Subagents are a team-management pattern.
A single session, three workstreams
A Claude Code session refactored a payments service in twenty-two minutes. Not because the model wrote faster code. Because the session dispatched three subagents simultaneously:
- one mapped every downstream dependency of
PaymentProcessor.charge(), - one drafted a migration plan from v2 to v3 with the constraints written into the prompt,
- one wrote integration tests against the existing contract.
Three parallel workstreams, coordinated by a single operator. The interesting part is not the speed. It is that the pattern is not new — it is how a strong engineering lead has always managed work.
What a subagent is, operationally
A subagent is a child session with its own context window, its own system prompt, and its own permission boundary. The parent session does not absorb everything the subagent reads. It absorbs the subagent's summary.
That property is what makes parallelism work. Without it, every parallel branch would compete for the same context budget, and you would be back to a sequential session pretending to be parallel.
In practice the subagents come in three flavors:
- Explore — read-only, optimized for codebase search and dependency tracing. The senior engineer who knows where everything lives.
- Plan — analysis-focused, evaluates tradeoffs and produces structured plans. The staff engineer at the whiteboard.
- General-purpose — full read/write/execute. The implementation engineer who takes a scoped spec and ships it.
These are not cosmetic labels. Each gets a different system prompt and different tool access. Treating them the same is the same mistake as staffing every role with the same engineer.
Foreground vs. background
Most teams default to foreground for everything. They watch the output stream, then dispatch the next task, then watch again. That is a synchronous conversation with extra steps.
The pattern that shows up in high-performing setups is a mix:
- Foreground for the critical-path decision — the one whose result gates the next move.
- Background for supporting work — documentation, full test runs, codebase-wide refactors that can catch up later.
A reasonable rule of thumb: if you can imagine doing other useful work while the subagent runs, run it in the background. If the next thing you do depends on the answer, run it in the foreground.
Isolation is the unglamorous part
The temptation with parallel agents is to let them all touch the same working tree. They will. They will also stomp on each other's changes the moment two of them try to edit the same file.
Git worktrees solve this cleanly. Each agent gets its own checkout, its own branch, and its own filesystem boundary. Conflicts surface at PR time, in front of a human, which is where conflicts should surface anyway.
A pattern that works in practice:
git worktree add ../wt-explore --detach
git worktree add ../wt-plan --detach
git worktree add ../wt-impl -b feat/payments-v3
Explore and plan can be detached because they are not going to commit. The implementation worktree is on a real branch because it will.
Why this is a management pattern, not a tooling trick
The reason this pattern feels familiar is that it is the same pattern a good engineering lead has always used:
- Decompose the work into pieces with clear interfaces.
- Dispatch each piece to the right specialist.
- Run independent pieces in parallel; sequence the dependent ones.
- Synthesize the results at the merge.
The change with subagents is not the pattern. It is the cost of dispatching — close to zero, available at any moment, without convening anyone. The leverage that used to require a team meeting is now a single tool call.
The teams that win with this are not the ones with the biggest models. They are the ones whose engineering leads were already good at this kind of orchestration and now have a tool that lets them practice it ten times a day instead of twice a week.