Fan three or four agents at the same diff and what comes back is a list you cannot act on as it stands. Some items are real, some are the same item twice, and at least one is confidently wrong in a way that takes a while to see. Running more agents does not tell you which is which.
In Agentic OS, the framework I maintain (github.com/KbWen/agentic-os), whatever a dispatched agent returns is a candidate, and the primary owes it a check before it counts. Its /govern-audit workflow, which audits the governance system itself, lets the sweep run single-agent or fanned out across subagents and qualifies the second immediately — subagents are optional acceleration, never a dependency. The step after the sweep is titled Verify before report (findings are hypotheses).
A run in July puts numbers on it. A sweep asked whether the framework’s own directives contradict each other, and the first census came back with eleven conflicts. A four-seat adversarial roundtable read behind it, refuted nine, and caught two proposed fixes that would have done more damage than the conflicts they answered.
Findings are hypotheses
A dispatched reviewer reads a slice of the system and reports what that slice supports. Dispatching one trades coverage for parallelism, so its output is a hypothesis about the whole. One row in the July census was a mandatory spec gate no validator accepts, which reads like a real defect and had in fact been raised and closed twice before, in two separate Work Logs, and carried forward since as binding precedent. A May record has the more physical version: a subagent reported a lost-update bug in the write guard, having seen two lock files and missed the wrapping lock that holds both; the lesson written from it notes that the agents even “reproduced” the false claims.
The remedies a fan-out proposes inherit the same partial view, which is the part a dispatch design has to budget for. Each of those two fixes added a heading to the Work Log template: ## Security Findings in one case, ## Lessons in the other. Both headings were bare presence tests somewhere else in the system. validate.sh greps for ## Security Findings at line 1691, and the guardrails file’s completion guard read a missing ## Lessons as proof the retro phase had not run. Ship either and the check goes permanently true for every log the template produces, which retires a live WARN and a live guard while leaving both sitting in the source, where a reader would assume they still fire. The template is not among the synthetic logs those checks are tested against, so no test would have contradicted the change.
The report that shipped carries eight findings, six of them surfaced by the roundtable rather than the sweep. The sweep itself produced eleven candidates and two survived. So the pass that reads behind the sweep did most of the useful work.
Every finding — from a subagent, a heuristic, or a hunch — has to be checked against the actual code path, reading both cited sides, before it may appear in the report at all. A false alarm that gets dropped is still written down, with its refutation attached. That second half is what keeps the ratio visible; without it a run reports two findings and nobody can tell how many it started with.
Agreement among same-vendor reviewers
All the sub-agents in an expert roundtable are the same model with shared training data and shared blind spots, the framework’s lesson file says, and the diversity of perspective is theatre. The case behind that line is from April 2026: four Claude instances agreed on a CRITICAL finding, a skill missing on the Antigravity path, and it was wrong. What settled it was file and head run against the two paths, which showed the dual-path stub design was intentional.
/review therefore asks for something a fan-out cannot supply on its own. For architecture-change and trust-boundary work it requires at least one external signal — a fetch of authoritative published sources, a different vendor through /ask-openrouter, or a human reading the diff — and a single-vendor roundtable does not count as one. Meeting that is not free. On the July scan six free-tier models failed across two /ask-openrouter attempts and a paid one needs the user to confirm the spend, so the seats stayed same-vendor, which the report records as a property of the evidence alongside the findings themselves.
This blog runs a separate multi-agent pipeline over prose. A Chinese-language post that three same-family reviewer panels had cleared went to a cross-family blind reader, which flagged nine sentences. One fix round took that to four, then to zero. The note in the ledger is that same-model reviewers rate the house cadence as good because they would have written it that way.
Who is allowed to write
When /review dispatches an adversarial reviewer, that reviewer has to be a fresh Task() instance. The workflow’s reason is one line: same-context review is confirmation bias by construction. Reusing the implementing agent’s session, memory or transcript is prohibited, and so is passing along the reasons behind the diff. What the reviewer gets is the diff, the spec and acceptance criteria, and the relevant standards, and it works out from those whether the code is right.
The write side is drawn tighter. Under subagent_policy: read-only, the framework’s default, subagents fan out and return evidence while the primary stays the sole Work Log writer, gate owner and emitter of the runtime sentinel; the opt-in governed policy hands over some of that but keeps Work Log writes primary-only. Part of the reason is mechanical: the Work Log lock runs in blocking mode, every phase entry calls recover_worklog_lock.py ensure, and parallel shims on one branch all call it at once — the first wins, the rest exit 2, the gate fails. Read-only sidesteps that collision without touching the lock, because subagents never acquire it. This blog’s pipeline met a smaller version of the same boundary: workflow agents wrote their whole report into a field meant to hold a file path, and the rule that came out was to take the path from the workflow’s stamped return, never from the model.
Any fan-out reaches the same fork. Many agents may touch the record, or many agents may look and one may write. Agentic OS took the second, because a single writer keeps the record from disagreeing with itself. Taking the first needs something the declaration does not supply. read-only is observed by the primary and its subagents rather than enforced, and the lock was never a write guard; the framework defers the lock change until a downstream project actually wants its subagents to write. What that branch wants is a check at the point of the write, one that can name who owns a write and tell a primary apart from something the primary spawned.
Further reading
- No evidence, no completion — the same rule pointed at the agent’s own report instead of at a reviewer’s
- How Claude Code’s Dynamic Workflows Run 1,000 Subagents — the runtime side of large fan-out, and cross-examination encoded as a script
- Token Economics of AI Agent Governance — what decomposition costs, which this post leaves alone
- Why AI Agents Fail in Production — the gap taxonomy behind the write boundary

