Two-Agent Loop Discipline

A personal one-page site quietly accumulated admin authentication, invite gating, a runtime configuration API, session revocation, and an audit log over the course of several months. Every individual feature was reasoned about, reviewed, and shipped without obvious objections. Each addition looked reasonable at the moment of its review, and no single one was indefensible. The cumulative surface vastly exceeded the stated goal of the original page, and eventually had to be unwound through a deliberate subtraction pass that removed most of what had been added during the prior months. The fix was nearly as much focused work as the drift. None of the additions had been wrong individually; they were wrong only when summed.

That additive drift is the dominant compounding failure mode of two-agent review loops on solo work. A two-agent loop has additive bias by construction: it converges when there are no remaining substantive disagreements between the agents, which rewards comprehensive coverage, not minimal viable design. Every round can add findings but cannot subtract scope. Each finding looks small in isolation. None of them, individually, justify going back to first principles. The total bloats toward an over-engineered surface that the next reviewer accepts as the new baseline. The three rules below are counterweights. They are not engineering taste; they are mechanical constraints designed to hold under the pressure of a converging review loop and to fail loudly when violated.

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 or endpoints or pages. Make the budget specific enough to be falsifiable by the finished design — vague envelopes never trigger. If the loop's findings collectively exceed the budget, the design is wrong, not merely larger than expected, and the default response is to cut, not to extend the budget after the fact. The budget is a sanity check applied before any review round, not a retrospective metric; without it, every round will add, because no round is anchored to a concrete number it could violate. A budget that the loop has not committed to violating is not a budget; it is a forecast nobody is bound by. Skip the budget only for pure factual reviews where no implementation follows from the design.

Mandatory subtraction round

After the loop reaches its natural convergence point on coverage, run one additional round whose prompt contains only this question: what can we cut? What is premature optimisation? What is YAGNI? What would a smaller, simpler version of this design look like — the one you would ship if the deadline were halved? Treat the subtraction round as a hard requirement, not a courtesy step. Convergence is valid only after the subtraction round either accepts cuts or explicitly affirms there are none to make. The round matters because it asks a question the converging loop will never ask itself. Without it, the design ships with whatever weight the loop accumulated — which, by construction, is the maximum the reviewers could agree to keep.

No abstractions for hypothetical second consumers

A function used once is just code. Do not extract a helper before a second caller exists in the codebase. Do not introduce an interface for a class that has exactly one implementation. Do not build a factory for something constructed in exactly one place. 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; the cost of three duplicates is low, while the cost of an early bad shape is paid forward indefinitely.

A private runtime coordinates Claude and Codex through deterministic handoff files between subtasks, which is what allows the discipline above to be enforced as a settled invariant rather than a per-task negotiation.

In practice

These rules emerged from months of daily private use across several coordinated repositories — a working multi-agent setup carrying real engineering work, not a synthetic experiment. The opening example is one observed failure mode: a tightly-scoped surface that drifted into many times its intended size across a long series of individually reasonable review rounds, until a deliberate subtraction pass returned it close to its original shape. The pattern repeated across several feature areas before the counterweights above were formalised in writing. The rules are artifacts of having to undo concrete additive drift more than once on real work, and they have held since the discipline was put in place.