Spawning subagents is the feature everyone wants to show off. Hand the model a big task, split it into five, run them at once, done in a fifth of the time. On a demo it looks like free speed.
It is not free. It is the old project triangle — speed, cost, quality: pick two — wearing new clothes. Subagents buy you speed. The bill lands on the other two corners, and whether the trade is worth it depends entirely on one property of the work: does it share state.
What fan-out actually costs
Run five agents instead of one and you pay in two places that do not show up until later.
Cost. Each agent carries its own context and burns its own tokens. Five agents reading the same repo is roughly five times the input, not one fifth. For a short task the speed is worth the spend; for a long one you can quietly multiply your bill without multiplying the result.
Quality. This is the corner people miss. Agents running in parallel cannot see each other's work. Each one knows less than a single agent would, because the single agent accumulates everything it learns and the parallel ones each start cold. When their outputs have to fit together, nobody was holding the whole picture.
The line that decides it: shared state
The honest rule is not "subagents good" or "subagents bad." It is:
Fan out for reads. Stay single for writes.
Reads fan out cleanly. Searching a large codebase, running independent reviews from different angles, recon across many sources, summarising a pile of documents — the outputs do not touch each other. Five agents search five areas, you merge five answers. The triangle still charges you cost, but quality holds, because nothing collides. This is where parallel agents genuinely earn their keep.
Writes do not. The moment two agents edit related files, the collisions start. One rewrites a helper the other was depending on. Both touch the same config and the second silently clobbers the first. Commit and signing steps race each other and you end up with unsigned or conflicting commits on the branch. Each agent, missing what the others did, makes a locally sensible change that is globally wrong. We have watched a batch of parallel builders do exactly this — faster to the first commit, slower to a working result, because the time saved up front came back as untangling afterwards.
A missed review is slow. A bad parallel write is wrong, and it reports success while being wrong, which is the more expensive failure.
Encode it where the agent reads it
A mental model only helps if it is written down where the work happens. For a team, that is CLAUDE.md. One rule keeps everyone — human or agent — on the right side of the triangle:
## Fan out for reads, stay single for writes
- Subagents are for read-only work: search, independent review, recon,
summarising many sources. Their outputs are merged, never written back
in parallel.
- Build, edit and commit work runs in ONE agent in the main session —
one change at a time. No parallel writers to shared files or the same
branch.
- "Do them all" / "in parallel" means sequential in one session, not
fanned out.
Now "do it in parallel" stops meaning "spawn five writers" and starts meaning "go fast, one thing at a time" — and the next person on the repo reads the same rule you did.
The triangle does not bend
Subagents are a throughput tool for independent reads, not a shortcut for shared-state writes. Fan out to search and review, and you get real speed at a fair price. Fan out to build, and you pay for the speed twice: once in tokens, once in untangling the mess. Pick the two corners you actually want before you spawn.
If your team runs Claude Code, the rule above is one paste into your CLAUDE.md. AI Workspace Builder turns the way your team already works into that file — and the agent configs around it — so decisions like this one live in the repo instead of in one person's head.
Top comments (0)