Subagents
Spawning a second agent buys you a clean context window. That is the whole trick — and the whole cost.
A subagent is an agent spawned by another agent via a tool call. It runs in its own session with its own context window, does a job, and returns a result. It cannot usually spawn further subagents.
The value is precise: the subagent's tool results land in the subagent's window, not yours. What comes back to the parent is a summary. You get the work without the debris.
Where that matters
- Search and exploration. "Find every place we construct a Stripe client" might read twenty files. In a subagent it costs your session one paragraph.
- Independent parallel work. Three unrelated files needing the same mechanical change, done concurrently.
- Fresh-eyes review. A reviewer with only the diff, unprimed by the reasoning that produced it (Lesson 3.3).
- Expensive verification. Running a long suite and reporting only what failed.
The cost: they cannot see your session
A subagent starts empty. It does not know the plan, the constraints you agreed twenty minutes ago, or the three approaches already ruled out. Everything it needs must be in its instructions — and the parent agent is the one writing those instructions, usually more briefly than you would.
This produces the characteristic subagent failure: work that is locally reasonable and globally wrong. Four subagents each solve their piece with a different naming convention, or each add the same helper.
Use them for the two shapes that work
| Works well | Works badly |
|---|---|
| Read-only investigation returning a summary | Design decisions requiring project judgement |
| Mechanical work against an exemplar diff | Anything needing the parent’s conversation history |
| Review of a specific artifact | Work whose pieces must agree with each other |
| Verification with a narrow report | Exploratory work with an undefined endpoint |
Instruct them like a stranger
Spawn a subagent with these exact instructions, and nothing implied: "Find every call site of createCheckoutSession in this repo. For each, report: file path, line number, and whether the idempotency key argument is passed. Do not modify any file. Return only the list." Then summarise its findings for me in five lines.
Notice the shape: read-only, narrow output, no judgement required. That is the reliable pattern.
Watch out
Parallel subagents writing to the same files will clobber each other, and the parent will not necessarily notice. Either give each one disjoint files, or run them in separate worktrees (Lesson 3.5) and merge deliberately.
Try it
Run the same exploration twice: once inline, once delegated to a subagent. Compare your session’s token count afterwards. The saving is the point — and it is usually large enough to change how you explore.
Takeaways
- Subagents buy a clean context window; the summary comes back, the debris does not.
- They start empty — everything they need must be in their instructions.
- Best for read-only investigation, exemplar-driven mechanical work, and review.
Why do four parallel subagents implementing four similar features tend to produce an inconsistent result?
Because none of them can see the others, and none has the parent’s conversation history. Each makes locally reasonable choices with no shared context, so naming, helpers, and structure diverge. Give them an exemplar diff and a shared brief, or do the work sequentially.
A course by Pieter Zandbergen