A couple writes in, excited about a Saturday in October. The venue’s AI assistant replies warmly, in perfect brand voice, and offers them the date. The date was already booked. In Isadora Martin-Dye’s words: “The AI would keep offering dates to my clients that did not exist” [1]. Nothing in the prompt had failed. The model had simply never been given the calendar, and no amount of additional instruction was ever going to fix that.
Martin-Dye runs Rixey Manor, an 1801 estate in Virginia [2], and built an AI agent for it before productizing that agent as Bloom House, which she describes as “the first vertical AI built by a venue owner, for venue owners” [3]. She described the resulting architecture in her AI Engineer World’s Fair 2026 talk on the Online Track [1][4]. It is worth saying up front what this is and is not: it is one practitioner’s first-person account of a system she built and operates, not a spec, not a standard, and not a framework. She disclaims the framing herself: “The four-layer pattern isn’t a framework I’m trying to sell” [1]. What makes it worth an article is that the failure it was built to fix is one we keep finding in the agent stacks we audit, and that the fix maps cleanly onto Claude API primitives that exist today.
Figure 1 - Three layers of instruction, one layer of permission: Identity, mode, and voice are all text asking the model nicely. The fourth layer is code that reads what came out and decides whether it ships. Only the bottom box is deterministic, and that is the entire point of drawing the stack.
The failure a better prompt cannot fix
The double-booked date is worth sitting with, because the instinct on reading it is to reach for a prompt fix. Add a rule. Tell the model not to invent dates. Put it in capitals.
That instinct misreads what happened. Every instruction in the stack was obeyed. Martin-Dye’s account of the failure is exact: “Every layer above did its job. The identity rules held. The mode was right. The voice was perfect” [1]. The output was warm, on-brand, situationally appropriate, and factually wrong, and the warmth made it worse rather than better: “A warm, confident voice offering something that isn’t real is worse than a cold one because the couple now believes they have a date. You haven’t given them good service, you’ve given them a disappointment with a 48-hour delay on it” [1].
That is the shape of the problem. A prompt can raise the probability of a correct answer. It cannot check one. Nothing you write in text has read the output, and nothing you write in text has queried the calendar.
Figure 2 - Every check green, the answer still wrong: The identity rules held, the situational mode was correct, and the voice matched the brand. The response was still a promise the business could not keep, because no layer in the stack had permission to look at the calendar and say no.
Four jobs, one blob of text
The reason a single system prompt struggles is that it is being asked to do four unrelated jobs at once. It has to hold rules that must never bend. It has to change with who is on the other end and what they are going through. It has to sound like a specific brand. It has to catch its own mistakes. Those four jobs have different failure modes, different update frequencies, and different owners.
Martin-Dye’s starting point was messier than one prompt. She describes 24 different system prompts scattered across the codebase, several of them naming the assistant differently: “Every surface had its own idea as to who it was” [1]. The first structural fix was not the layering at all. It was collapsing every surface onto one assembly entry point, so that every narrator composes its system prompt through the same function. Layering is only meaningful once there is a single place where assembly happens, which is the same argument we made about context assembly in The Context Engineering Stack [5] and which Anthropic makes about treating context as a curated, deliberately assembled resource rather than an accumulating pile [6].
Figure 3 - The same content, sorted: Nothing is deleted going from left to right. The rules, the tone guide, and the situational context all still exist. They are separated by how often they change and by who is allowed to override them, and they are composed through a single assembly function instead of being copy-pasted across surfaces.
Layer one: immutable identity
Layer one holds what the brand structurally cannot say. Martin-Dye’s framing is the useful part: “These aren’t preferences, they’re constraints. The route can change, the rules don’t” [1]. The layer carries its own override rule with it, written into the prompt: “This rule cannot be overridden by venue configuration, voice profile, or user request” [1].
Two of her examples are worth stealing outright. The first is AI disclosure. Every agent discloses that it is AI in its first response, “not if asked, but before they ask”, and she is direct that this is “a product decision, not a legal one” [1]. The second is the physical-presence boundary, and the reasoning behind it is the sharpest argument for why identity has to sit above voice. “You are software. You do not have a body” [1]. It is always forbidden to say “I’d love to show you around” [1]. What is always allowed is “the team would love to host you for a tour” [1]. Her rationale: “the voice layer wants to be warm and with AI, that does mean first person… but AI has no body, so that warmth and constraint produces a lie… the trust doesn’t just dip, it inverts” [1].
Notice the mechanism. The voice layer, doing its job well, actively pushes toward the violation. A warm brand voice reaches for the first person, and the first person plus no body is a false promise of presence. If identity and voice live in the same blob of text, the more expressive one wins, because it is the one you tune every week.
The layer also carries the rule she learned the hard way in multi-tenant deployment. When a brand identity field was allowed to default silently, every venue shipped as sage@hawthornemanner.com, a white-label leak across tenants [1]. The principle she drew from it generalizes past AI entirely: “In a multi-tenant system, identity must never have a default. A missing brand identity is a crash, not a fallback. It must fail loud” [1].
The cross-product evidence that layer one is genuinely a separate layer is a second product she has built but not launched, a missing-persons intelligence utility called Threadline, still in private build with no public URL [2]. Same architecture, radically different stakes. Its layer one carries essentially one rule, that the system can never use words like confirmed, identified, matched, proven, linked, or solved [1]. Her explanation of why is the strongest case in the talk for putting rules above tone: “The word ‘match’ said to someone who has spent years not knowing where their child is is not just a tone violation. It is the single most damaging thing that a product could ever do” [1]. The model has no idea it is doing this, she adds, since it is “reaching for the word ‘match’ because statistically it is the natural word” [1].
Figure 4 - Rules that nothing downstream can renegotiate: Layer one is defined by what cannot override it. Tenant configuration, voice tuning, and user instructions all arrive at the same closed boundary. A missing identity field is a crash, never a silent default.
Layer two: situational mode
Layer two is the one Martin-Dye says almost nobody builds: “This is the layer that most teams never build at all. They write one system prompt and send it to everyone regardless of who that person is or what they’re going through” [1].
It carries two kinds of real-time signal. The first is the role of the person being served. The same agent that talks to couples also briefs venue coordinators, and for a coordinator it talks “like a colleague, not a customer” [1]. A coordinator asking whether inquiries will be up in June should hear something like “I can’t forecast that confidently, here is the trend”, while “a couple should never be refused like that” [1]. Same identity, same voice, different route.
The second is what the person is going through. Soft context notes about a couple’s circumstances are loaded “for tone, empathy, and what not to say. Never quote them verbatim” [1]. If a couple’s engagement drops off and the system knows a parent is in treatment, that reads as a family under strain rather than a cold lead to chase [1].
One implementation detail here is more useful than it first looks, and it is the kind of thing you only learn by shipping. The assembler renders the couple-note block before the numbers-guard block, deliberately, because the model sets tone from the soft human context first and then satisfies the numeric constraints. Reverse the order and, in her words, “reversing the order makes the prose feel mechanically slotted” [1]. Order inside a layer is load-bearing, not just order between layers.
Figure 5 - One agent, two routes: The identity and the voice are identical on both paths. What changes is the situational layer: who is asking, and what they are living through. The same question about June inquiries earns a hedged trend answer for a coordinator and a different framing entirely for a couple.
Layer three: example-anchored voice
Layer three is the tone guide, the phrase list, and the brand dials, taught by example rather than by description. Her analogy: “If we’re keeping the intern analogy, it’s the induction pack” [1]. This is the layer most teams start at, and it is also the layer most teams stop at.
It is worth being precise about what it cannot do, since three of the four jobs get quietly assigned to it by default. It cannot enforce a rule that belongs in layer one. It cannot respond to who this specific person is, which is layer two. It cannot catch what the model produced that it should not have, which is layer four.
The limit statement is the one to remember: “Examples teach the model what good looks like on the happy path. On turn 21 where the user asks the things that examples never cover, the phrase list has nothing to say… Examples are not the right tool for guarantees, they were never designed to be” [1].
Figure 6 - Examples cover the path they were drawn from: A phrase list built from good day-one conversations holds up through the turns that resemble them. The coverage gap opens at exactly the turns nobody wrote an example for, which is where the expensive failures live.
KEY INSIGHT: Few-shot examples are a steering mechanism, not a guarantee mechanism. If a requirement has to hold on the turn nobody anticipated, it does not belong in the example set.
Layer four: the deterministic veto
Layer four is different in kind from the three above it. It is “the only layer that actually reads what came out… it’s automated, it’s cheap, and it’s the only part of the whole architecture that isn’t a prompt” [1]. Her framing of why it needs to exist is the one that has landed hardest with the engineering managers we have repeated it to: you wouldn’t let a new intern send a client email blind, so someone reads it first, and layer four is that read [1].
It comes in two flavors, and the distinction matters when you build it.
The soft flag is an honesty inspector that runs after generation and raises a hand when a response has slipped a rail, asking questions as basic as “did it actually answer the question?” [1]. Its tuning is governed by an asymmetry that is obvious once stated and almost never written into a design doc: “A false positive means someone double-checked a phone response. A false negative means a hallucinated number or a privacy violation that ships to a client” [1].
The hard reject is a numbers guard. The model states a figure it was never given, the prompt already told it not to, and the guard rejects the output regardless: “A date the model offered that isn’t in the allow list doesn’t ship” [1].
The implementation choice is regex, and she defends it as a real trade rather than an obvious win: “regex is fast and cheap and deterministic… a small classifier might catch more edge cases… but it is a classifier that is probabilistic. Right now I’m choosing determinism over coverage. I’d make that choice again as it stands, but it is a real trade-off and not an obvious win” [1]. That is the correct way to hold it. Swapping the regex for a small model buys coverage and gives back the guarantee, which is the only thing layer four exists to provide.
She is equally honest about where the design is currently weak, and it is the failure mode we would flag first in an audit. The veto is wired individually into each surface rather than living behind one gate: “the veto should be its own service not wired individually into each surface… a new service remembers to wire in the veto manually. That’s a checklist item waiting to be forgotten” [1]. A gate you have to remember to attach is not a gate.
This is the same conclusion we reached from a completely different direction in Stripe Minions and the Hybrid Secret [7], where the test-validation node runs regardless of what the coding agent decides, and the same architectural move we described as a named component in The Verification Layer [8]. Brand voice and coding agents have nothing in common except the part that turns out to matter: the last thing standing between the model and the user has to be code.
Figure 7 - The only box in the architecture that is not a prompt: Generated output arrives, the soft flag routes questionable responses to a human, and the hard reject blocks any claim that fails an allow-list check. Both branches are ordinary code paths, which is why they are the only part of the stack that can promise anything.
KEY INSIGHT: The first three layers are instruction, the fourth is permission. Instructions are probabilistic. Permission is deterministic. If your architecture has no layer that can refuse, it has no guarantees, only tendencies.
Why “usually correct” stops being good enough
The obvious objection to layer four is that a well-tuned prompt already gets it right almost every time. That is true, and it is the reason the layer is so often skipped.
The reliability math is unforgiving here, and we walked through it in The March of Nines [9]. A system that is right almost every time fails at a rate proportional to how often you run it, and each additional nine of reliability costs roughly as much engineering as the one before it. A prompt-only stack buys the early nines cheaply and then stalls, because the remaining failures are exactly the cases no instruction anticipated. Layer four is cheap precisely because it does not attempt the general problem. It answers one narrow question, deterministically, on every single response: is this specific claim one the system is allowed to make?
The venue case makes the stakes concrete. A booked date offered to one couple is a refund conversation and a lost booking. The same error, repeated across every booking inquiry the venue receives, is a business problem rather than a support ticket.
Building the four layers on the Claude API
None of the above requires a framework, a fine-tune, or a beta program. It is field placement and one function. Here is where each layer lives if you are building on the Claude API today, and, more usefully, where the platform’s guarantees stop.
The layer order is the cache order
This is the part that surprised us, and it converts “layer your prompts” from style advice into a line item.
Anthropic’s prompt caching documentation states that “Cache prefixes are created in the following order: tools, system, then messages. This order forms a hierarchy where each level builds upon the previous ones,” and that “Changes at each level invalidate that level and all subsequent levels” [10]. Up to four cache_control breakpoints are allowed per request [10].
Read that next to the four layers and the shared principle is obvious: both orderings are attempts to put the least volatile content first. That does not make the two orderings identical, and the difference is the useful part. Identity never changes, tenant voice configuration changes per tenant, and situational context changes per conversation, so a cache-optimal layout puts the voice layer above the mode layer rather than below it. Layer four sits outside the hierarchy altogether, because it is not a prompt and never enters the cache at all. The practical move survives either ordering: put a breakpoint at each boundary, and editing one layer re-bills that layer and everything below it instead of the entire prompt.
The inverse is the expensive part, and it is the single most common thing we find in a client’s prompt file. One monolithic system prompt with the current date, a user name, or a session ID interpolated near the top invalidates everything after it on every request. There is no error and no warning. The tell is usage.cache_read_input_tokens sitting at zero when you expected it to be large.
One trap worth knowing before you split things finely: the minimum cacheable prefix is model-dependent and not monotonic across generations, ranging from 512 tokens on the newest models up to 4,096 on others [10]. A tight, well-written identity layer can land below the threshold and silently fail to cache, again with no error. Check the current table in the docs against the model you are actually calling.
Figure 8 - Editing a layer re-bills that layer and everything below it: The caching hierarchy runs tools, then system, then messages, and a change at any level invalidates that level and all subsequent ones, the edited level included. Breakpoints placed at layer boundaries keep an edit local. Layer four sits outside this hierarchy entirely, since it is not a prompt and never enters the cache. A volatile value near the top of a monolithic prompt invalidates the whole thing on every request.
Where each layer actually lives
| Layer | Claude API surface | What the platform guarantees |
|---|---|---|
| 1. Immutable identity | Top-level system field, first block, in a stable XML tag | Nothing behavioral. The documented effect of a role is that it “focuses Claude’s behavior and tone” [11]. Focus is not enforcement. |
| 2. Situational mode | A {"role": "system"} message appended to messages mid-conversation [12], or an Agent Skill loaded on demand [13] | Nothing behavioral. It does guarantee the cached prefix survives the update. |
| 3. Example-anchored voice | Few-shot <example> blocks | Nothing. Anthropic’s own verb for what examples do is “steer” [11]. |
| 4. Deterministic veto | output_config.format, strict: true on a tool, and then your own code | Schema compliance via constrained decoding [14]. Shape only. |
Layer two used to be the awkward one to implement, since changing a situational instruction meant editing the top-level system field, which sits ahead of the entire conversation and therefore threw away every cached turn. On several current Claude models you can now append a {"role": "system"} message to messages instead [12], adding a system-level instruction “without invalidating the system or message caches” [10]. The model list moves, so check the page rather than trusting any cached summary of it, including this one.
The security property of that channel is worth as much as the caching property. An operator instruction sent as role: "system" cannot be forged by anything that writes into user-visible input, whereas an instruction smuggled into a user turn can [12]. A situational layer that carries authority belongs on the operator channel.
Structured outputs guarantee shape, never truth
Here is the misconception this article exists to head off, and it is the one a reader who knows the Claude API is most likely to walk into.
Structured outputs “guarantee schema-compliant responses through constrained decoding” [14], and strict tool use guarantees “schema validation on tool names and inputs” [14]. Both are real guarantees. Neither is a veto.
A JSON schema can force {"date": "2026-10-17"} to be a well-formed ISO date. Nothing in the schema knows that date is booked. Constrained decoding removes the parsing problem so that the checking code becomes trivial to write, which is a genuine gain and a completely different gain. Mistake one for the other and you reproduce the venue failure exactly: a perfectly formed, perfectly on-voice, factually wrong answer, now with a green checkmark from your validator.
Layer four on Claude is therefore two moves, not one. First, constrain the output into a machine-checkable shape. Second, run non-LLM code over that shape before the response is released: the allow-list lookup, the calendar query, the price-table comparison, the regex on a phone number. The second move is the one no API feature provides, and it is the entire reason the layer exists.
Figure 9 - Two checks that look alike and are not: The schema validator asks whether the answer is well formed and the calendar asks whether it is true. Only one of them has ever seen the booking table. Constrained decoding makes the second check easy to write; it never performs it.
KEY INSIGHT: Structured outputs are how you make the veto cheap to implement. They are not the veto. If no code in your request path has read the world state, nothing in your stack has checked anything.
Where the check physically runs
The tool-use loop is the natural home for the second move. The model emits a tool_use block, your application executes it, and your application returns a tool_result [15]. Your code is already sitting between the model’s proposal and the user’s outcome. A veto implemented at that seam is a code path rather than a prompt, which is the property the whole pattern is arguing for. It also answers the architectural debt Martin-Dye names: one gate every surface routes through, instead of a wiring step each new surface has to remember.
Three domains, one conclusion
What makes this worth building on rather than merely quoting is that teams with nothing in common keep arriving at it.
The second instance comes from monday.com. Its Sidekick agent wraps its orchestrator in a middleware pipeline, and one of those middleware layers exists for a failure that looks nothing like a double-booked wedding date and is structurally identical. The model confidently invents tool names that do not exist. The middleware intercepts every tool call before execution, checks the name against the bound tool set, and substitutes the closest valid one, so the model never sees the error. monday.com reports a 94% recovery success rate across its self-healing mechanisms [16]. Treat that as production testimony rather than an audited benchmark, since it is a speaker-claimed figure with no published measurement behind it. The mechanism is the point, and the mechanism is deterministic by design: the check triggers on a mechanical signal, not on a quality judgment.
A third instance comes from CI/CD. Premved Dhote, a software engineering intern at Red Hat, demonstrated a personal proof-of-concept in which a failing pipeline triggers an agent that reads the logs, proposes a patch, and validates that patch in a Docker sandbox against the same test suite a human’s pull request would face, opening a pull request only once the tests pass [17]. This is a demo, not a product, and no performance numbers accompany it. Its framing of why the agentic step is needed at all is a clean one-liner: “workflows are really good at automating things, but very bad at solving problems” [17]. The deterministic scaffolding stays deterministic. Only the diagnosis is agentic, and the test suite, not the model’s confidence, decides what ships.
Brand voice, tool calls, and shipped code. Three domains, three teams who were not talking to each other, one conclusion about where the final check has to live.
Figure 10 - The same shape three times: A generation step that is expressive and probabilistic, followed by a check that is narrow and deterministic. The domains share no vocabulary and no tooling. They share the position of the gate.
What to do on Monday morning
The audit is short, and you can run it on your own stack before lunch.
- Find the assembly point. If more than one place in your codebase builds a system prompt, that is the first fix, ahead of any layering. One function, every surface.
- Sort the existing prompt into the four jobs. Rules that must never bend, context that changes per conversation, tone, and checks. Most prompt files turn out to be three of the four, with the fourth missing entirely.
- Write the override rule into layer one. Name what cannot be overridden by configuration, voice, or user request, in the prompt itself.
- Make identity fail loud. A missing tenant identity field is a crash, not a default. This is a code change, not a prompt change.
- Put a
cache_controlbreakpoint at each layer boundary, then checkusage.cache_read_input_tokenson a warm request. Zero means something volatile is sitting above your stable content [10]. - List every factual claim your agent is allowed to make. Dates, prices, availability, names, capacities. Each one needs a lookup, not an instruction.
- Write the veto as one function, called from one place. Soft flag for anything questionable, hard reject for anything on the claims list that fails its lookup.
Figure 11 - The audit, in order: Assembly first, because layering is meaningless without one composition point. The veto last, because it needs the claims list to check against. Everything in between is sorting text you have already written into the job it actually does.
Conclusion
The four-layer split is useful as a diagnostic before it is useful as an architecture. When an agent misbehaves, the layer names tell you which fix is even capable of working. A rule that keeps getting talked around belongs in layer one, not in a firmer sentence in layer three. A response that is technically correct and tonally wrong for the person receiving it is a missing layer two, not a voice problem. A response that is beautifully written and factually false is a missing layer four, and no rewrite of the first three layers will ever close it.
The Claude API half is what makes this actionable this week rather than aspirational. The layers map onto request fields you already use, the ordering the pattern recommends is the ordering the cache already rewards, and the only piece the platform cannot give you is the one you were always going to have to write: a function that reads the output and checks it against something real. Structured outputs make that function trivial to write. They do not write it.
If you want the honest version of what this costs, it is an afternoon of sorting and a day of writing lookups, and the payoff is that you stop shipping confident answers you cannot back. That audit is work we do with clients: reading the prompt stack, separating the four jobs out of whatever single file has accumulated them, and adding the deterministic veto that almost nobody has built. If your agent can state a fact that no code in your request path ever verified, you already know which layer is missing.
References
[1] I. Martin-Dye, “Stop Writing Tone Instructions. Layer Them.,” AI Engineer World’s Fair 2026 (Online Track), AI Engineer, Jun 2026. https://www.youtube.com/watch?v=ij-AU9dpJjc
[2] Isadora & Co, “Press Kit,” accessed Aug 2026. https://www.isadoraandco.com/press
[3] Isadora & Co, “Bloom House,” accessed Aug 2026. https://thebloomhouse.ai
[4] Isadora & Co, “Speaking,” accessed Aug 2026. https://www.isadoraandco.com/speaker
[5] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Context Engineering Stack: Compression, Retrieval, and Decision Memory,” 2026. /insights/ai-16-context-engineering-stack/
[6] Anthropic, “Effective context engineering for AI agents,” Anthropic Engineering, accessed Aug 2026. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[7] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Stripe Minions and the Hybrid Secret: Deterministic Rails Around AI,” 2026. /insights/ai-04-stripe-minions-deterministic-rails/
[8] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Verification Layer: Why Knowledge Agents Need One,” 2026. /insights/ai-15-verification-layer-knowledge-agents/
[9] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The March of Nines: Why Agent Reliability Is an Engineering Problem,” 2026. /insights/ai-01-march-of-nines-reliability/
[10] Anthropic, “Prompt caching,” Claude Docs, accessed Aug 2026. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
[11] Anthropic, “Prompting best practices,” Claude Docs, accessed Aug 2026. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
[12] Anthropic, “Mid-conversation system messages,” Claude Docs, accessed Aug 2026. https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages
[13] Anthropic, “Agent Skills overview,” Claude Docs, accessed Aug 2026. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
[14] Anthropic, “Structured outputs,” Claude Docs, accessed Aug 2026. https://platform.claude.com/docs/en/build-with-claude/structured-outputs
[15] Anthropic, “Tool use with Claude,” Claude Docs, accessed Aug 2026. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
[16] Omri, “How Monday.com Built Sidekick on Deep Agents,” Interrupt 2026, LangChain, Jun 2026. https://www.youtube.com/watch?v=c2fLLS7np3Y
[17] P. Dhote, Red Hat, “I Break Things, AI Fixes Them: Building a Self-Healing CI/CD Pipeline,” The Linux Foundation, Jul 2026. https://www.youtube.com/watch?v=l82vSl0MwGQ
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.