Five agents reviewed your pull request. All five approved it. You feel good about the merge.
You shouldn’t. If those five ran the same model, read the same framing, and inherited the same context, you did not collect five opinions. You collected one opinion printed five times, with a confidence score attached that nobody earned.
Spawning subagents is the easy part. The hard part is deciding who sees what, how disagreement survives, what counts as evidence, and when the loop stops and asks a human. This article is one worked pattern for that problem, in depth: the diagram, the six rules, the exact prompt I paste into Claude Code, Codex or OpenCode, and the failure modes that make five agreeing agents worthless.
It’s one pattern pulled from a wider set of orchestration shapes, routing, fusion, cascades, panels, and more. If you want the full map first, see Model Routing vs. Model Fusion vs. Subagents.
The Claim That Needs Qualifying
The usual pitch for fusion is “the combined answer is better than any individual answer”. That is not guaranteed, and the failure is specific: aggregation is the bottleneck.
A synthesizer can average away the single strongest candidate. It can copy an error that two of the three models share. It can prefer the most confident prose over the most correct reasoning. A 2026 study across 42 tasks found judge-based selection substantially stronger than synthesis in its setup. One study is not a law, but the mechanism is easy to believe if you have ever read a merged answer that is fluent and subtly wrong.
So the real question is not “how many agents”. It is “what decision protocol turns their output into evidence”.
The Pattern Worth Stealing: A Bounded Agent Jury
This is the one I actually use. Freeze a target, hand it to three blind judges, and never let them see each other.
flowchart TB
T["Frozen target<br/>exact paths, diff or ADR"] --> J1["Judge A<br/>read-only, fresh context"]
T --> J2["Judge B<br/>read-only, fresh context"]
T --> J3["Judge C<br/>read-only, fresh context"]
J1 --> L["Coordinator builds the verdict sheet"]
J2 --> L
J3 --> L
L --> CF["CONFIRMED<br/>all three judges, severe"]
L --> SU["SUSPECT<br/>one or two judges only"]
L --> CO["CONTRADICTION<br/>cannot all be true"]
CF --> F["Fixer agent<br/>confirmed IDs only"]
F --> RJ["Re-judge<br/>verdict sheet + exact fix diff"]
RJ -->|"round 1 of 2"| L
RJ -->|"budget spent"| HU["Human decides"]
SU --> HU
CO --> HU
Six rules make it work:
- One immutable target. All three judges get identical scope. No “have a look around”.
- Blind and read-only. No judge sees another’s output, and none can edit. Detection and action are different jobs.
- All three results required. A partial jury is not a jury. If one judge fails, re-run it.
- Only the parent merges. Judges report findings, the coordinator classifies them.
- Fixers receive IDs, not narratives. The fix agent gets the confirmed list, not the reviewer’s prose.
- Two rounds, then a human. Every loop needs a terminal state.
Prompt: Judgment Day Lite
Review this frozen target: [exact paths / diff / ADR].
Spawn three read-only judge subagents in parallel, each with a fresh context.
Identical target, identical rubric. No judge may see another's work.
Rubric: correctness, security, edge cases, failure handling, performance,
testability, project conventions.
Each judge returns structured findings:
- severity
- exact location (file:symbol or file:line)
- observable claim
- concrete proof or reproduction steps
- confidence
Wait for ALL THREE judges. Then build a verdict sheet:
- confirmed: all three judges independently found the same severe defect
- suspect: only one or two judges found it
- contradiction: their conclusions cannot all be true
- info: non-severe suggestions
Do not average away dissent. Do not edit anything yet. Show me the verdict sheet.
If I approve fixes: pass ONLY confirmed IDs to a separate fix agent, then
re-run all three judges against the original verdict sheet plus the exact fix diff.
Maximum two fix/review rounds, then escalate what is left.
Blindness limits anchoring. Read-only permissions stop a reviewer from silently “fixing” what it just imagined. The proof requirement kills style-only findings. The round cap stops the self-perpetuating review loop where the critic invents new preferences forever.
Do the Judges Need to Be Different Models?
No. The pattern is defined by isolation, not by the model picker. Fresh context, no visibility into another judge’s output, no edit rights. Three subagents on the same model, each starting cold, already gives you three independent reads of the same target.
But independent context is not the same as independent reasoning. The stronger the shared model and shared framing, the more likely two “independent” judges converge on the same blind spot for the same reason, which looks like agreement and isn’t. That is the correlated-judges failure mode below, and it’s the real reason “spawn three reviewers” so often produces three copies of one opinion.
Model fusion, one judge per model family, is the strongest fix, because it changes the training data, the RLHF process and the failure modes behind each judgment, not just the prompt. It also triples your model bill and adds the slowest provider’s latency to your critical path. Cheaper decorrelation levers exist short of full fusion: vary the rubric emphasis per judge, vary the tools each judge can call, or point each judge at a different subset of context, logs for one, spec for another, prior incidents for a third.
Default to same-model subagents for routine review. Reach for a genuinely multi-model jury when the target is high-stakes enough that correlated blind spots are specifically the risk you’re paying to avoid: security boundaries, release gates, anything you can’t easily undo.
Confirmed, Suspect, Contradiction
Requiring all three judges to agree before auto-fixing is an AND gate. It buys precision and costs recall: a real bug found by only one or two judges does not get fixed. That is exactly why partial-agreement reports must stay visible as suspect instead of quietly disappearing.
Pick the gate on purpose:
| Decision rule | Optimizes | Use it for |
|---|---|---|
| Any judge flags it | Recall | Security triage, exploratory bug hunting |
| All judges flag it | Precision | Automated correction of severe findings |
| Majority of three or more | Stability | Binary answers with independent voters |
| Select the best evidenced candidate | Quality ceiling | Architecture proposals, solution tournaments |
| Contradiction goes to a human | Accountability | Irreversible or high impact decisions |
The four concerns stay separated: judges inspect, the coordinator classifies, a bounded fixer edits, and a human accepts residual risk. Most broken multi-agent setups collapse two of those into one agent.
Six Ways the Jury Breaks
flowchart LR
A["Same model"] --> C["Correlated errors"]
B["Same context"] --> C
D["Sees the first answer"] --> E["Anchoring"]
C --> F["Confident consensus,<br/>same blind spot"]
E --> F
- Correlated judges. Role labels do not create cognitive diversity. A 2026 preprint measured high similarity among same-model role-play committees and called it representational collapse: the personas changed the prose, not the reasoning. Vary model family, instructions, tools, sources or hypothesis. Better yet, require independent evidence.
- Anchoring and conformity. Never show a judge the first answer or another judge’s conclusion before its own pass. If you want debate, make it a short phase after independent commitments.
- Weak aggregation. “Summarize these answers” is not a decision protocol. Say whether the parent selects, votes, merges non-conflicting facts, preserves contradictions, or defers.
- Judge bias. Position, verbosity and self-preference. Anonymize, randomize order, use a rubric, demand proof.
- Infinite critique loops. Every loop needs a budget and a terminal state.
- False certainty from agreement. Homogeneous agreement is not a confidence estimate. Research on multi-agent debate found that majority voting explains most of the claimed gains, that extra discussion rounds can reduce performance, and that longer debates drift off the original problem. A 2026 study also found that homogeneous, conformist agents converge on biased group norms.
Short version: independent first passes, minimal interaction, explicit dissent, and evidence. Long free-form arguments between agents are where quality goes to die.
For the failure modes that hit routing, fusion and other subagent shapes instead, not the jury specifically, see Model Routing vs. Model Fusion vs. Subagents.
Prove It On Twenty Tasks
Before you add more orchestration, build a small eval set. Twenty representative real tasks is enough to show large differences.
For code review, build it from previously fixed production bugs plus clean diffs that must produce zero findings. Then run the same set through five configurations:
flowchart LR
E["20 real tasks"] --> C1["Strong single agent"]
E --> C2["Two same-model agents"]
E --> C3["Two heterogeneous agents"]
E --> C4["Jury + selection"]
E --> C5["Jury + synthesis"]
C1 --> M["Compare"]
C2 --> M
C3 --> M
C4 --> M
C5 --> M
Measure defect recall, false-positive rate, severe-issue precision, regressions introduced by fixes, human review time, token cost, wall-clock latency, and how often the system escalates. A pipeline that finds two more real bugs while adding thirty plausible-sounding false positives has made your review worse, not better.
The Takeaway
Stop asking how many subagents to spawn. Ask what decision protocol turns their output into evidence.
The smallest version that pays for itself: freeze one target, give it to three blind read-only judges, wait for all three, classify their findings as confirmed, suspect or contradiction, fix only what all three confirmed, re-check once, then escalate. That protocol fits in a single prompt and it beats a nine-agent swarm with no aggregation rule.
Orchestration quality matters more than agent count. Five agreeing agents are still one opinion if you built them that way.
This is one pattern out of a dozen worth knowing. For the full catalogue, including where a bounded jury fits against cascades, panels and mixture-of-agents, see Model Routing vs. Model Fusion vs. Subagents.