Governance documents say things like "the agent must never refund above $200." The architect's job is the next sentence, the one the document usually skips: enforced where? Every policy has four candidate homes — the retrieval scope, the tool scope, the output screen, the approval gate — and each home stops a different failure class. Putting a policy in the wrong home is how systems end up governed on paper and ungoverned in production.
The policy: refunds are capped at $200, and must hit the right order. 1,000 refund requests for $20–$400, of which 2% target the wrong order entirely (the customer pasted the wrong id; the model matched the wrong record). Choose where the cap lives:
Read the three configurations as a progression of failure classes. The prompt version leaks over-cap refunds — not many, but "not many" times real money is an incident report. The schema version makes an over-cap refund unrepresentable: the tool call cannot validate, so the failure class is closed by construction — but the schema knows nothing about which order deserves the refund, so wrong-target refunds sail through at exactly the background rate. The gate closes that last class too, at the price every gate charges: human time, on every single approval.
Generalise that experiment and you get the table the exam keeps asking about from different angles — each policy type has a home where it's enforceable by construction, and prompt-level phrasing of the same policy is a behaviour shaper, never the control:
| policy | enforced by construction at… | the prompt version fails when… |
|---|---|---|
| "never reveal internal pricing" | retrieval scope — pricing docs aren't retrievable in this flow (see ACL-RAG) | the model is argued into it, or paraphrases what's in context |
| "refunds ≤ $200" | tool scope — maximum: 200 in the schema; larger calls cannot validate | an urgent-sounding customer justifies an exception |
| "no destructive action without sign-off" | approval gate — the harness holds the call until a human approves | the model decides this case surely counts as approved |
| "no PII in replies" | output screen (recognisable formats: emails, card numbers) — plus retrieval scope for PII that shouldn't be in context at all | the PII is paraphrased, partial, or a format the screen doesn't know |
| "stay under $0.25/episode" | harness budget — the loop is cut when the meter says so (see the Bench loop station) | always — the model doesn't see the meter |
Two working rules fall out. First: when a policy review says "the prompt says so," ask what happens on the day the prompt is ignored — if the answer is "an incident," the policy needs a structural home too. Second: gates are precious — they spend human attention, the scarcest resource in the system — so they belong on the actions that are irreversible or above authority, not on everything (a gate on everything is how reviewers learn to click approve without reading).
Second opinion (taught here — these corroborate): Building effective agents · Anthropic docs · tool use.