Subagents¶
An agent can spawn agents. This is not a gimmick — it solves the two problems that actually limit agentic research: context pollution and serial time.
Why fan out¶
Every file the agent reads occupies context — and context is the scarce resource. If the main agent personally reads 40 files to answer "where is the detector calibration applied?", those 40 files crowd out everything else for the rest of the session.
A subagent fixes this: it gets a fresh context, does the dirty work (reading, searching, running), and returns only its conclusion to the parent. The parent keeps the answer; the 40 files never touch its context.
> Use three parallel subagents: one to map every place the calibration
> constants enter the analysis, one to check our fitting code against the
> paper's appendix B, one to find why the CI job is 4x slower since March.
> Report back the three summaries.
The three run concurrently. Wall-clock time is the slowest one, not the sum.
When to reach for it¶
| Situation | Pattern |
|---|---|
| Broad search ("find every place X happens") | One Explore subagent; you want the conclusion, not the file dumps |
| Several independent questions | Parallel subagents, one each |
| Big migration / sweep over many files | Fan out workers, one per file or module |
| Cross-checking a result | Independent subagents told to refute it — agreement means more when contexts are independent |
That last row is the research-grade trick. Independent contexts are independent errors:
> I'll paste a derivation below. Spawn two subagents with opposite briefs:
> one argues it's correct, one hunts for the flaw. Then judge.
When not to¶
Don't fan out work that's inherently serial (each step needs the previous step's result), and don't use a subagent for a single lookup you could do in one command. Orchestration has overhead; reserve it for breadth.
In the walkthrough
In Act II we use subagents to scan a parameter space — each worker integrates one slice, the parent only ever sees the assembled result table.