A runtime guardrail asks one question: is this action allowed? That catches the agent approving an ineligible refund. It cannot catch the agent that never verified who it was talking to, or confirmed nothing before making the change — and in the three customer-service domains tested, procedural requirements like those cover 67% to 100% of tasks. Compile the written policy into a graph, keep the position in code rather than in the conversation, and have a separate checker walk it at every user turn: mean pass-on-all-four-attempts goes 0.42 → 0.62, and the domain where the steps have a mandatory order goes 0.25 → 0.675.
Compliance breaks in two shapes. The agent takes an action policy forbids — approving a change on a ticket that is not eligible. Or the action itself is fine and the procedure around it is not: identity never verified, eligibility never checked, no confirmation before a charge. Step through four transcripts and watch which shape an action-level guardrail catches.
The share of tasks carrying a procedural requirement is 67.4% in the airline domain, essentially all of them in retail, and 98.0% in telecom. What separates telecom is order: 54.0% of its tasks have steps that must happen in a fixed sequence, against 4.7% and 3.6% in the other two — which is exactly where the baseline agent collapses.
The policy is compiled offline into a graph of typed nodes — read-only tool calls, mutating calls that need authorisation, required user confirmations, decision branches, reusable subflows — and each node carries the condition that satisfies it. At every user turn a separate verifier reconciles open requests against stored state, walks the graph from the position it recorded last turn, stops at the first node the conversation has not satisfied, and hands that step back as the agent's next instruction. Advance the turns and watch the walk.
The design decision that matters is where the position is kept. The agent's memory of "I already verified them two turns ago" is a claim about a transcript; the verifier's record is a row in a store, reconciled each turn against what actually happened. That is why the next section's ablation — the same graph, pasted into the agent's own prompt — recovers so little of the gain.
Three customer-service domains, four trials per task, scored on how many tasks pass on all four. The comparison is a plain agent loop, an action-level guardrail that blocks unauthorised mutations, and the graph-walking verifier. Pick a domain and a slice — the tasks that test forbidden actions, the tasks that test whether the right change was made, or all of them.
Note what the action-level guardrail does in retail: it takes the plain loop from 0.575 down to 0.360. Blocking is not free — a guard that intercepts a mutating call without telling the agent what to do instead can leave it stuck mid-procedure. Guidance and blocking are different interventions, and only one of them is monotone.
Two ablations isolate the two halves of the method. Put the compiled graph in the agent's own system prompt and remove the external verifier: the agent has the whole procedure written down and still cannot hold its place. Keep the verifier but give it raw policy text instead of the graph: it can judge, but it has no position to resume from. Step through the arms.
The step-level number barely moves — 86.4% to 94.5% — while the whole-trace number nearly doubles. That is the signature of an ordering problem: individual steps were mostly being done, and the runs were failing on sequence. Reading only step-level compliance would have told you this system was already fine.
The shape in production: an agent handling support conversations against a written policy, some fraction of which carry ordered steps — verify, then check eligibility, then confirm, then charge. Set your volume and the share of conversations with an ordered procedure. The verifier price and the compliance rates are the paper's; the traffic is yours.
Forty cents a conversation is not nothing, and the paper is explicit that the verifier fires at user-turn boundaries rather than before every policy-relevant action, so coverage has gaps and enforcement stays probabilistic. If your rule is hard — money moved, data deleted, an account closed — you still want a deterministic check on the action itself. This buys you the procedure around it.