Two-Agent Loop Discipline: The additive bias of two-agent review loops

A personal one-page site of mine quietly grew, over several months, into something with admin authentication, invite gating, a runtime configuration API, session revocation, and an audit log. Each feature came through the same loop: I described what I wanted, Claude proposed a design, Codex reviewed it, I read both passes, and we shipped. Every individual round was reasoned. Every finding was defensible. Each addition looked, on its own, like the right call at the moment of review.

The cumulative surface, several months in, vastly exceeded the stated goal of the original page. The reversal — a deliberate subtraction pass that I ran across the project end-to-end — took nearly as much focused work as the drift had. None of the additions had been wrong individually; they were wrong only when summed. That last line is the one I keep coming back to, because it explains why the failure mode stayed invisible round by round. Two reviewers signed off on every step. Two reviewers were also why the surface kept growing.

I had assumed that a two-agent review loop would catch over-engineering early — that having one model propose and another model critique would naturally bias toward minimal viable design. The opposite turned out to be true. The loop converges on something, but the something it converges on is the maximum the two reviewers can agree to keep, not the minimum the goal requires. That is additive bias by construction, not by accident, and the three rules below exist to counter it.

Why the loop drifts

A two-agent loop reaches a stable resting point when neither agent has any remaining substantive disagreement with the other. That sounds like a healthy notion of convergence. It is not. "No remaining disagreement" rewards comprehensive coverage, not minimal viable design. Each round can add findings — new edge cases, new safety checks, new helpers, new abstractions — but no round can cleanly subtract scope; cutting something previously agreed would read as regression, the one direction the loop is structurally hostile to. So the design ratchets in one direction. Each individual ratchet is small. None of them, alone, justifies going back to first principles and asking whether the surface should be half its current size. The asymmetry compounds: a finding that adds is the reviewer doing their job; a finding that cuts is the reviewer reopening a settled question. The total drifts toward whatever the next reviewer is willing to accept, and the next reviewer accepts whatever survived the prior round. The maximum the reviewers can agree to keep becomes the new baseline. Subtraction never enters the prompt unless somebody puts it there explicitly.

Three rules

Scope budget

Declare the effort envelope in the design subject before the first review round: target hours of implementation work, maximum files touched, maximum new routes. Make the budget specific enough to be falsifiable; vague envelopes never trigger and never constrain the loop. If the loop's findings collectively exceed the budget, the design is wrong, not merely bigger than expected, and the response is to cut, not to extend the budget. A budget the loop is not bound by is a forecast, not a constraint.

Mandatory subtraction round

After the loop reaches a natural convergence point on coverage, run one additional round whose prompt contains only this: what can we cut? What's premature? What would a smaller version of this design look like — the one you'd ship if the deadline were halved? Convergence is valid only after this round either accepts cuts or explicitly affirms there are none. Without it, the design ships at the maximum weight the reviewers could agree to keep.

No abstractions for hypothetical second consumers

A function used once is just code. Three similar lines is preferable to a premature abstraction; the pattern is allowed to repeat until the third copy reveals the actual right shape. The hypothetical second consumer that justifies an abstraction now is the one that has not been written yet, and the abstraction designed for an imagined version will be wrong in the specific ways the imagined version could not have anticipated. Wait for the real second caller.

These three rules sit on the canonical policy page, Two-Agent Loop Discipline, alongside a credibility note and one sentence on the runtime that coordinates the two reviewers. This essay is the article-length account of why the rules matter; the policy page is where they live for reference. If you run two reviewers on solo single-feature work and have not yet seen this failure mode, the rules will look like engineering taste — until the first time the loop quietly drifts your design out of shape, and then they will look like the load-bearing constraints they are.