Sub-agents buy you a window and charge you a boundary

What you are actually buying

Strip away the vocabulary of delegation and roles, and a sub-agent is one mechanism: a second context window that the first one does not pay for.

A research sub-agent runs twelve searches, reads nine pages, burns 80,000 tokens in its own window, and returns 600 tokens of findings. The parent’s window grows by 600. The 80,000 happened somewhere the parent will never see and never be billed for again on subsequent turns, which is the part that matters, because in the parent’s own window those 80,000 tokens would have been resent on every step for the rest of the task.

That is the entire benefit. Everything else attributed to sub-agents (specialisation, focus, cleaner prompts) is real but secondary, and mostly achievable other ways.

The boundary is the design

Whatever the sub-agent knew and did not write down is gone. Not retrievable, not queryable: gone, unless you re-run the whole thing.

This makes the return schema the most consequential thing you write, and it is usually the least considered. A sub-agent told to “research X and report back” returns prose of whatever length it fancies, with confident claims and no indication of which are solid.

Specify it instead:

{
  "findings": [{"claim": "...", "source_url": "...", "quote": "..."}],
  "could_not_determine": ["..."],
  "sources_consulted": 9,
  "confidence": "high | mixed | low"
}

The field that earns its place is could_not_determine. Without it, a sub-agent that failed to find something returns a report that reads exactly like a sub-agent that found everything, and the parent proceeds on an evidence set it believes is complete. This is the characteristic sub-agent failure and it is silent at every layer.

The quote field is the second. A claim with the sentence it came from can be checked by the parent; a claim without one has to be believed.

What it costs, beyond the obvious

Cache fragmentation. Each sub-agent has its own prefix, so none of them shares the parent’s cache. Five sub-agents means five cold prefixes. You can recover most of this by giving every sub-agent of a given type an identical system prompt and toolset, so they at least warm the same cache entry, which means resisting the urge to inject the specific task into the system prompt. Put the task in the first user message, below the breakpoint.

Compounding compression. A sub-agent summarising its own sub-agent’s summary is two lossy steps. Each is reasonable; together they produce a report whose relationship to the source material nobody can reconstruct. Two levels is usually the practical limit, and one is better.

No shared state. Two sub-agents editing the same file is the canonical disaster, and it fails in the ugliest way: both succeed, one overwrites the other, and nothing reports a conflict. If the work touches shared mutable state, either serialise it or do not decompose it.

Where the real latency win is

Parallelism, and it is a genuine one. Four sub-agents searching four sources concurrently take as long as the slowest, not the sum. For read-only, independently decomposable work (search across sources, review across files, check across datasets) this is the strongest argument for the pattern, stronger than the token saving.

It inverts immediately when the sub-tasks depend on each other. Sequential sub-agents are slower than doing the work inline, because you have added a model call and a serialisation round trip per step for no isolation benefit that a stub would not also give you.

When not to

• When the parent will need to ask a follow-up. There is nobody to ask. The sub-agent is gone. If the shape of the next question depends on the answer, keep the work in one window.
• When verification matters more than volume. The parent can only check what came back. A sub-agent that reasoned badly returns a confident, well-formed, wrong summary, and it looks identical to a good one.
• When the task is small. Below a few thousand tokens of reading, the overhead of a second model call exceeds the saving.

A test worth running

Run the same task twice: once decomposed into sub-agents, once inline in a single window with aggressive stubbing. Compare three numbers: total tokens billed, wall-clock time, and accuracy on your golden set.

The result surprises people regularly in both directions. Sub-agents win decisively on parallel read-heavy work. Inline with stubbing wins more often than expected on sequential work, because stubbing achieves much of the same context reduction without paying the boundary. Which one you have is an empirical question about your task, and it takes an afternoon to settle rather than an argument.