Sub-Agents · Working With Sub-Agents
Dispatching for parallel research
Sequential context-loading is the bottleneck you stop tolerating after you understand fan-out. Three agents reading three modules simultaneously collapse fifteen minutes of sequential file reads into five — not because agents are faster readers, but because they work at the same time and their findings land in the parent as structured summaries rather than raw file contents.
The fan-out pattern is the fastest thing you can do with sub-agents. Here is a working example.
A real parallel dispatch
This is a security audit across three subsystems. These three briefs run concurrently:
Agent 1 brief:
Read every file in /src/auth/. Summarize the session lifecycle in 3-5 sentences.
List every place a token is written to disk or browser storage: file path, line
number, storage key, token type. Return as JSON:
{ "summary": string, "writes": [{path, line, key, type}] }
Agent 2 brief:
Read every file in /src/api/. List every route that accepts a Bearer token.
For each route: method, path, middleware chain (in order), handler file.
Return as JSON: { "routes": [{method, path, middleware, handler}] }
Agent 3 brief:
Read every file in /src/db/. List every table touched by operations related to
authentication, sessions, or tokens. For each: table name, operation
(read/write/delete), calling file and function.
Return as JSON: { "tables": [{name, operation, caller}] }
Parent integration step (runs after all three return):
You have three JSON objects from a security audit of the same codebase.
Cross-reference them: find any route in agent 2's output where the token type
written by agent 1 does not match the token type the route expects. Also find
any auth table from agent 3 that is written by a route from agent 2 without
middleware validation appearing before the handler in the middleware chain.
Return a markdown audit report with findings only. No findings = empty list,
not "no issues found."
Each brief specifies JSON output with a fixed envelope shape. The parent receives structured objects and reasons about them — it does not parse prose or extract values from narrative text. This discipline is what makes fan-out composable.
Why output format discipline is not optional
If agents 1, 2, and 3 return prose in different structures, the parent integration step becomes a parsing problem, not a reasoning problem. The parent will spend its context budget trying to interpret three different formats instead of reasoning about their contents. Specify the output format in every brief. Make the envelope shape consistent across all agents in a fan-out. The field names do not have to match — but the shape ({ key: value } vs. [{...}, {...}]) should be decided before dispatch.
When fan-out is the wrong pattern
Fan-out fails when briefs have hidden dependencies. If agent 2 needs to see agent 1's token type list to know which routes to flag, you cannot run them in parallel. You have a pipeline, not a fan-out. Run agent 1 first, embed the result in agent 2's brief, then run agents 2 and 3 in parallel if they are now independent of each other.
The test: can each brief be executed knowing only its own contents? If yes, fan-out is correct. If one agent's brief implicitly assumes something another agent would discover, sequence them.
If you get stuck
You dispatched three agents and one returned partial results. The temptation is to re-run all three. Do not. Identify which brief was underspecified, fix that brief, re-run that agent only, and re-integrate. The other two results are still valid — they are sitting in the parent's context as structured objects. Re-running them wastes time and context budget.
Context bleed is the second failure mode. You embedded a file's full contents in each brief rather than giving the path and letting the agent read it. Now each agent starts with 8,000 tokens already consumed and the parent's context is also heavy. Give agents paths, not file contents, unless the file is too large for the agent to read in its own context or the file changes between dispatch and execution.
The third failure mode: agents returning at different times, and the parent reasoning about partial results before all three have finished. If you are using Claude Code's parallel dispatch, wait for all agents to return before running the integration step. Do not short-circuit by integrating as agents trickle in — you will produce an incomplete audit.
Cross-reference
l1 defines the sub-agent primitive and the boundary rule that governs when agents can run in parallel versus when they must be sequenced. l3 handles the case where your fan-out agents need to write code, not just read — which requires worktrees to prevent conflicts. l7 extends fan-out to a full PR pipeline.
Deliverable
Write a parallel dispatch plan for one investigation you have open. Three agents, each with a self-contained JSON-output brief. Then write the parent integration step that synthesizes their outputs into a single artifact. Before you dispatch anything, review each brief for hidden dependencies: does any brief's task require knowing what another agent will find? If yes, redesign the sequence. The planning step is the lesson — run it after you have reviewed all three briefs.
Try these prompts
- Write a parallel dispatch plan for auditing three subsystems — auth, API routes, and database — for a token-handling security review. Include one brief per agent with a JSON output envelope.
- Explain in two sentences why output format discipline across parallel agents is not optional, with a concrete example of what breaks when formats differ.
- Identify the hidden dependency in these two parallel briefs and explain whether they can run concurrently or must be sequenced.
Sign in to keep your place and tick off lessons. Reading stays open either way.