The generator–verifier gap: the asymmetry every agent loop is betting on.
Every autonomous loop you ship is a wager that checking an answer costs less than producing one, and where that wager is false the loop has nothing to converge against — no model upgrade rescues it. The gap between what it costs to generate and what it costs to verify is the quantity that should set your autonomy level, and the uncomfortable consequence is that an agent allowed to retry until it passes inherits the verifier's error rate, not the model's.
Verification is a different job, and it is usually — not always — the cheaper one.
Finding a route through a city is hard; checking that a proposed route is legal and arrives on time is easy. Writing a function that passes a test suite is hard; running the suite is a subprocess. That asymmetry is the load-bearing fact underneath almost everything that works in agentic systems, and it has a name worth using because it makes the design question explicit: for this task, how much cheaper is checking than doing?
"Verifier" is a broader family than people assume, and the members differ by orders of magnitude in cost and in trustworthiness:
- Exact oracles — a compiler, a schema validator, a type checker,
terraform plan, a unit test, a SQL query that either parses or does not. Cheap, deterministic, and they do not lie about what they check. They are also narrow: a passing test says nothing about the requirement nobody wrote a test for. - Sound checkers — a linter, a policy engine, a simulator, a physical constraint enforced below the agent. These reject a superset of what is truly wrong, which is the safe direction to be imprecise in.
- Learned judges — another model scoring the output. Cheap per call, available for anything, and the only one on this list whose errors correlate with the generator's, which is the property that makes it dangerous. See LLM-as-judge for agents.
- Humans — the most general verifier and the one whose cost does not fall when your traffic rises. Reviewer time is the budget that decides whether a workflow scales, which is why the cost of human review is an economics question before it is a quality one.
The gap is not a property of the model. It is a property of the task plus whatever instrumentation you were willing to build. Two teams pointing the same model at the same problem can have completely different gaps because one of them wrote the checker.
The loop only converges against a signal the agent did not author.
An agent loop is iteration: act, observe, revise. Iteration improves an answer only if the observation carries information the model did not already have. When the observation is the model's own opinion of its work, it usually does not.
This is the most replicated negative result in the area. Intrinsic self-correction — asking a model to review and revise its own answer with no external signal — does not reliably improve accuracy on reasoning tasks and frequently makes it worse, because the model that produced the error is the same model being asked to notice it. Extrinsic self-correction, where the revision is driven by a tool, a test, a retrieved document or a second party, works. The critical surveys of this literature land on a tidy summary: the tasks where self-review helps are the decomposable ones, which is precisely the class where verification really is easier than generation.
Two familiar systems are the same idea in undisguised form. Speculative decoding is the pure case — a cheap model drafts, the expensive model verifies, and because verification is a single forward pass over many tokens you get the speedup for free with provably identical output. Reinforcement learning with verifiable rewards is the training-time case: it works on maths and code because a checker exists, and it stalls the moment you point it at tasks where nobody can write one (RLVR and GRPO for agents). Same asymmetry, three layers of the stack.
The practical read: when you cannot make a loop converge, the first suspect is not the model's reasoning. It is that the loop is running blind — the agent is generating and grading in one head, and the number of iterations is just a budget being spent.
Retrying until it passes hands your error rate to the verifier.
Here is the part that surprises teams in production. Suppose your verifier accepts a wrong answer 5% of the time it sees one — a fairly good judge. A single-shot system with a 20% error rate ships wrong answers 20% of the time. Now let the agent retry until the verifier is satisfied. Every genuinely correct answer passes; every wrong answer that survives is a wrong answer the verifier waved through. The system's residual error is no longer governed by how often the model is wrong. It is governed by how often the checker is fooled, and the retry loop is searching for the inputs that fool it.
That is the same mechanism as reward hacking, arriving at inference time instead of training time (reward design and hacking). It has three immediate consequences:
- False accepts are the only verifier metric that matters for an agent allowed to iterate. False rejects cost you tokens and latency; false accepts cost you the incident. Report them separately and never behind a single accuracy number.
- Retry budgets are a safety parameter, not a performance one. Unbounded retries against a soft verifier converge on its blind spots. Bound the attempts and escalate rather than letting the loop grind.
- Independence is worth more than accuracy. A slightly weaker verifier that fails differently from the generator beats a stronger one that fails the same way — different evidence, different model family, different prompt, ideally a mechanism rather than a model. This is why a test the agent wrote is a much weaker check than a test it was handed.
Coding agents survive this because pytest cannot be sweet-talked, only gamed by editing the assertions — which is why every serious harness treats "the agent changed the test" as a separate, monitored event (patch generation and test-driven loops).
Set autonomy from the verifier you have, not the model you bought.
Use the gap as the decision rule it is. Before scoping a system, answer three questions and let the answers pick the shape:
- Is there a cheap, sound, independent check? Then the task is a candidate for real autonomy: run the loop, bound the retries, sample the accepted outputs to keep the false-accept rate honest. This is the regime where higher autonomy levels are defensible.
- Is verification possible but expensive — only a person can judge it? Then you have a throughput problem, not a capability problem. The design question is how to spend scarce review: batch it, sort by the agent's own uncertainty, and route the confident-and-checkable cases past the queue (human in the loop, uncertainty and calibration).
- Is verification genuinely as hard as generation? Open-ended strategy, novel research synthesis, tone. Then you are building a drafting tool with a human owner, and you should say so. Adding iterations here consumes budget and produces confidence, not correctness.
Most of the engineering leverage in agentic systems is in moving a task from the third bucket to the first, and almost none of that work is prompt work. It is writing the checker: a schema for an output that was prose, a simulator for an action that was irreversible, a reconciliation against a source of truth that arrives anyway, a golden set that turns a vibe into a measurement (evals).
Build the verifier before the agent. If you cannot state, in one sentence, what would tell you the agent's output is wrong — and how much that check costs — you do not yet have an agent task, you have a demo. And once the verifier exists, put its false-accept rate on the same dashboard as the agent's success rate, because after the first retry loop ships, that number is your quality.
Related: planning and termination for what tells a loop to stop, agent evaluation for grading the whole trajectory rather than one answer, and verifier-guided search for spending inference compute against a checker on purpose.