← Index

Stage Gate Loops: Why Agent Verification Has to Move From the End to Every Transition

August 30, 2026

Loop engineering is what everyone’s talking about now. You don’t prompt agents anymore. You design systems that prompt them: scheduled automations, isolated worktrees, reusable skills, sub-agent hierarchies. The job of an agent engineer is increasingly the job of writing loops.

The shift got a name in June 2026. Boris Cherny, the head of Claude Code at Anthropic, put it blunt: “I don’t prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.” [1] Peter Steinberger, an OpenAI engineer, told developers to design the loops that prompt their agents. And Google engineer Addy Osmani gave the pattern its name: loop engineering, built on six primitives: automations, worktrees, skills, connectors, sub-agents, and memory. [2]

There’s a structural flaw in all of this. Nobody’s talking about it.

Verification comes too late.

Verification happens at the end

In the current model, the loop runs, the loop finishes, then you check. Or a sub-agent checks. Either way it’s post-hoc. The agent worked for ten minutes and only now do you find out whether any of it was worth something.

Addy flags this himself: “A loop running unattended is also a loop making mistakes unattended.” He’s right. It’s worse than he says.

Three things break when you verify at the end.

Token waste. If run 2 of 5 produces garbage, you still paid for runs 3, 4, and 5. The loop doesn’t know to stop. It keeps spending.

Self-grading blindness. The verifier is still an LLM. Same architecture, same blind spots. You swapped one confident guess for another.

No breakpoints. A fifteen minute loop that goes wrong at minute three runs for twelve more minutes before anyone knows. There’s no stop-the-line. Just blind momentum.

The fix: gates at every transition

Stage gate loops move verification from the end to every transition. Break the work into distinct runs. Every run ends at a deterministic gate. Not an LLM judging output. A tool that returns pass or fail. Schema validator. Test suite. Type checker. Build step. CI status.

Pass the gate, go to the next run. Fail the gate, stop. Fix what broke. Retry from that stage.

Here’s the shape.

RUN 1   discovery agent finds work
  GATE A   is the finding actionable?   (rule check)
RUN 2   implementation agent drafts the fix
  GATE B   does the schema validate?    (tool)
RUN 3   review agent checks the draft
  GATE C   do the tests pass?           (pytest)
RUN 4   connector opens the pull request
  GATE D   did CI go green?             (GitHub API)

Fail any gate. Stop the line. Fix what broke. Retry from that stage. Runs downstream of the failure never execute, so tokens aren’t spent on doomed work.

Why deterministic gates

An LLM can be talked into accepting bad output. A schema validator can’t. A type checker can’t. A test runner can’t.

That’s the whole point. “Seems right” versus “is right.” The gate has no opinion. It has a contract. The output satisfies it or it doesn’t. Zero amount of confident prose from the agent turns a red test green. The gate is mechanical.

LLM-as-judge research lays out the failure mode. Judges prefer longer outputs, they’re sensitive to prompt ordering, and they tend to agree with outputs that share the same model architecture. [3] The model writing the code is too nice grading its own homework. But the model grading it is an LLM too. You didn’t fix the problem, you moved it.

Token economics flip

Standard loop: run, run, run, verify. Wrong at the end? Burned the whole cycle.

Stage gate loop: run, gate, run, gate, run, gate. Gate B fails? You only paid for run 1 and run 2. Runs 3, 4, 5 never fire. Fix what broke at stage 2. Retry from there.

If you’re running dozens of loops a day, this isn’t marginal. It’s the difference between sustainable and lighting money on fire.

Inspectability stops being a feature. It’s just there. Gate C fails? You get the test output, the diff, the commit hash of everything that passed up to that point. You debug the pipeline without replaying the whole thing. This is basic CI thinking. You wouldn’t debug a failing deploy by rebuilding everything from scratch. You look at the stage that broke.

I built this the hard way

None of this is theory for me. I run agent loops in production and watched them fail quietly for a long time.

The system I built orchestrates multiple autonomous agents handling research, drafting, review, and publication on schedules. For a long while the verification model was the standard one: the agent finished its full run, then a separate review step checked the output.

The failure mode was consistent and expensive. An agent would spend seven minutes on a multi-stage task and the review step at the end would catch that the draft failed a basic schema check at stage two. Six minutes of downstream work, gone. Tokens burned. And the review step itself wasn’t reliable. Roughly a third of the time it missed failures a deterministic tool would have caught.

The fix was to insert gates between stages. After discovery, a rule check: is the finding concrete enough to act on? After drafting, a schema validator: does the output conform? After review, a test suite: do the integration tests pass? Each gate is a tool call, not an LLM call.

The token savings were immediate. A run that used to consume 12,000 tokens end-to-end now stops at 3,000 if it fails at stage two. And the failures that still happen are inspectable. The gate tells you exactly what went wrong and what output triggered it. You don’t replay the whole run to debug. You look at the breakpoint.

This became the grooting framework: GOAL, evals, tasks, execute, QA, reflect. The evals are the gates. Each eval is binary pass/fail. When a scheduled run fails at eval three, it doesn’t burn tokens on tasks four through seven. It stops at the breakpoint, fixes what broke, and resumes. The result was a measurable drop in failure rates. The loop stopped hoping and started verifying.

The system still uses LLMs for what LLMs are good at: generation, summarization, reasoning about ambiguous input. But the verification layer is deterministic. The gates don’t think. They check.

Nothing here is new. That’s the point

Stage gate loops are a recombination of ideas that have worked in manufacturing and software for decades. The common thread: quality is built in at every transition, not inspected in at the end.

Toyota’s Andon cord. A worker spots a defect, pulls the cord, the line stops. Fix it at the source. Quality isn’t inspected in after the car rolls off, it’s enforced at every station. Anyone can stop the line. The cost of stopping is lower than the cost of shipping a defect downstream. [4]

TDD’s red-green-refactor. Write the failing test, make it pass, clean up. The test is the gate. You don’t write all the code, then write all the tests at the end. [5]

CI/CD pipeline gates. Every commit triggers a build, a test suite, static analysis. Fail any gate and the change never reaches production. The gates are deterministic. No opinion, no confidence score. Pass or fail. [6]

NASA’s mission phase reviews. You don’t attempt landing if orbital insertion failed. Gated sequence, by design. [7]

Agents just didn’t have this yet.

The missing building block

Osmani’s six building blocks are all necessary. None of them are sufficient. What they lack is gates.

Without gates, the loop is a machine that runs itself but can’t stop itself. With gates, the loop stops being a prayer and starts being a pipeline. Quality enforced at every transition, not hoped for at the end.

Gate design is the new bottleneck

The trade-off is real. Moving verification to the gates makes gate design the critical skill.

Bad gates pass everything and catch nothing. A schema validator that accepts any shape, a test suite with no assertions, a lint step with every rule disabled. These aren’t gates. They’re decorations. A loop running on decorative gates is back to shipping slop silently.

Overly strict gates stall everything. A gate that rejects valid output because of an edge case in the validation rule creates the opposite waste. The loop never clears gate A. It’s not stopping garbage, it’s stopping everything.

Good gate design means understanding the failure modes of the system. What kinds of errors does this agent actually make? What does a false negative look like at this stage? What does a false positive cost? The answers are specific to the domain, the agent, the task.

There’s no general-purpose gate. There are only gates designed for specific failure modes by someone who understands the work. This is harder than writing a prompt. But it compounds. A well designed gate catches a class of errors forever. A well crafted prompt catches errors once, if you’re paying attention.

Where gates don’t apply

Not every agent task can be gated deterministically. When the output is prose, creative strategy, architectural judgment, or ambiguous input classification, there’s no mechanical check for correctness. A schema validator can’t tell you whether a blog post is compelling. A test suite can’t evaluate whether a system design is coherent.

That semantic layer stays probabilistic. This isn’t a weakness. It’s an acknowledgment of the boundary. The goal isn’t to replace every LLM review with a deterministic check. It’s to push the boundary out as far as it goes, and reserve probabilistic review for the remainder.

So in practice: gates handle the structural layer. Format compliance, link integrity, schema conformance, test passage, type safety, lint rules. Review handles the semantic layer. Tone, argument quality, strategic fit, creative merit.

By the time review happens, the structural failures are already caught. The reviewer isn’t wasting attention on JSON that doesn’t parse or tests that don’t pass. They’re evaluating whether the output is good, not whether it’s well formed.

Same trade CI/CD makes. A pipeline doesn’t prove your code is correct. It proves it compiles, passes tests, conforms to lint. Correctness is a higher bar and it stays a human responsibility. The pipeline just makes sure you aren’t spending human attention on failures a machine can catch.

The deeper pattern

Loop engineering moved the thing you optimize from prompts to systems. Stage gate loops move it again: from hoping the output is right to knowing it passed the checks.

The key move is substituting deterministic tools for LLM review. A schema validator isn’t smarter than an LLM. It’s more reliable at the specific thing it checks. Gates don’t guarantee correctness. They guarantee that known failure modes are caught at the point of origin, not the point of delivery. That’s enough to change the economics of running agents at scale.

Addy closes with a warning about loops: “Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all.”

Stage gates don’t solve the understanding problem. They make the difference visible.

One person’s loop hits Gate C and stops. Tests failed, output wrong, the gate caught it. The other person’s loop has no gates, or gates that pass everything. Slop accumulates silently.

Build the loop. Gate every stage. Stop the line when something breaks.

That’s how you earn the right to walk away while the agent is running.

---