Verification Gates Between Steps

Verification Gates Between Steps are the cheapest defence against the compounding described in Chapter 2, and the one most systems skip because the step reported success. A gate exists to disbelieve that report, at a cost proportional to what believing it wrongly would cost.

Key takeaways

• A gate compares a step's claim against something outside the model. A model reviewing its own work shares the premise that produced the error, which is why self-assessment is the weakest form available.
• Price each gate against the commitment it guards. A read costs nothing to get wrong, so it gets a schema check; an irreversible external effect justifies an expensive gate and sometimes a human.
• Prefer deterministic checks. Counts, invariants, schema validation, read-back and diffing catch a large share of real failures for microseconds and no tokens.
• Gate the precondition as well as the result. Half of what goes wrong at a step was already wrong before it started, and preconditions are cheaper to check than outcomes.
• Record every gate result, including the passes. Gate outcomes over time are the only honest measurement of where your agent actually breaks, and they feed the horizon work in Chapter 11.

Read this beside Chapter 3, which put an acceptance field on every step, and Chapter 4, which checkpoints only after a gate passes. Chapter 6 handles the case where the gate fails after the effect has already left.

A step reports that it updated the customer records for a segment, and it did. Two hundred and forty-one of them, when the segment contains two hundred and forty.

Nothing in the run notices. The report says success because the tool returned success, and the extra record was correctly updated according to a filter that was subtly wrong. Forty steps later the discrepancy surfaces as a billing question.

What a gate actually is

A gate is a comparison between two things: what the step says happened and what an independent source says happened. The independence is the whole mechanism.

That framing rules some things in and some things out. Reading back the row you just wrote is a gate, because the database is independent of the model's belief. Counting the records affected and comparing against the count the plan expected is a gate. Validating output against a schema is a gate, weak but real. Asking the model whether it did the right thing is not a gate, because the answer is generated from the same context that produced the action.

Anthropic's guidance from December 2024 makes a related point about design: agentic systems introduce the potential for compounding errors, and complexity is worth adding only where it is needed. A gate is complexity that is needed exactly where a wrong commitment would be expensive, which is the pricing rule this chapter is built around.

The diagnostic work published in April 2026 by Wang and colleagues supports the placement question too. Failures in long-horizon runs concentrate at identifiable steps rather than spreading evenly, which means gates do not have to be uniform. Instrument first, then put the expensive gates where the failures actually are.

Price the gate against the commitment

Gates cost latency, tokens and engineering time. Spending them evenly across forty steps is the surest way to end up with none where they matter.

The bottom row is where the money is. A step that sends money, deletes data, or contacts a customer deserves a gate that costs real time, because the alternative cost is unbounded. Everywhere else, cheap and deterministic beats thorough and slow.

Google's error budget framing gives the language for arguing this with a product owner. Decide the failure rate you are willing to carry for a class of task, measure what you are getting, and spend gate latency until you are inside it. That turns an aesthetic argument about rigour into an arithmetic one about a number both sides agreed.

Deterministic checks first

The reflex is to reach for a model as the checker. Reach for code first, because most of what goes wrong at a step is detectable without judgement.

Counts and totals. Did the number of affected rows match the number the plan predicted, and does the sum of the parts still equal the whole. Invariants. Is the ledger still balanced, is every order still attached to a customer, is the status field still one of its permitted values. Schema. Does the output parse, are the required fields present, are the types right. Read-back. Does the record now say what the step claims it says. Diff. What changed between the pre-step checkpoint and now, and is anything in that diff outside what the step was authorised to touch.

The diff check deserves its own mention because it catches the failure class nobody predicts: the correct action applied to the wrong scope. A step that was supposed to touch one tenant and touched three passes every check that looks only at what it intended to do, and fails a diff immediately.

None of these require a model, all of them run in milliseconds, and together they catch a substantial share of real failures. Only after they pass is a judgement check worth its cost.

When the checker has to be a model

Some properties are not mechanically checkable. Whether a summary is faithful to a document, whether a message is appropriate to send to a customer, whether a proposed code change matches the intent of the ticket.

For those, the rules that make model verification worth anything are strict. The checker gets the artifact and the criteria, and not the reasoning that produced the artifact, because the reasoning is what carries the error forward. It should be a separate call with its own prompt, not a continuation. Where the stakes justify the cost, use a different model, since two models sharing a family share failure modes. And the checker must be able to fail: a rubric that only asks for a score produces scores, while one that asks for the specific criterion violated produces findings.

This is the point where teams reinvent the reflection loop and get less than they expect. The March 2026 reliability framework reports memory scaffolds degrading long-horizon performance in their tests, which is a caution about the general shape: adding more model-generated context to a run that has gone wrong tends to reinforce the wrong premise rather than dislodge it.

Gate the precondition, not just the result

Half of what fails at a step was already false before the step began.

The wrong environment was selected two steps earlier. The record the step is about to update has been modified by someone else since the plan was made. The account is now closed. Checking those before executing is cheaper than checking the outcome afterwards, and much cheaper than compensating for a completed action.

Preconditions also give you the safest possible failure. A step that never runs because its precondition was false has emitted nothing, changed nothing, and needs no undo. It is the only completely free recovery in this book.

A practical rule: any step whose effect class is external must re-check the specific facts its decision depended on, immediately before acting, rather than trusting the plan's snapshot. On a long run the gap between planning and acting can be hours, and Chapter 1's horizon measurements are a reminder that hours is now the operating range.

What happens when a gate fails

A gate with no defined response is a log line. The response is part of the design and belongs in the plan artifact from Chapter 3.

Four outcomes cover nearly everything. Retry the step, valid only when the failure is transport rather than judgement, per Chapter 2's rule. Repair, where the gate's finding is specific enough to fix mechanically, such as a malformed field. Roll back to the last checkpoint and take a different branch, which is the normal case for internal state. Or escalate to a human with the gate's finding attached, which Chapter 10 designs properly.

The wrong response, and the common one, is to continue with a warning. A warning in a long run is an unread log entry, and the step that produced it becomes the premise for everything after.

One nuance about repeated failures. If the same gate fails three times on different steps, the problem is usually the plan or the tool rather than the step. Escalate on the pattern rather than only on the instance, and record both, because that pattern is the most actionable signal your system produces.

Measure the gates, not just the runs

Gate results are the instrumentation that makes the rest of this book empirical.

Record every evaluation: which gate, which step, pass or fail, what the comparison found, and what the response was. Passes matter as much as failures, because a gate that has never failed in ten thousand runs is either protecting nothing or checking the wrong property, and both are worth knowing.

Three readings come out of that data. Which steps fail most, which tells you where to spend the expensive gates. Which gates never fire, which tells you what to remove. And the failure rate by task length, which is the raw material for the horizon measurement in Chapter 11, computed from your own workload rather than inherited from a benchmark.

Anthropic's September 2025 tool guidance makes the adjacent point about tools: evaluate with realistic tasks and let the results drive iteration. The same loop applies to gates. They are a component with a measurable hit rate, and they should be tuned like one.

Chapter summary

A verification gate compares a step's claim against an independent source, and independence is the property that makes it work, which is why a model reviewing its own output is not a gate at all. Price each gate against the commitment it guards: schema checks for reads, read-back and invariants for reversible internal writes, provider confirmation for compensable external effects, and a second derivation or a human for anything irreversible. Reach for deterministic checks first, because counts, invariants, schema validation, read-back and diffing catch a large share of real failures in milliseconds, with the diff check catching the correct action applied to the wrong scope, which nothing else notices. Use a model as checker only for properties that are not mechanically checkable, and then give it the artifact without the reasoning, run it as a separate call, prefer a different model where stakes justify it, and demand a named violated criterion rather than a score. Gate preconditions as well as results, since a step that never runs is the only free recovery available, and re-check the specific facts an external step depends on immediately before acting, because hours can separate planning from execution. Define the response to every gate failure in the plan artifact, choosing between retry for transport failures, mechanical repair, rollback and branch, or escalation, and never the warning that nobody reads. Then record every gate evaluation, including passes, because the resulting data says where to spend expensive gates, which gates to delete, and what your own reliability horizon is.

Gates catch the wrong commitment when it is still inside your system. Chapter 6 is Compensating Actions and Safe Undo, which is about the case where the gate fails after the effect has already reached somebody else: what a compensation is, when a true inverse does not exist, and how to design steps so the irreversible part is as small and as late as it can be.