Model Routing vs. Model Fusion vs. Subagents

“Multi-agent” gets used as one word for three different decisions: which model runs, whether several run in parallel, and whether a task gets its own context. Conflate them and you end up either paying for a five-model panel to answer a question one model could handle, or running five instances of the same model and calling the agreement a consensus.

They happen at different moments and solve different problems. Here’s the difference, a catalogue of twelve concrete patterns built from them, and a table for picking the right one instead of defaulting to “spawn more agents.”

Three Words People Use Interchangeably

Routing, fusion and subagents are not variations of the same idea.

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. Three subagents on the same model already gives you three isolated reads of a target, no model diversity required.

💡 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.

If you want the deepest worked example of that composition, a bounded jury of blind judges reviewing a frozen target, that’s its own article: The Bounded Agent Jury: A Pattern for High-Stakes Review.

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.

flowchart LR
    T["Frozen target"] --> J1["Judge A"]
    T --> J2["Judge B"]
    T --> J3["Judge C"]
    J1 --> L["Verdict sheet"]
    J2 --> L
    J3 --> L
    L --> F["Bounded fix"]
    F --> RS["Scoped re-review"]

Freeze a target, hand it to several blind read-only judges, classify agreement as confirmed, suspect or contradiction, fix only what’s confirmed. The default for risky code: auth flows, migrations, release gates. It doesn’t require different models per judge, isolation is the requirement, not model diversity, though correlated blind spots are the pattern’s main failure mode. Full pattern, six rules, and the exact prompt: The Bounded Agent Jury: A Pattern for High-Stakes Review.

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.

Four Ways Multi-Agent Setups Break in General

The jury-specific failure modes, correlated judges, anchoring, judge bias, are covered in the jury deep-dive. These four hit routing, fusion, cascades and every other shape in the catalogue above, regardless of whether a “judge” is involved at all.

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.

Short version: cheap decorrelation and cheap verification beat expensive orchestration. Add agents only after you’ve measured that the simpler version actually falls short.

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

The Takeaway

Routing, fusion and subagents answer three different questions: which model runs, whether several outputs get combined, and whether a task gets isolated context. Most real systems need at least two of the three, rarely all in the same call.

Default to the cheapest lever that solves the actual problem. Route when you know the difficulty upfront. Cascade when you don’t. Reach for a subagent when you need isolation, not a second opinion. Reach for fusion, several models on the same prompt, only when correlated blind spots are specifically the risk you’re paying to avoid, and even then, prove it against a single strong agent on real tasks before you ship it.

For the one pattern in this catalogue dense enough to deserve its own walkthrough, a bounded jury of blind judges, see The Bounded Agent Jury: A Pattern for High-Stakes Review.