A subagent is a separate Claude Code session, launched by the main one, with its own context and a narrow job. The point is not speed for its own sake. It is that some work is genuinely independent, and running it in a clean context produces better results than cramming everything into one long conversation.
Why splitting work helps
A single session accumulates everything it has read. By the time it has explored half a codebase, the details that matter are competing with a great deal that does not. Handing a self-contained task to a fresh session avoids that entirely, and the difference in output quality is obvious once you have seen it.
Independent investigation: searching a large codebase without polluting the main session with every file it opened
Parallel work: several unrelated changes progressing at once rather than in sequence
Specialised review: a separate pass whose only job is to check the work critically
Bounded risk: a subagent with a narrow brief cannot wander into unrelated parts of the system
The review case is the one teams undervalue. A second session that has not just spent an hour writing the code is markedly better at spotting what is wrong with it, for much the same reason a colleague is.
When not to split
Subagents cost coordination. Each one starts without the context the main session built up, so anything that depends heavily on that shared understanding is faster and more accurate done in one place, by the session that already knows the shape of the problem.
The rough rule: split when the task can be described completely in a paragraph and the result can be summarised in a paragraph. If briefing the subagent would take longer than doing the work, do the work.
Writing a brief that survives the handoff
A subagent only knows what you tell it. The most common failure is a brief that assumes context the parent session has and the child does not, which produces confident work against the wrong assumptions and costs more to unpick than it saved.
State the goal and what a finished answer looks like
Name the constraints explicitly, including what not to change
Say how much to explore: a single lookup, or a thorough search across conventions
Ask for a summary of findings rather than a transcript of everything it read
Parallel work in practice
Where this pays off most is a task that decomposes cleanly into independent pieces: auditing several modules against the same standard, or investigating three unrelated bug reports. Each subagent works in isolation and reports back.
What it does not do is make a single sequential problem faster. Three subagents on one tightly coupled change spend their time duplicating each other's discovery and producing conflicting suggestions that someone then has to reconcile by hand.
The cost dimension
Every subagent is a separate context being filled, and tokens are the unit of cost. Three subagents doing thorough exploration will cost several times a single focused session, which is fine when the parallelism is real and wasteful when it is not.
For an Australian dev team where a frontier-model bill can already run $2,000 to $5,000 a month, this is worth a rule rather than a habit: split when the work is genuinely independent, not by default because it feels thorough.
Reviewing what comes back
Treat subagent output as a report from someone who was not in the room. It may be excellent and it will not know what changed in the main session while it was working, so reconcile before acting on it.
In practice that means reading the summary rather than accepting the conclusion, and being especially careful where two subagents touched adjacent code. Merge conflicts between parallel agents are the ordinary cost of the approach.
A sensible starting pattern
The easiest first use is read-only investigation. Send a subagent to answer a specific question about the codebase, where is this configured, which modules call this function, and have it report back without changing anything.
That gives you the context benefit with none of the merge risk, and it builds a feel for how much briefing a subagent actually needs before you let one write code.
Who owns the decision
Keep one session as the place where architectural calls are made. Subagents gather, check and execute narrow tasks; they should not be deciding how the system is shaped, because none of them can see the whole.
Teams that blur this end up with three defensible but incompatible approaches landing in the same afternoon. The coordination cost of unpicking that comfortably exceeds whatever the parallelism saved.
What not to conclude
Subagents do not make Claude Code autonomous, and more of them does not mean better results. The teams getting value are the ones that use them for genuinely separable work and keep a single session as the place where decisions get made.
They also do not remove review. A parallel pass produces more output in less time, which means more code arriving for a human to check, not less. If review is already your bottleneck, parallelism makes that worse before it makes anything better.
If your team is scaling up Claude Code and unsure where parallel work actually helps, book a short call and we will look at what is worth splitting.
