Isadora Martin-Dye
Founder at Isadora & Co
Culpeper, Virginia, United States
Actions
Isadora Martin-Dye is the founder of Bloom, a venue intelligence platform for the wedding industry, and the owner-operator of Rixey Manor, a Knot Hall of Fame wedding venue in Rixeyville, Virginia. She runs both - a working venue and a software company - from the same desk.
A non-engineer by training, she ships production AI through 2,700+ lines of living architecture doctrine, versioned prompts with dual-provider fallback, and a cross-tier audit framework she designed to stress-test her own work. British-born and Virginia-based, she builds for industries where the transaction is irreplaceable, the customer is emotional, and "the model hallucinated" isn't an acceptable answer.
Area of Expertise
Topics
Your Harness Outlives the Model. Build It That Way.
Takeaway: treat provider choice as a runtime detail, not an architectural one. Everything you build on top of one model's behaviour is technical debt with a release date attached.
I run production AI on versioned prompts with dual-provider fallback, and I have swapped the model underneath a live system more than once. What breaks is never the API call. It is everything that quietly encoded one model's habits: prompts tuned to a particular refusal style, parsing built around one family's formatting, evaluation baselines that reset the moment you switch, and agent instructions that were only ever load-bearing because a specific model happened to follow them.
This session covers the layer I built to keep provider choice swappable, what it costs in abstraction overhead, and the places I deliberately left things coupled because portability was not worth the price. I will show a real migration, including the failure that made me build the layer in the first place.
Built and maintained by a non-engineer running two production products, which is the constraint that forced the structure rather than a footnote to it.
Your Agent Forgot Your Rules Three Hours Ago
Takeaway: rules that are requested decay, and rules that are enforced don't. Move your standards out of the prompt and into a hook that inspects what the agent actually produced.
My coding agent follows my standards for the first hour. By hour three it is quietly violating the one rule I cared most about, and I find out in review. Every fix I reached for first made it worse: restating the rules, bolding them, moving them into a file the agent reads at session start and drifts from steadily afterwards. The wording was never the problem. The rules were in the wrong layer.
Mine now live in the filesystem. Canonical doctrine sits in one directory, per-repo rules extend it, and a PostToolUse hook inspects the output and vetoes what fails. The agent does not have to remember anything. It has to pass.
This session covers the doctrine layout, the hook itself, real violations it caught that I would otherwise have shipped, and the false positives, because rejecting work that was fine is the honest cost of enforcement. The doctrine directory currently runs to roughly 2,700 lines across two production products. I am dyslexic and cannot review my way out of a bad session, which is why I found this failure at all and why every control I rely on has to be structural.
Tell Them It's a Bot. You'll Sell More.
Most agent deployments assume the goal is to sound human. The interaction feels warmer, early drop-off looks lower, and nobody in the review meeting argues for the version that announces itself.
The cost arrives later. Buyers work it out, usually at the point where the stakes rise, and what they learn isn't that you used AI. It's that you were willing to let them believe something untrue while they were deciding whether to trust you. In any purchase the customer can't undo, that's the one discovery you don't recover from.
This session argues that clear disclosure is the higher-converting choice in exactly those categories, and it's grounded in a year of running it. The speaker's wedding venue has had AI handling initial sales enquiries for twelve months, disclosed to every enquirer, in a purchase that is emotional, expensive and made once. Enquiries and booked tours held steady. She hasn't personally worked an initial enquiry in a year.
The second half is architecture. Where the agent acts and where it deliberately stops, drawn along a line that predicts it well: the more the buyer must trust a human afterwards, the less the agent can do beforehand. How a handoff carries context so the customer doesn't start again. What happens at runtime when the system detects a user in distress, using deterministic deny-lists and routing that moves away from generation before it happens, rather than a model asked politely to be careful.
Attendees will leave with a test for which transactions in their own deployment can go agentic, and a pattern for building disclosure and handoff that holds the sale rather than costing it.
Doctrine-Driven Development: Silence in the Spec Is Delegated Authority
Bloom is a multi-tenant production AI platform for wedding venues, running across four product tiers with versioned prompts, provider routing with a primary and live fallback, per-call metering, and client-facing generation against live business records. Most of the implementation is generated by Claude Code against written architecture, product rules, failure behaviour and acceptance criteria.
A structured cross-tier audit of that system produced three findings that resolved to one.
Client boundary. Provider exceptions could reach a user as a raw server failure rather than an application-owned response. Generation was well specified. Failure was not owned by the application across every route capable of reaching a client. The correction was normalising provider-specific failures at the application boundary and testing failure paths alongside success paths, rather than strengthening the system prompt.
Cost enforcement. A five-dollar daily per-venue threshold pauses autonomous AI behaviour while leaving operator-initiated work available. Metering had generalised, with calls through the shared client recording provider, model, tokens, cost, prompt version and correlation ID. Enforcement had not. It remained a helper function each caller had to invoke, and one path with a legitimate reason for its own provider client recreated the circuit breaker and the usage logging but not the autonomy gate.
Data contract. Lead ageing, stage duration, follow-up scheduling and decay scoring all resolve to a single inquiry_date field. Doctrine covered timestamp handling but did not specify behaviour for a missing or untrusted source timestamp, so the implementation selected new Date().toISOString(), conflating ingestion time with source time and scoring late-processed enquiries as new.
The common shape is control placement. In each case the rule existed as written policy or as a convention on the expected route, one layer above the point where it could be enforced. Written specification moves judgement earlier and gives the diff something concrete to be reviewed against, but a control that holds only because the generating model did not route around it is a capability gap rather than a control.
The session covers the build loop and where audit differs from test, the evidence standard applied to audit claims and why a model-assisted review of a model-built system is not independent assurance, and the migration of each finding to an enforceable boundary. It draws on published work on requirement ambiguity in function-level code generation and on maintainer acceptance of agent-written patches that pass automated graders, and it includes the remediation that remains deliberately incremental.
Stop Writing Tone Instructions. Layer Them.
Tone instructions in a system prompt collapse the moment your AI hits production. "Write in our brand voice" is the prompt-engineering equivalent of writing a comment that says "make it work." It does nothing the model wasn't already going to do, and it breaks the moment a user asks something the example outputs didn't cover.
I built five production AI products on the same technical spine, three of them with strong, distinct brand voices that had to hold under unusual conditions. Couples in the most emotionally loaded purchase of their lives. Families of missing people. Multi-tenant hospitality clients with completely different tones from each other. The four-layer architecture in this talk is what survived contact with all of them.
The four layers, in order: the immutable identity layer (what the brand structurally cannot say), the situational mode layer (what shifts when the user's state shifts), the example-anchored voice layer (where most teams stop, and why it isn't enough on its own), and the post-generation veto layer (the cheap final pass that catches what the other three missed).
Real prompts. The multi-tenant pattern that made it scale. The failure cases that forced each layer into existence. The version I'd build differently if I started today.
Could do a hands-on workshop on prompt building.
Designing an API Layer for AI Providers You Can't Trust
Every team shipping production AI eventually faces the same problem: the model API you depend on will fail. It will rate-limit you mid-request, return malformed JSON, deprecate without warning, raise prices, or simply go down on a Tuesday afternoon. If your application treats the model as a hard dependency, your application is as reliable as your weakest provider.
This talk walks through the design of a dual-provider AI abstraction layer in production at Bloom, a vertical AI platform for the wedding industry. We'll cover the API contract that lets a single call route between Claude and GPT-4o without the calling code knowing which provider answered, the cost-routing logic that picks providers based on task class rather than just price, the fallback semantics when the primary fails mid-stream, and the observability layer that tells you which provider you actually paid for at the end of the month.
Attendees leave with a concrete pattern for treating LLM providers the way mature systems treat any other unreliable upstream dependency: with versioned contracts, explicit fallback paths, cost ceilings enforced above the model, and audit trails that survive a postmortem. Useful for any team currently coupled to a single AI vendor and wondering what happens the day that vendor changes the deal.
Doctrine-Driven Development: Shipping Production AI Without Writing the Code
I'm a wedding venue owner who built a production AI platform without writing the code myself. Not because I was coasting on agents - because I wrote the spec so tightly that the code became the easy part.
Bloom is a venue intelligence platform now in active build across four tiers, with prompt versioning, dual-provider fallback, a four-character cross-tier audit framework, and a 2,700-line living architecture doctrine that gets fed to Claude Code at the start of every session. The doctrine isn't documentation. It's the spec, the test plan, the security policy, and the cost ceiling, all in one place, all under version control, all enforced by audit.
This talk is about what I've learned doing it: where doctrine-driven development actually works, where it falls apart, and what the real failure modes look like when the founder is the architect and the model is the contractor.
I'll walk through three specific findings from a recent audit - an AI name leak that was worse than the doctrine tracker indicated, an inquiry-date recomputation gap, and a cost ceiling enforcement hole — and what each one taught me about the limits of writing your way to correctness.
The audience leaves with a concrete framework for treating prompts as governed artifacts: versioned, audited, fallback-protected, and tied to enforceable cost and security boundaries. Useful Monday morning whether you're a non-engineer founder or an engineering lead trying to bring AI work under the same discipline as the rest of your stack.
Why me, why this audience:
I'm not pitching a product. I'm an operator with a build I can show, in a category - vertical AI for a regulated, relationship-heavy industry - that the DC audience will recognize structurally even if the surface domain is unfamiliar. Wedding venues aren't federal agencies, but the constraints rhyme: irreplaceable transactions, low tolerance for AI failure modes, real money on the line, and no appetite for "the model hallucinated" as an answer.
I live in Rixeyville, Virginia. Inside the 100-mile radius.
API World Roundtable: Isadora Martin Dye, Founder, Isadora & Co
We talk a lot about models, APIs, agents, reliability and architecture. But none of them exist in a bubble. There’s a human building the system, and another human eventually living with whatever it does.
I want to talk about what gets lost between those two people. The cognitive load on developers trying to keep up with technology that changes underneath them. The assumptions we make about the people at the other end. And what happens when technically impressive systems meet messy, emotional, unpredictable humans in the real world.
Because ultimately, we aren’t building for benchmarks. We’re building for people.
Bring your war stories. Especially the ones where the technology worked exactly as designed — and the human absolutely did not.
DC State of the Stack 2026 Sessionize Event
API World + CloudX + AI TechWorld 2026 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top