Ten Percent of Ten Percent: Why Independent Checks Beat Better Prompts

Here is the most useful thing we have learned operating a platform where agents write code, triage inboxes, extract orders, judge each other’s work and file their own tickets: you do not get reliability from a better prompt. You get it from a second check that fails differently from the first. A single model step that is wrong ten percent of the time is a fact of life at the frontier of what the model can do; you can move that number, but you cannot move it to zero, and the last few points cost more than everything before them. Put an independent check behind it that catches nine mistakes in ten and the pair is wrong one percent of the time. Put a third behind that and you are at a tenth of a percent. Every high-reliability discipline already works this way: two pilots, two sets of books, a redundant sensor that measures a different physical quantity. The arithmetic is not the insight. The insight is that the second check has to be actually independent, and most of the ways teams add checks to LLM systems quietly are not.

The Arithmetic, and the Catch

The multiplication only holds if the layers fail for unrelated reasons. Run the same model over the same prompt twice and ask it to “double check,” and you have not built a second layer; you have built the first layer with a slightly different random seed. When one checker shares the blind spot of another, the errors are correlated, and correlated errors do not multiply. Two checks at ten percent each, sharing most of their failure modes, land closer to eight percent than to one.

So the design question is never “how many checks?” It is “does this check fail in a way the previous one does not?” In practice we have found five kinds of layer that are independent enough of each other to multiply, and we try to make sure anything that matters passes through at least three of them.

Five Layers That Fail Differently

1. A second agent with a different job. The author of a change and the reviewer of a change have different incentives, different context and different failure modes, and that is as true of agents as it is of people. Our pull-request pipeline includes a reviewer agent that runs on its own small machine, sees only the diff and the validation results, and must return one of three verdicts: approve, request changes, or escalate to a human. It cannot see the author’s reasoning, so it cannot be talked into the author’s assumptions. Any failure in the process, including the reviewer timing out after thirty minutes, escalates rather than approves. The same pattern shows up inside our code-review workflows: every finding a reviewer raises is handed to a separate verifier agent whose only job is to try to knock it down before it reaches a person. The author’s blind spots, the reviewer’s blind spots and the verifier’s blind spots overlap much less than three passes of the same agent would.

2. Deterministic gates that cannot be persuaded. A model can be argued into almost anything. A type checker cannot. On our main repository, every pull request passes through fifteen separate automated checks before a human sees it: the type checker pinned to one version so it cannot drift, a coverage gate that requires a test file for every changed module, a migration-safety check, a lint over environment templates, a check that a prompt file and its database copy still agree, and a test-quality gate that rejects tests which merely assert the source contains the text you just typed. None of these has any judgment, and that is the point. Their failure modes are the failure modes of rules: they miss what nobody wrote a rule for. That is exactly the gap a model-based reviewer is good at, which is why the two multiply.

3. Structural guards that make the mistake impossible. Better than catching an invalid action is making it unexpressible. When we built the self-expanding state machine, we measured a model judging the business validity of proposed states blind, from the schema alone. It ran at roughly sixty percent accuracy, and the misses were systematic, not noise: rules like “a partial refund is only possible after shipping” are not inferable from a schema no matter how good the model is. Prompting harder did not fix it. One neutral paragraph of domain context helped a great deal, taking bug detection from about a fifth of cases to half. But the thing that took invalid admissions to zero was structural: we made the “add state” action illegal for any discovery the validator had already flagged. The blind loop over-admitted a dozen invalid states. The guarded loop admitted none, by construction. A guard like that fails only if the guard itself is wrong, which is a failure mode with no correlation at all to the model’s.

4. Blind evaluation against held-out truth. The layer teams skip most often is the one that checks the checkers. We run a model that scores how important each task on a board is, so that human attention goes to the right place. The second version of its rubric scored well on the thirty tasks we tuned it on and then collapsed on fifteen tasks it had never seen, from a rank correlation of 0.63 down to 0.38. The rubric had learned the sample, not the judgment. We only found out because the held-out set was pre-registered: the judge’s scores were written to storage, timestamped, before the human ranked anything, so nobody could tune toward the answer. Our knowledge-bank deduplication model taught us a harder version of the same lesson. When we changed how much of each candidate entry the model sees, a token-count measurement said the change was a pure saving. The behavioral evaluation against a truth set said it was quietly flipping healthy “update this entry” decisions into “create a new one.” And before we could believe that, we had to measure the noise floor: two identical passes of the unchanged configuration agreed with each other only seventy-eight percent of the time, so any single-digit gap between configurations was indistinguishable from chance until we ran enough cases to clear it. A checker you have not evaluated blind is a checker whose catch rate you are guessing.

5. A human at the gate, seeing one percent instead of ten. The last layer is a person, and the whole purpose of the layers before it is to make that person’s time count. For a chemicals distributor whose order desk we automated, an inbound email is classified, its order lines are extracted, and a customer-service representative approves the extracted order before it is submitted. After submission a second, independent verifier compares what was entered against what the customer actually asked for, and the corrections it produces are recorded with the dollars that were at risk: pre-ship corrections, verifier corrections, short shipments prevented. The representative does not review every field of every email. They review a proposal that has already survived extraction, validation and the model’s own uncertainty flags, and a machine checks their work afterwards. Each of those three catches a different kind of mistake, which is what makes the chain worth more than any one of them.

One Chain, End to End

Put the five together and here is what happens when one of our agents changes production code. The author agent writes the change and is required to write a test for every new branch of logic. The fifteen deterministic checks run. A reviewer or verifier agent reads the diff without the author’s context. A human approves the merge through a document review that records their exact words. A deploy runs, and a post-deploy check exercises the live site. And then a fleet of long-lived watcher agents reads the audit trails of the running system on a cadence, with an escalation path that forces a human to look when severity crosses a threshold. Six layers. We do not have a measured catch rate for each of them, and I would distrust anyone who claimed to. What we do know is that a failure reaching production is by definition one that every layer missed, and every such failure tells us which kind of layer was absent.

The clearest example we have of that rule is one we got wrong first. A weekly automation cleans up stale branches and the pull requests behind them. In one run it closed four pull requests whose linked tasks each carried an owner approval. The approvals were audio, transcribed, and no agent had ever read them. Our first fix was a prompt: “check whether the review contains an approval before closing.” It could not work, and it is worth being precise about why. The failure was an agent applying judgment to text it never fetched, and a prompt only changes the judgment. The fix that held was deterministic and orthogonal: classify the linked review by its status, which the system records whether or not anyone reads the content. If a human engaged at all, the branch is off limits, and if the record is missing the guard fails closed. We calibrated the predicate against the live population before shipping it, because the first version blocked nineteen of twenty-four open pull requests, and a guard that blocks everything is a guard someone turns off. Scoping it to the pull request’s own lifetime brought that to sixteen while still catching all four incident cases. When a layer fails, do not strengthen that layer. Add one that fails differently.

What a Layer Costs

None of this is free, and pretending otherwise is how teams end up with checks they quietly bypass. Every layer adds latency, tokens or human attention, so the ordering matters: deterministic checks first because they are cheapest and fastest, model-based review second, humans last and only on what survived. That ordering is the reason the person at the gate sees one percent of the mistakes rather than ten, which is the entire economics of running agents at volume. We wrote about the other side of this in The Human Attention Bottleneck: the constraint on an agent operation is never model throughput, it is how many decisions a human can make well in a day, and layered checks are how you spend that budget on the decisions that need it.

Two more rules about cost. A layer that catches nothing should be removed, and you only know that if it reports what it caught. Our deduplication gate, our order verifier and our pull-request guard all log every decision with the evidence behind it, so we can read the catch rate off the audit table instead of guessing. And a layer you cannot evaluate blind is a liability rather than an asset, because it will be tuned toward whatever it was last tested on, and it will be trusted in proportion to how careful it looks rather than how often it is right.

What We’ve Learned

Stop fighting for the last five points in the prompt. Past a certain quality, another independent layer is cheaper than another week of prompt work, and it keeps paying as the model underneath changes.

Independence is a design property, not a head count. Two passes of the same model over the same context is one layer. Ask of every check: what does it miss, and does the layer before it miss the same thing?

Rules where the rule is known, models where judgment is needed, humans where experts disagree. Encode the business convention deterministically. Give the model one paragraph of context and the ambiguous cases. Send a person only what is left.

Hold out, pre-register, measure the noise floor. A checker’s in-sample score is not information. Write down the prediction before the truth exists, and know how much two identical runs disagree before you believe a difference.

Guards that block everything get switched off. Calibrate a predicate against the real population, hold it to the regression floor and the precision ceiling at the same time, and log what it catches so the trade stays visible.

Every miss in production is the specification for the next layer. Not a stronger version of the layer that missed. A different one.