Reading Isn't Verifying — So I Cut the Agents That Only Read

Two months ago I argued that a new top-tier model means the disciplined move is to route down, not up. Last month I argued that Opus 5’s launch expired half the instructions in a lot of setups — the verify your work, double-check before answering scaffolding people wrote for weaker models, which is now a tax rather than a safeguard.

Both posts left me homework. The largest piece of scaffolding I own is a multi-agent harness that reviews and repairs code across my repos, and it is built almost entirely out of the thing Anthropic now tells you to delete.

So I went and deleted a lot of it. The redesign is freshly deployed, with far too few runs behind it to conclude anything — so this is not a results post. It’s a why post, and the interesting part is that the obvious conclusion was wrong. The correct one is narrower, and more useful.

Here is where it landed:

Verification that reads artifacts is near-worthless. Verification that executes code on inputs the producer did not choose is what catches escapes.

Which means the change is not less verification. It is fewer verifier agents and more execution.

The org chart I had accidentally built

The harness ran five agent classes per round. A reviewer filed a finding. A finding-critic tried to refute it before anyone acted on it. A fixer fixed what survived. A fix-critic audited the fix. A judge dispositioned the round. On a representative round — six review lenses across four file clusters, plus a cross-surface pass, 100 findings — that is 44 agent spawns.

Every one of those roles was added after a real failure. And every one of them, at the seams, performs the same physical act: it reads what the previous agent wrote and forms an opinion about it.

I had built an org chart and called it a verification architecture.

Anthropic said cut it. Anthropic also said it works.

The Opus 5 prompting guide opens the case: “Claude Opus 5 verifies its own work without being told to.” That much made the launch coverage. The sentence closing the same paragraph did not, and it is the one that named my system: “The same applies to legacy harness scaffolding that adds separate verification steps.”

The example instruction it offers for delegation is blunter still — “do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several” — and it notes the model “performs best when given the complete task specification up front and left to run.” A relay of narrow agents, each handed a slice, is the structural opposite of that.

Then there is Anthropic’s January 2026 post, When to use multi-agent systems (and when not to), which describes an experiment I could have taken dictation from: “In one experiment with agents specialized by software development role (planner, implementer, tester, reviewer), the subagents spent more tokens on coordination than on actual work.”

Reviewer, critic, fixer, fix-critic, judge. Same org chart, different job titles.

It names the mechanism, too. Split agents by problem type and “they engage in a ’telephone game,’ passing information back and forth with each handoff degrading fidelity.” And it gives the boundary rule that indicts the whole design: “Planning, implementation, and testing of the same feature share too much context.”

And then there is the part I could have quietly left out.

Both documents also say verifier agents work. A few sections above the delete-your-scaffolding line, the same Opus 5 guide reports that the model “coordinates teams of subagents well, with effective writer-verifier patterns and few cases of agents overwriting each other’s work.” The January post is more explicit still: it names the verification-subagent pattern as consistently effective across domains, and lists three conditions under which multi-agent earns its cost — context protection, parallelization, specialization.

So the honest summary is not Anthropic said cut it. It is: Anthropic said cut redundant self-checking, and separately said verifier agents work — two claims that sound contradictory and aren’t. What neither document tells you is which of your verifiers is which.

That question has an answer. It just isn’t an answer you can get by reading — which is precisely the mistake I went on to make.

The conclusion I almost drew, and why it was wrong

Here’s the part worth the post.

I already had an internal reading pointing the same direction, and it was wrong. It said the adversarial layers were near-saturated — the critics had gone long stretches catching nothing, so cut them.

My own design record retracted that before it could be acted on. A zero-catch streak against honest agents, it noted, is “consistent with an ungameable gate and with a gameable gate never yet attacked; the two are indistinguishable from the reject-rate column alone.” Every number behind the saturation claim came from a single run.

That is sharper than it first looks. A gate nobody has attacked has not been proven sound — it has been unused, and the reject-rate column cannot tell you which. The only instrument that separates the two is an attack.

So I ran one.

The measurement that falsified it

I commissioned an adversarial red team against my own verification stack: six attacks, each a plausible way for bad work to be dressed as good work. Four of them were these.

• A lookup wired to a production constant, so it returns the right answer without doing the work.
• An acceptance test weakened until it could no longer fail.
• An acceptance criterion narrowed by a skip until there was nothing left to assert.
• A report claiming the CLI was wired a way it was not.

All four passed every artifact-reading gate — builder contract, TDD receipts, fidelity contract, audit contract, judge contract. Five layers of scrutiny, four escapes. Each was caught by exactly one control: driving the production entry point on held-out inputs the producer never saw and could not anticipate.

So saturation was falsified. The layers weren’t useless — they were untested, and the test found holes. But look at which ones had been carrying the weight. Every gate that caught something ran something. Every gate that caught nothing read something.

That’s the redesign in one line, and it is emphatically not “the adversarial layers catch nothing, so delete them.” It is: the layers that catch nothing are the reading ones.

The harness manufactured a bug it later caught

The live evidence pointed the same way, from the other direction.

During a run against one of my sites, a fixer was told to “mirror the /about/ seam.” It copied the seam’s shape and not its validator, and shipped a javascript: injection into two live checkout buttons. A later audit caught it — by starting a local PHP server and curling the page. By executing.

That sounds like the system working. It isn’t. The harness manufactured that bug, for a specific and fixable reason: an orchestrator’s summary of a finding stood in for the finding itself. The fixer never read the artifact describing the seam. It read a sentence about it.

Which is how the highest-value change in the whole redesign turned out to be one missing sentence. My rules already required every agent to write its output to disk, precisely so nothing load-bearing lives only in a return value. There was no symmetric rule for reading. Every phase said an agent “receives” its inputs — language that quietly permits prose to stand in for the artifact.

The new rule: every spawned agent gets absolute paths to its source artifacts and reads them itself. A prompt may summarize for orientation, but it is never the only statement of a finding, an acceptance criterion, or an ownership boundary. Where prompt and artifact disagree, the artifact wins, and the agent reports the divergence.

One sentence, closing the seam that put a javascript: URL into production markup.

Three more things an org chart does to you

Nobody owns “done.” One finding took three fix attempts, each satisfying a different reading of what fixed meant — because who defines done, who does it, and who checks it were three different agents. That is the telephone game with a commit attached.

Volume impersonates coverage. Of the 100 findings filed in that run, 61 were below the severity threshold — noise, each consuming a verification pass. One lens filed 22 findings for 2 real hits. More readers produce more findings; that is a tautology, not a quality signal. Sub-threshold findings now register without a verification pass at all.

The judge’s best work was arithmetic. Its single most valuable contribution across the entire run was recomputing a count the orchestrator had got wrong. That is genuinely worth having — and it is a job for deterministic code, not an inference pass from an expensive model. So the arithmetic moved into a kernel that derives the round’s outcome from the artifacts and refuses any judge whose numbers disagree with it, and the agent kept only the judgment calls a function can’t make.

What survived — and why it’s the same line as last time

I kept the thing that most resembles what I cut, so the distinction has to be exact.

The most valuable finding of that run was a cross-surface inconsistency: two pages agreed with each other, and only the source manifest disagreed with both. No file-scoped reviewer could have found it — not through carelessness, but by construction. None of them had all three files in view.

That is breadth of evidence sources, not breadth of readers. On an org chart they look like the same move; in practice they are opposites. Widening what one agent can see is free coverage. Adding an agent to look at what the previous one concluded is a second opinion from the same source.

Which is the line I drew in the Opus 5 post, one level up. There it was about sentences: verification that consults an external source of truth stays, verification that asks the model to re-examine its own output goes. Here it’s about agents, and it resolves the same way. Evidence, keep. Second opinions, delete.

So mutation proofs stayed — break the fix, confirm the test goes red, revert. The held-out-input control got promoted from a technique buried in a list to a required element of every fix proof. And the coverage manifest stayed, because it is what makes “clean” mean nothing exists rather than nothing found.

What I am not claiming

The redesign went live this week, and it is early — a handful of runs, nowhere near enough to separate a real effect from noise. What follows is a baseline and a set of targets, not results.

The baseline is on the record: 100 findings filed, 39 at threshold, 32 fixed, 5 reopens, roughly 22 agents in one session, a 1,037-line ledger. The targets are reopens down, agents per session down materially, at-threshold confirmed findings at or above baseline, sub-threshold volume down. Agent classes are already down from five to three, and a representative round 44 spawns to 28 — but those are inputs, not outcomes.

One trap is written into the success criteria deliberately: a drop in confirmed findings alongside a drop in agents is ambiguous, not success. Fewer agents finding fewer bugs is what a good redesign and a broken one both look like from outside. The only thing separating them is evidence of what was actually examined — which is why the coverage manifest was never a candidate for the cut.

The audit, if you run a harness

Count your verification layers. For each one, ask a single question: does it run something, or does it read something another agent wrote?

The ones that run are your gates. The ones that read are your bill — and, worse, your false confidence, because a reading layer returns green whether or not it is capable of returning red. That is gate erosion arriving through the org chart instead of through a prompt, invisible for the same reason: nothing about it fails.

Then keep the epistemics honest, because this is where I nearly went wrong. A gate that has never caught anything isn’t proven useless — it’s untested, and reading it won’t tell you which, because that check has no way to notice when it becomes wrong. If you want to know whether a gate works, attack it. Mine took an afternoon and falsified an assumption I was ready to act on.

If you build with AI, that audit lives in your tooling — that’s the software-engineer track.

A verifier that only reads is a second opinion from the same source. If you want to know whether the code is right, run it — on inputs whoever wrote it never chose.