Build a Multi-Agent Review Loop, Not an Agent Swarm

One agent can propose, implement, and review a change.

For cheap, reversible work with strong tests, that is often enough.

The problem starts when the same context creates the proposal and judges it. Self-review can become self-explanation: the agent remembers why it chose an abstraction, then defends that choice instead of testing whether the abstraction should exist.

The fix is not an agent swarm.

Use a bounded review loop:

independent position -> shared evidence -> one disagreement -> explicit verdict

This guide shows when to add a second reasoning path, what each reviewer receives, and how the final authority closes the decision.

Add review where reversal is expensive

Use one agent when the answer is observable:

• the change is small
• rollback is cheap
• tests define success
• the downside is visible quickly

Add an independent reviewer when the decision contains a material judgment:

• architecture with high migration cost
• security-sensitive code
• destructive database changes
• research built on incomplete evidence
• launches with reputational downside
• operational changes whose failure may stay hidden

Independent does not mean uninformed.

Each reviewer should receive the same decision, constraints, artifacts, evidence, and acceptance criteria. The reviewer should not receive a persuasive summary of the proposer’s reasoning before forming its first position.

Roles need rejection conditions

Decorative job titles do not create independent analysis.

Weak:

You are a senior architect. Review this plan.

Better:

Identify choices that increase migration cost, operational coupling,
or recovery time. Recommend revision when the plan lacks a tested
rollback path.

Define roles by the question they must answer:

The proposer should not also play the breaker during the independent round.

Give every reviewer the same evidence packet

Several agents repeating one unsupported claim do not create corroboration.

Use explicit evidence labels:

• FACT: directly supported by an artifact or source
• INFERENCE: follows from evidence but is not directly observed
• ASSUMPTION: required by the argument and still unverified
• UNKNOWN: missing information that could change the verdict

Copy this packet:

DECISION
What exact choice or artifact is under review?
 
CONSTRAINTS
- technical boundaries
- time and budget
- security and compliance
- compatibility requirements
 
EVIDENCE
- FACT:
- FACT:
- INFERENCE:
- ASSUMPTION:
- UNKNOWN:
 
ACCEPTANCE CRITERIA
- approve when:
- revise when:
- reject when:
 
REVIEW BUDGET
One independent position.
One challenge round.
One verdict.

OpenAI’s Codex guidance emphasizes configured environments, reliable tests, clear repository instructions, and terminal evidence so reviewers can inspect what happened rather than trust a polished summary. OpenAI: Introducing Codex

The same rule applies here: shared evidence first, opinions second.

Force one useful disagreement

If reviewers see one another’s conclusions too early, they tend to converge around the first answer.

Protect the first position:

1. Restate the decision.
2. Produce independent analyses.
3. Extract the strongest conflicting claim.
4. Run one direct challenge.
5. Record final positions.
6. Issue the verdict without deleting dissent.

Ask:

POSITION
Approve, revise, reject, or experiment first.
 
STRONGEST CLAIM
The claim carrying most of your recommendation.
 
EVIDENCE
Label each point as FACT, INFERENCE, ASSUMPTION, or UNKNOWN.
 
FAILURE MODE
What breaks if your recommendation is wrong?
 
CHALLENGE
Dispute one specific claim from another reviewer.
State whether the conflict comes from evidence, interpretation, or values.
 
REVERSAL CONDITION
What new evidence would change your position?
 
NEXT ACTION
One action that reduces uncertainty or moves the work forward.

The reversal condition keeps the reviewer attached to a testable position instead of a persona.

Magnet: Three-Seat Review Loop

Start with three seats:

• Proposer
• Reviewer
• Decider

Add another reviewer only when a distinct risk deserves its own lens.

THREE-SEAT REVIEW LOOP
 
1. BOUNDARY
Write the decision in one sentence.
 
2. PACKET
Attach the artifact, constraints, evidence labels, unknowns,
acceptance criteria, and review budget.
 
3. INDEPENDENCE
Run proposer and reviewer positions separately.
 
4. CONFLICT
Extract no more than two claims that can change the verdict.
 
5. CHALLENGE
Run one response per claim with evidence and reversal conditions.
 
6. VERDICT
The decider chooses:
- approve
- approve with conditions
- revise
- reject
- experiment first
 
7. RECEIPT
Record the decision, decisive evidence, dissent, owner,
next action, and review date.

You should see: one narrow disagreement, one named authority, and a verdict that can be checked later.

Authority closes the loop

Agent count does not remove hierarchy.

The authority may be:

• a human operator
• a designated lead agent
• a deterministic policy gate
• a test suite for a narrow technical question
• a risk owner with explicit approval rights

The authority should not count votes. A majority can share the same weak assumption.

Evaluate each position against the acceptance criteria. Then issue a verdict containing:

• decision
• decisive evidence
• unresolved questions
• accepted dissent
• conditions or kill criteria
• next action
• owner
• review date

“Mixed feedback” is not a verdict.

Pick the smallest review shape

Cursor recommends parallel attempts for hard problems and isolates them with worktrees. That is useful for generating alternatives, but a review loop still needs a decision boundary and evaluation criteria. Cursor: Best practices for coding with agents

Parallel output is not the verdict.

FAQ

How many agents should review a decision?

Start with one independent reviewer. Add another only when it owns a distinct risk that the first reviewer does not cover.

Should reviewers see each other's answers?

Not before their opening positions. Share the strongest conflicting claims during the challenge round.

Can a test suite be the decider?

Yes, when the question is narrow and the tests fully represent the acceptance criteria. Product, risk, and business tradeoffs still need an accountable owner.

Failure modes

When not to use multiple agents

Do not convene a panel when:

• documentation can answer the question
• one test can settle the dispute
• no concrete artifact exists yet
• the change is cheap to ship behind a flag
• reviewers would share the same role and evidence

The cheapest method that resolves the uncertainty wins.

Your next action: use the Three-Seat Review Loop on one decision with expensive reversal cost.

For a ready-made implementation, use the Council of High Intelligence. For the wider operating system, open the Agent OS checklist.