//
Search across all documentation pages
When a research task splits cleanly into independent pieces, spawning one subagent per piece and running them at the same time is faster and cleaner than researching each piece one after another in the main session.
This is the fan-out pattern: several subagents launched together, each with its own scoped task, each reporting back a short summary once it finishes.
A single subagent already keeps exploratory work out of the main session's context.
Fan-out extends that by launching several subagents at once instead of one at a time, so independent research happens concurrently rather than sequentially.
Because each subagent gets its own isolated context, running three or five of them in parallel does not risk one subagent's findings leaking into or contaminating another's.
The main session's role shifts from doing the research itself to writing clear, independent task descriptions and then synthesizing the summaries that come back.
This only works well when the pieces are actually independent; a task where the second subagent needs the first one's answer before it can start is not a fan-out candidate.
Spawn three subagents in parallel, one each for the authentication code, the
billing code, and the notifications code. Each subagent should report back:
the entry point file, the overall data flow, and any error-handling pattern
it finds. Keep each report under 150 words.When to reach for this:
I'm about to add rate limiting to this API. Before I do, spawn three subagents
in parallel:
1. Research how the existing auth middleware is structured, so rate limiting
can plug into the same request pipeline.
2. Research how errors are currently formatted and returned to API clients,
so a 429 response matches existing conventions.
3. Research whether any existing config system (env vars, a settings file)
should hold the rate limit thresholds, rather than hardcoding them.
Each subagent should report back file paths and a two or three sentence
summary, not full file contents. Once all three are done, propose where the
rate limiting logic should live based on what they found.What this demonstrates:
| Signal | Fan-out fits | Fan-out does not fit |
|---|---|---|
| Dependency between tasks | None; each task can start with zero information from the others | One task needs another's findings before it can begin |
| Scope of each task | Bounded and specific (one subsystem, one question) | Vague ("look around the whole codebase") |
| What "done" looks like | A short, concrete summary answers the question | The answer only makes sense woven into a long narrative |
Bad: "Look into how the app handles errors."
Better: "In the payments module only, find where errors are caught and
formatted for the client. Report the file path and the format used, in
under 100 words."| Alternative | Use When | Don't Use When |
|---|---|---|
| A single subagent | The research question is one coherent task, even if it touches several files. | The task genuinely splits into several unrelated subquestions that would each dilute a single subagent's focus. |
| Sequential subagents, one after another | Later research depends on what an earlier subagent found. | The pieces are independent and running them one at a time would just add unnecessary latency. |
| Researching directly in the main session | The lookup is quick and small enough that spawning a subagent at all would cost more than it saves. | The research is broad enough that its intermediate steps would meaningfully bloat the main session's context. |
There's no fixed limit stated by the product, but practically the number should match how many genuinely independent pieces the task actually has, and how much synthesis effort the main session can reasonably do afterward, usually a handful rather than dozens.
No. Each subagent gets its own isolated context, so none of them can see what the others are doing or have found while all are still in progress.
The main session generally waits for all spawned subagents to complete before synthesizing across their reports, so the slowest subagent in the batch determines when synthesis can begin.
Yes. Asking for a consistent structure, such as a file path followed by a short summary, makes it much easier to compare and combine the reports once they all come back.
No. Fan-out is for independent pieces that can start with no information from each other; a dependent, sequential task should be run as sequential subagents (or steps) instead.
If describing the task for one subagent naturally requires referencing "what subagent B found," the task has a dependency and is not a genuine fan-out candidate.
The context savings come from isolation itself (each subagent's exploration never lands in the main session), which holds whether the subagents run in parallel or sequentially; parallel spawning mainly saves wall-clock time, not additional context.
The main session that spawned them. It receives each subagent's summary and is responsible for drawing conclusions or making decisions that combine information across all of them.
Yes. A command's prompt body can instruct Claude to spawn several subagents in parallel, turning a recurring fan-out audit into a single repeatable /command-name invocation.
Debugging a single, specific failing test, where the investigation is one continuous thread of reasoning rather than several independent, parallel subquestions.
Not necessarily; research subagents in a batch commonly share the same scoped, often read-only, tool list, since their jobs (reading and searching, not editing) are usually similar even though their targets differ.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.