The pitch for subagents sounds like parallelism: split the work across ten agents, finish ten times faster. That is the least interesting reason to do it, and chasing it is how teams end up with distributed systems problems on top of the LLM problems they already had.
The better reason is quieter. When a subagent reads forty files and returns three sentences, the parent agent never sees the forty files. The context stays clean. That is worth more than the wall-clock saving in almost every real deployment.
What changed in 2026
- Delegation moved from framework feature to platform primitive. Spawning a sub-task used to mean orchestration code you owned; it is increasingly something the agent runtime handles, which changes the cost of trying it.
- Model tiering inside a single workflow became normal. Running the orchestrator on a strong model and the readers on a cheap one is now a standard shape rather than a clever optimisation.
- The context argument overtook the speed argument. As windows grew, the binding constraint shifted from "will it fit" to "is it full of noise", and subagents turned out to be a good answer to the second question.
- Isolation guarantees got attention. Running subagents against separate working copies rather than a shared one stopped being optional once people started letting them write files.
When fan-out pays
| Situation |
Fan out? |
Why |
| Audit 30 files for one pattern |
Yes |
Independent, read-heavy, returns small |
| Research 5 unrelated questions |
Yes |
No shared state, results merge cleanly |
| Refactor with a shared interface |
No |
Every worker needs the others' decisions |
| One ambiguous, exploratory task |
No |
Needs conversation, which subagents cannot have |
| Migrate 200 call sites mechanically |
Yes |
Uniform, verifiable, parallel by nature |
| Debug an unfamiliar failure |
No |
Serial by nature; each step informs the next |
The pattern in the "yes" rows: the work decomposes cleanly, each piece can be described completely up front, and the results combine without negotiation. The pattern in the "no" rows: the pieces depend on each other, or the task specification is discovered rather than known.
The brief is the whole job
A subagent gets one shot. It cannot ask what you meant, cannot see the conversation that led here, and cannot check whether its interpretation matches yours. Whatever the prompt says is the entire world.
This is the part teams underestimate, because in a chat interface ambiguity is cheap — the model asks, you clarify, everyone moves on. Delegate the same ambiguous instruction and it comes back as finished work built on a wrong assumption, which is considerably more expensive than a question.
Three things reliably improve a brief. State the output shape explicitly, including what not to include; a subagent that returns its full reasoning defeats the context-isolation purpose entirely. Supply the context it needs rather than a pointer to where the context lives, because a subagent that has to go find things spends its budget searching. And name the failure case — what it should return if the thing it is looking for does not exist — or you will get a confident invention instead of an honest nothing.
Structured returns help more than prose here. A subagent that must fill a defined schema cannot ramble, and the parent can merge results without parsing.
Cost, and where the money actually goes
The naive model says ten subagents cost ten times one call. The real accounting is less obvious in both directions.
Subagents are more expensive than expected because each one carries its own system prompt, its own tool definitions, and its own reasoning overhead before it does any useful work. Ten small tasks pay that fixed cost ten times.
They are less expensive than expected because the parent never ingests the raw material. An orchestrator that receives ten short summaries instead of ten long documents runs its subsequent turns against a fraction of the context — and in a long session, that compounds across every remaining turn.
Which effect dominates depends on how read-heavy the leaves are. Subagents that consume a lot and return a little are where the architecture earns out; subagents that consume a little and return a lot are usually a mistake. The per-task figures in AI agent cost per task are a reasonable place to sanity-check your own numbers, and agent cost attribution covers how to see the split once you are running it.
Common mistakes
- Fanning out work that is not independent. Subtasks that need each other's output serialise anyway, and you have paid coordination cost for nothing.
- Vague briefs. The single largest cause of bad subagent output. It cannot ask, so it guesses.
- Letting subagents return everything they read. This reintroduces the exact context bloat the architecture exists to prevent.
- Shared mutable state without isolation. Parallel agents writing the same files produce conflicts that are painful to diagnose after the fact.
- No per-subagent tracing. When one of twelve returns nonsense, you need to see its actual inputs and output. Aggregate logs will not tell you which one.
- Re-delegating from inside a subagent. Uncontrolled nesting turns a bounded fan-out into an unbounded tree. Cap the depth, usually at one.
- Using a cheap model for synthesis. Cheap models are good at filtering and bad at judgement. Put them in the leaves, not at the root.
FAQ
How many subagents is too many?
Concurrency is usually capped by your runtime well below what you can request, so the practical question is total count rather than parallelism. Past a few dozen, the merge step becomes the hard part and the parent's context fills with summaries — which is the original problem in a new costume.
Should subagents share conversation history?
Generally no; that defeats the isolation. Pass exactly the context each one needs. The exception is a shared immutable brief — project conventions, a schema, a style guide — which is cheap to include and prevents divergent interpretations.
How is this different from a workflow?
A workflow has control flow you wrote: fixed stages, deterministic branching. Subagent delegation lets the model decide what to spawn. Workflows are more predictable; delegation handles work you could not enumerate in advance. Many production systems are a workflow whose stages happen to call agents — agentic workflows covers that boundary.
What happens when a subagent fails?
Decide deliberately, because the default is usually bad. A dropped subagent silently narrows coverage, and a parent that reports success on partial results is worse than one that errors. Filter failures explicitly and say what was not covered.
Where to go next
Tracing is what makes this architecture debuggable rather than mysterious — AI agent observability covers the spans worth emitting. For bounding what each subagent may spend, read agent token budgets, and for the single-agent techniques that often remove the need to split at all, context engineering.