Guide · Agents & Orchestration

When is fanning out to subagents worth it?

Published 1 August 2026

Fanning out means handing parts of a task to several subagents that run independently, then merging their results. It is the most over-applied pattern in agent design. It genuinely helps on a narrow class of problems and quietly makes everything else slower, more expensive and harder to debug.

What you actually gain

Fan-out buys you two things and no others:

  • Wall-clock time, when the subtasks are independent and each one is slow. Ten file searches in parallel finish in the time of the slowest — provided nothing serialises them. Per-minute token and request limits do exactly that: past your rate limit, ten "parallel" calls queue, and the wall-clock win collapses toward the sequential number while the token cost stays at fan-out level.
  • Context isolation, when each subtask would otherwise flood the parent's window. A subagent can read 40k tokens of logs and return three lines. The parent's window never carries the 40k — you still pay for those tokens once, inside the subagent, and they never enter the parent's cached prefix.

Context isolation is the underrated half. Most successful fan-outs are not about speed at all — they are about keeping noisy exploration out of the window where the real reasoning happens.

What it costs

  • Token multiplication. Every subagent re-pays for its own instructions and context. Five subagents is rarely five times one call; with setup overhead it is often eight.
  • Merge cost, paid by you. Independent workers produce inconsistent output: different naming, overlapping conclusions, contradictions. Someone has to reconcile that — either code you write or another model call you did not budget for.
  • Debuggability. When a sequential agent goes wrong you read the transcript. When a fan-out goes wrong you read five transcripts and try to work out which one poisoned the merge.
  • No shared learning. Subagent 3 cannot benefit from what subagent 1 discovered. If the subtasks inform each other, parallelism actively destroys information.

The decision test

Fan out only when all four hold:

  1. Genuinely independent. No subtask needs another's output. If you find yourself ordering them, they are not independent.
  2. Mergeable by rule, not by taste. You can state the merge as code: concatenate, take the union, pick the highest score. If merging requires judgement, you have moved the hard part downstream, not removed it.
  3. Each subtask is expensive on its own. Parallelising three cheap lookups adds orchestration overhead for nothing.
  4. Narrow, verifiable return. A subagent should return a small structured result you can validate. "Return the file path and line number" is fine; "return your analysis" is a merge problem in waiting.

Fail any one of the four and sequential is the better engineering choice, even if it feels slower.

Where it clearly wins

  • Search and survey. "Find every place this pattern occurs across these ten packages." Independent, cheap to merge, expensive per unit.
  • Bulk classification. Same prompt, many inputs, structured output. The merge is a concatenation.
  • Read-heavy investigation. Several subagents each digest a large document and return a short summary with citations. Context isolation is doing the work.
  • Independent verification. One agent produces, another checks against stated criteria, and the criteria — not the reviewer's taste — decide.

Where it clearly loses

  • Multi-file code changes. Edits interact. Two subagents refactoring two files that import each other will produce two locally correct, jointly broken diffs.
  • Anything with shared writes. Same file, same table, same branch — you have built a race condition with a language model in it.
  • Exploratory work. When the second step depends on what the first one found, parallelism throws away exactly the information that made the task tractable.
  • Tasks you cannot specify tightly. Vague instructions are survivable in a conversation, where you correct course. A subagent gets one shot and no feedback.

A worked comparison

Task: audit twelve API route files for missing auth checks.

Sequential: one agent reads all twelve. The context fills with route code by file eight; by file twelve the model is comparing against a degraded memory of the early files, and the report gets vaguer as it goes.

Fan-out: twelve subagents, one file each, each returning { file, hasAuthCheck, line }. Twelve small structured results, merged by code into a table. Cheaper per unit of trust and independently verifiable — you can spot-check any row. Note what "cheaper" means here: cheaper per verified result, not necessarily fewer tokens. Twelve subagents each re-pay for their own instructions, and none of them shares a cached prefix with the parent, so the raw bill can be higher even when the trust-per-token is better.

Now change the task to "refactor the auth checks into shared middleware". The same fan-out is the wrong tool: the twelve edits must agree on one interface, and nothing in the parallel design makes them agree.

If you do fan out, do it narrowly

  • Give each subagent a single task and a fixed output shape, and validate the shape when it returns.
  • Cap the fan-out width. Beyond eight or so, cost climbs faster than the time you save.
  • Set a per-subagent step or token limit, so one confused worker cannot spend the whole budget.
  • Treat a failed subagent as a normal outcome: return partial results and say which unit failed, rather than losing the batch.
  • Log every subagent's input and output separately. Without that, the merge is unauditable.

Where this fits

This is an orchestration decision, so it belongs with agent topology in the Agents part of the track. The judgement being tested is not whether parallelism is available but whether the subtasks are independent and the merge is mechanical — the same question that separates an orchestrator from a router.

Related in this track

Keep going