When to spawn a subagent, and the many times you should not

Spawning a subagent feels like parallelising: the work happens elsewhere, your own context stays clean, and several things can proceed at once. All of that is true and it obscures the cost.

The cost is that a fresh agent knows nothing. It has to locate the files, infer the conventions and rebuild the context that you spent the last hour establishing. For a task that depends on that context, the rebuild is most of the work — and it is done worse, because it is done from scratch.

So the question is not whether a task could be delegated. It is whether the task is cheaper to explain than to do.

Wide search. Finding where something lives across many files. The subagent reads a great deal and returns a short answer, which is exactly the shape that benefits — the reading stays out of your context.

Genuinely independent work. Two tasks that do not touch each other and do not need each other's results.

Bounded investigation. 'Find out whether X is true' — a question with a short answer that requires long reading to produce.

The common property: high reading, low output, no dependency on accumulated context. When all three hold, delegation is clearly right.

Work in files you have been editing. You know the state, the subagent does not, and explaining it costs more than doing the edit.

Anything requiring taste. Judgement calls that depend on the direction established in the session will be made differently, and you will redo them.

Small tasks. Below a certain size, the coordination overhead exceeds the work. A two-line change is never worth a spawn.

Chains. Tasks where the second depends on the first cannot be parallelised at all, and running them as separate agents adds handover cost for no gain.

Tasks that are mostly about finding things out — searching, checking, investigating, summarising — delegate well, because the expensive part is the reading and the returned result is compact.

Tasks that are mostly about producing things — editing, designing, deciding — usually should not, because the expensive part is the context and it does not transfer.

The exception is a large, self-contained piece of production work with a specification tight enough to hand over in writing. If you can write the spec in a paragraph and it leaves nothing to interpretation, delegation works. If writing that paragraph is hard, that difficulty is telling you the context does not transfer.

A subagent brief needs the goal, the constraints, where to look, what to return, and what not to do. Vague briefs come back with work you did not want, and the review of that work costs more than the task.

Be explicit about the output. 'Report the file and line, do not edit anything' produces something you can act on. Without it you may get changes you have to inspect.

And ask for what you need rather than everything found. A subagent that returns its whole investigation has moved the reading into your context, which defeats the purpose entirely.

Two or three independent agents on genuinely separate problems works. Beyond that, you spend your attention tracking who is doing what, and the reviewing of several partial results becomes its own task.

There is also a consistency cost. Independent agents make independent decisions, and work that touches the same area comes back with three different conventions.

If you find yourself spawning many, the underlying problem is usually that the task was not decomposed properly. Fixing the decomposition is more effective than adding parallelism.