Two seats per task

The story

An agent building the first task of a recent plan did the work of a careful engineer. It wrote the tests first, watched them fail, made them pass, ran the whole suite, read its own diff and reported honestly, concerns included. One of the checks it added was meant to catch a forbidden word inside a page's address. The check could never fire. Addresses are joined with hyphens, and the pattern it reused forbade a hyphen on either side of the match, so the one place the check had to work was the one place it could not.

The agent's self-review did not see it. It had reused a pattern written for prose, where it was right, on addresses, without noticing the difference. Whatever it had misread when it built the code, it misread again when it reviewed it.

A second agent, given the task's brief, the builder's report and the diff, found the problem in its first pass, because the brief said in plain words where the pattern had to match and the reviewer read the pattern against that sentence. That is the whole argument for the shape we now use. Every task has two seats, and nobody sits in both.

The pattern

A fresh builder per task. The builder gets its task's brief, the interfaces it touches and the global rules of the project. It does not get the session's history, and it does not get the other tasks. It builds, tests, commits and writes a report. The report is a file, so the next seat reads evidence rather than a summary of evidence.

A fresh reviewer per task, before the next task starts. The reviewer gets the same brief, the builder's report and a single file holding the task's whole diff with context. It answers two questions separately: did the diff do what the brief asked, nothing more and nothing less, and is it well built. It is told not to trust the report, to verify claims against the diff, and to treat a rationale in the report as a claim like any other. The review is a gate: no Important finding, no next task.

Fixes go back to the builder; the re-review is scoped. When the reviewer finds something, the builder that wrote the code fixes it, because its context is intact. Then a scoped re-review checks only the findings and the fix diff. It marks each finding addressed or not, flags anything the fix broke, and is told not to wander into code the fix did not touch. Without that scope, each round discovers something new and the loop never closes. With it, most tasks need one round.

One whole-branch review at the end, then one fix wave. After the last task, a single reviewer on the most capable model reads the entire branch as a diff and asks what only the whole can show: do the tasks fit, does the posture hold end to end, which of the small findings parked along the way must be fixed before merging. If it finds things, there is one fix dispatch carrying the complete list, and one scoped re-review of that. Not one fixer per finding: each fixer rebuilds its context and re-runs the suite, so a wave of them costs more than the tasks did.

The coordinator never writes code. It dispatches, reads reports, packages diffs, rules on conflicts and keeps the ledger. The moment it fixes something itself, that fix has skipped review, and its own context fills with code it will re-read on every later turn. Its job is to keep the seats separate.

What this bought us is not that reviews find more bugs, though they do. It is that the findings arrive while the context to fix them still exists, and that a reviewer who was not in the room asks the questions the room had stopped asking. The bug in the story was caught exactly this way: the brief said the word must be found inside a hyphenated address, and a reviewer reading the pattern against that sentence saw in a minute that it never could be.

The cost is real. Each task spends a fresh context on building and another on reviewing. For a plan of seven tasks that is roughly fourteen contexts plus the final review. We spend it because the alternative is a branch that passes every task review and fails as a whole, and finding that out at the end is the expensive version.

Try it

For your next agent-built change, split it into tasks that each end with a testable deliverable. Run one agent per task with only that task's brief. Before starting the next task, run a second agent with the brief, the first agent's report and the diff, and ask it two questions: does this match the brief, and is it well built. Do not let it skip the first question because the second looks fine. Keep the two seats separate even when it feels slow. Especially then.