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 about that part, with a diagram for every workflow and prompts you can paste into Claude Code, Codex or OpenCode today.
Three Words People Use Interchangeably
Routing, fusion and subagents are not variations of the same idea. They happen at different moments and solve different problems.
Model routing: pick one model, before generating
A classifier looks at the request and sends it to exactly one worker. Nothing is combined, because only one thing ran.
flowchart LR
T["Task"] --> C{"Classifier"}
C -->|"architecture, tradeoffs"| M1["Deep reasoning model"]
C -->|"apply the diff"| M2["Fast, cheap model"]
C -->|"low confidence"| H["Fallback / human"]
M1 --> O["Answer"]
M2 --> O
H --> O
Routing is not only a cost trick. You can route for latency, tool compatibility, context window, privacy, or provider availability. OpenRouter’s Auto Router picks a primary model plus fallbacks based on task type, capabilities and cost.
Model fusion: run several, then combine
The same prompt goes to several models in parallel. Another layer reads all the answers and produces one.
flowchart LR
P["Prompt"] --> A["Model A"]
P --> B["Model B"]
P --> C["Model C"]
A --> AN["Analyst layer"]
B --> AN
C --> AN
AN --> R["One fused answer"]
OpenRouter’s default Fusion pipeline is a three model panel plus an analyst plus an outer response. That is roughly four to five times the cost of a single completion on the same prompt. You are buying coverage, and you are paying for it in tokens and in time to first token.
Subagents: separate contexts, not separate models
A subagent is a fresh working context with its own role, tools, permissions, task and return contract. It can run the same model as you. The value is isolation, not the model picker.
flowchart TB
M["Main thread<br/>your context, your history"] -->|"bounded task + rubric"| S["Subagent<br/>fresh context, read-only tools"]
S -->|"structured findings only"| M
M --> D["You decide"]
That third diagram is the one people skip. A subagent is a context engineering tool first. It explores noisy territory and hands back a compressed result, so your main thread never swallows 40k tokens of grep output.
💡 These three compose. Route a task to a security specialist, run it on a cheap model first, and only convene a multi-model jury when the cheap pass finds something high risk.
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 two 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"]
J1 --> L["Coordinator builds the ledger"]
J2 --> L
L --> CF["CONFIRMED<br/>both judges, severe"]
L --> SU["SUSPECT<br/>one judge only"]
L --> CO["CONTRADICTION<br/>cannot both be true"]
CF --> F["Fixer agent<br/>confirmed IDs only"]
F --> RJ["Re-judge<br/>ledger + 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. Both judges get identical scope. No “have a look around”.
- Blind and read-only. Neither judge sees the other’s output, and neither can edit. Detection and action are different jobs.
- Both 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 two read-only judge subagents in parallel, each with a fresh context.
Identical target, identical rubric. Neither may see the other'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 BOTH judges. Then build a ledger:
- confirmed: both judges independently found the same severe defect
- suspect: only one judge found it
- contradiction: their conclusions cannot both be true
- info: non-severe suggestions
Do not average away dissent. Do not edit anything yet. Show me the ledger.
If I approve fixes: pass ONLY confirmed IDs to a separate fix agent, then
re-run both judges against the original ledger 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.
Confirmed, Suspect, Contradiction
Requiring both judges to agree before auto-fixing is an AND gate. It buys precision and costs recall: a real bug found by only one judge does not get fixed. That is exactly why single 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 |
| Both of two 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.
The Catalogue: 12 Patterns, One Diagram Each
You already know the generic workflow shapes from Agentic Design Patterns. These are the same shapes seen from the subagent side, with the failure mode that actually bites.
1. Task or model routing
flowchart LR
In["Request"] --> R{"Router"}
R --> W1["Frontend agent"]
R --> W2["Backend agent"]
R --> W3["Docs agent"]
W1 --> Out["Result"]
W2 --> Out
W3 --> Out
- Use for: cheap vs expensive model selection, specialist agents with different tools.
- Breaks when: a wrong route hides the worker that would have succeeded.
- Fix: log the chosen route, allow escalation, and evaluate the router separately from the workers.
2. Cascades and escalation
flowchart LR
In["Task"] --> Cheap["Cheap agent"]
Cheap --> G{"Tests + types + lint pass?"}
G -->|yes| Done["Ship"]
G -->|no| Strong["Strong agent, full context"]
Strong --> G2{"Pass?"}
G2 -->|yes| Done
G2 -->|no| Human["Human"]
- Use for: lint fixes, routine refactors, doc extraction, simple classification.
- Difference from routing: routing guesses difficulty before running. A cascade escalates after observing failure.
- Rule: escalate on objective signals only. Failing tests, schema violations, unresolved static analysis. Never on “the agent sounded unsure”.
3. Sectioning (map–reduce)
flowchart TB
T["Large target"] --> S1["Worker: module A"]
T --> S2["Worker: module B"]
T --> S3["Worker: module C"]
S1 --> I["Integrator: cross-boundary pass"]
S2 --> I
S3 --> I
I --> Out["Merged result"]
- Use for: one reviewer per changed file, one migration worker per package, one researcher per source family.
- Breaks when: the defect lives between partitions and nobody owns the seam.
- Fix: the integrator node is not optional. Its only job is interactions.
4. Specialist panel
flowchart TB
D["Same diff"] --> A["Security lens"]
D --> B["Correctness + races"]
D --> C["Performance"]
D --> E["Test gaps"]
A --> M["Merge + dedupe by root cause"]
B --> M
C --> M
E --> M
M --> V["Verify severe claims"]
Different rubrics on the same artifact. Do not vote here: each specialist owns different evidence, so a “majority” is meaningless.
Review this branch against main using read-only subagents.
Spawn one specialist per lens, in parallel:
- correctness and regressions
- security and trust boundaries
- concurrency and state transitions
- test gaps and flaky behavior
- maintainability, only where it creates concrete risk
Every finding must include exact file/symbol references, impact, and either a
reproduction or a deterministic argument. Wait for all specialists.
Merge and deduplicate by root cause. For each high-severity finding, spawn a
fresh verifier that sees only the diff and the claim, never the original
reviewer's reasoning. Mark it confirmed only if the verifier reproduces it.
Return confirmed and unconfirmed findings in separate sections.
Five specialists beat five generic reviewers, because role separation produces coverage diversity instead of five copies of the same scan.
5. Self-consistency (voting)
flowchart LR
Q["Question"] --> S1["Sample 1"]
Q --> S2["Sample 2"]
Q --> S3["Sample 3"]
S1 --> N["Normalize answers"]
S2 --> N
S3 --> N
N --> V["Majority vote"]
- Use for: discrete, checkable answers. Which config value. Which enum. Which of three files owns this behavior.
- Breaks when: samples are correlated, which makes the vote look far more certain than it is.
- Not for: architecture trade-offs. There is no unique label to converge on.
6. Best-of-N plus selector
flowchart TB
P["Frozen problem + constraints"] --> P1["Proposal 1"]
P --> P2["Proposal 2"]
P --> P3["Proposal 3"]
P1 --> AN["Anonymize"]
P2 --> AN
P3 --> AN
AN --> S1["Selector A"]
AN --> S2["Selector B, reversed order"]
S1 --> D{"Same winner?"}
S2 --> D
D -->|yes| W["Selected proposal"]
D -->|no| H["Preserve dissent, ask human"]
Selection keeps an excellent candidate intact. Synthesis dilutes it into a hybrid that nobody designed.
We need an architecture for [problem]. Freeze the constraints first.
Spawn three proposal subagents in parallel, working independently:
1. simplicity and delivery speed
2. scalability and operability
3. security and failure containment
Each returns one complete proposal, its trade-offs, failure modes, migration
cost, and the conditions under which it should NOT be chosen. They may not
read each other's proposals.
Anonymize the proposals. Spawn two selector agents with the same weighted
rubric: team fit 30%, correctness 25%, operational risk 20%, delivery cost
15%, reversibility 10%.
Each selector scores every proposal criterion by criterion, cites evidence,
and picks one. Run a second pass with the proposal order reversed. If the
selectors disagree, or the ranking flips after reversal, keep the
disagreement and ask me. Do not invent a fourth hybrid architecture.
⚠️ LLM judges have documented position, verbosity and self-preference biases. Anonymize candidates, reverse the order, and demand criterion-by-criterion evidence. Otherwise you are measuring writing style.
7. Mixture-of-Agents (layered fusion)
flowchart TB
P["Prompt"] --> A1["Proposer 1"]
P --> A2["Proposer 2"]
P --> A3["Proposer 3"]
A1 --> G1["Aggregator layer 1"]
A2 --> G1
A3 --> G1
G1 --> G2["Aggregator layer 2"]
G2 --> Out["Final draft"]
- Use for: broad drafting where combining complementary material genuinely helps.
- Breaks when: the aggregator is weaker than the best proposer. Diversity gets erased and you paid 5x for it.
- Rule: never ship a fusion pipeline without comparing it to a strong single-agent baseline.
8. Blind dual review (the agent jury)
flowchart LR
T["Frozen target"] --> J1["Judge A"]
T --> J2["Judge B"]
J1 --> L["Ledger"]
J2 --> L
L --> F["Bounded fix"]
F --> RS["Scoped re-review"]
Covered above. This is the default for risky code: auth flows, migrations, release gates.
9. Proposer–critic (evaluator–optimizer)
flowchart LR
Gen["Creator agent"] --> Art["Artifact"]
Art --> Crit["Critic agent<br/>explicit criteria"]
Crit -->|"fails rubric"| Gen
Crit -->|"passes or budget spent"| Out["Done"]
- Use for: docs, tests, translations, code with clear quality criteria.
- Breaks when: the loop is unbounded and starts optimizing toward the critic’s stylistic taste.
- Fix: a written rubric and a hard iteration budget. Two rounds is usually enough.
10. Competing-hypothesis debugging
flowchart TB
S["Symptom, no code edits"] --> I1["Investigator: state / race"]
S --> I2["Investigator: API / data contract"]
S --> I3["Investigator: env / cache / config"]
I1 --> R["Rank by reproducible evidence"]
I2 --> R
I3 --> R
R -->|"none supported"| I4["Fourth investigator:<br/>find the missing hypothesis"]
R -->|"one supported"| Fix["Fix + regression test"]
Assigning different hypotheses is the trick. Telling three agents to “find the bug” gets you three walks down the same path.
Investigate [symptom]. Do not edit code.
Spawn three investigators in parallel:
- one assumes a state or race-condition bug
- one assumes an API or data-contract bug
- one assumes an environment, cache or configuration bug
Each investigator must:
1. trace the relevant execution path
2. state a falsifiable hypothesis
3. design the smallest discriminating experiment
4. run safe diagnostics where possible
5. report evidence FOR and AGAINST its own hypothesis
Wait for all three. Rank by reproducible evidence, not by confidence or
writing quality. If none is supported, spawn a final investigator whose only
job is to find the hypothesis nobody proposed, using the combined negative
evidence.
11. Red team, blue team, verifier
flowchart LR
B["Builder / defender"] --> Art["Code + boundaries"]
Art --> RT["Attacker: find violations"]
RT --> VF{"Verifier reproduces it?"}
VF -->|yes| Fix["Fixer + regression test"]
VF -->|no| Drop["Discard the claim"]
- Use for: authorization boundaries, prompt injection, secret handling, abuse cases.
- Breaks when: the attacker’s persuasive narrative gets accepted without reproduction.
- Rule: tool evidence outranks judge confidence. Always.
12. Tree or graph search over candidates
flowchart TB
Root["Problem"] --> C1["Candidate step A"]
Root --> C2["Candidate step B"]
C1 --> E{"Evaluate + prune"}
C2 --> E
E -->|"keep A"| A2["Expand A"]
E -->|"prune B"| X["Dropped"]
A2 --> Final["Selected path"]
- Use for: hard planning where an early choice locks in very different downstream paths.
- Breaks when: the value function is weak, and you burn a combinatorial budget on nothing.
- Reality check: for most coding work, a cascade plus a jury is cheaper and good enough.
Where This Runs Today
| Tool | Capability | Practical note |
|---|---|---|
| Claude Code | Custom subagents, agent teams, dynamic workflows | Subagents for focused return-to-parent work, teams when peers must talk, workflows when the orchestration itself should be repeatable in code |
| Codex | Natural-language parallel delegation, custom agents with their own model, reasoning effort, tools and permissions | Say explicitly “spawn one agent per point and wait for all of them”. Parallel reads are safe, parallel writes are not |
| OpenCode | Primary and subagent roles, model per agent, permissions, nested depth | Ships general-purpose, read-only explore and docs-oriented scout agents out of the box |
If you want the coordinator itself to run unattended across worktrees, that is a different layer. I wrote about it in How to Orchestrate Multiple AI Agents with Orca.
Anthropic’s own numbers are worth keeping in mind: their multi-agent research system beat the single-agent baseline on breadth-first research, and used about 15x the tokens of a normal chat. They also warn that coding tasks parallelize worse than research does.
💡 Use subagents to buy independent context, coverage, or wall-clock time. Not because “more agents” sounds advanced.
Ten Ways This 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.
- Parallel write conflicts. Parallelize reads and reviews first. If several agents must edit, give them disjoint ownership or isolated worktrees plus one designated integrator.
- Lossy handoffs. Big outputs should persist as artifacts with lightweight references, not get re-summarized through a coordinator in a game of telephone.
- Cost blindness. Record tokens, wall-clock time, agent count, model mix and outcome quality. Compare every fancy pipeline to one strong agent.
- No ground truth. For code, executable evidence beats votes: tests, type checks, linters, scanners, traces, browser reproductions.
- 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.
Pick the Pattern
| Situation | Pattern | Aggregation | Stop rule |
|---|---|---|---|
| Routine task | One agent, cheap route | None | Deterministic check passes |
| Unknown difficulty | Cascade | Escalate on failed check | Strong agent succeeds, or human |
| Large divisible target | Map–reduce | Integrator summarizes | All partitions plus boundary pass |
| PR with several risk domains | Specialist panel | Dedupe, then verify severe claims | All lenses returned, high risks verified |
| Discrete reasoning answer | Self-consistency | Majority vote | Quorum or sample budget |
| Several complete designs | Best-of-N + selector | Pick one, preserve dissent | Stable ranking or human tie-break |
| Complementary long-form drafts | Mixture-of-Agents | Synthesis | One or two layers, eval beats baseline |
| High-risk code or decision | Blind jury | Confirmed / suspect / contradiction | Bounded rounds, then escalate |
| Output improves under feedback | Evaluator–optimizer | Revision loop | Rubric passes or budget spent |
| Hard-to-reproduce bug | Competing hypotheses | Select by runtime evidence | Reproduced or search space exhausted |
| Security boundary | Red / blue / verifier | Accept reproduced findings | Exploit reproduced, fixed and tested |
| Branching planning problem | Tree or graph search | Judge prunes | Budget or confidence threshold |
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 two blind read-only judges, wait for both, classify their findings as confirmed, suspect or contradiction, fix only what both 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.
Sources and Further Reading
- Building Effective AI Agents (Anthropic)
- How we built our multi-agent research system (Anthropic)
- Claude Code subagents
- OpenRouter Auto Router and Fusion
- Self-Consistency Improves Chain of Thought Reasoning
- Self-Refine: Iterative Refinement with Self-Feedback
- Tree of Thoughts and Graph of Thoughts
- Mixture-of-Agents Enhances Large Language Model Capabilities
- RouteLLM: Learning to Route LLMs with Preference Data
- Related reading here: Agentic Design Patterns and How to Orchestrate Multiple AI Agents with Orca