When to Spawn a Subagent (and When You’re Just Paying for a Second Copy of the Same Context)
Parallel earns its spend only when the spec is locked, the units are independent, and nobody has to reconcile the outputs afterward.
I once split a research task across four subagents. Each one read about the same three reference files, ran the same kind of analysis on a different slice of the problem, and returned a chunk of findings. The four ran in parallel. The “parallel” part took 90 seconds. The integration step took 22 minutes.
The four subagents had collectively re-Read the same files four times, produced output in four slightly different formats, and disagreed in small ways about how to structure their findings. I spent the 22 minutes reconciling shape, deduping conclusions, and rewriting the section that needed to thread their outputs together.
If I’d done the work serially in one session, the analysis would have taken about 6 minutes longer and the integration would have been zero. I paid for “parallel” twice. Once in the four subagent runs, once in the cleanup that “parallel” made necessary.
Article 1 distinguished orchestrator from worker. That was one boundary. Sequential vs parallel is another, and it’s worth deciding in advance, not in the moment.
The mental model that was wrong
“More parallel = faster.” This is true for compute. It is not generally true for Claude work.
Compute parallelizes when the units are independent and the cost of splitting and joining is small. Claude work parallelizes when those same conditions hold AND the spec is locked AND each subagent’s context is genuinely different from its siblings.
When any one of those fails, you don’t get speedup. You get two or more copies of the same waste, plus an integration tax at the end.
Subagents aren’t free even when they help. Each one loads its own context, often re-reads files the parent already has, and produces output the parent has to ingest. The math is simple: parallel earns the spend only if the alternative was serial work that took meaningfully longer AND the integration step at the end is small.
The four conditions
Before spawning, run all four.
Locked spec. The brief is unambiguous. Each subagent could read it cold and produce work that fits next to its siblings without coordination. If the spec leaves any room for interpretation, the subagents will interpret differently. The cost of that drift gets paid at integration.
Parallelizable units. The work splits into independent chunks with no shared state. No subagent needs to know what another subagent is doing. No subagent’s output depends on another’s. If any unit needs to consume another unit’s output, the work is not parallel by definition.
Isolated-context need. There is a reason NOT to pollute the parent context with this work. Research that pulls many files. Exploratory searches that you don’t want sitting in your main session afterward. Big lookups whose findings the parent will summarize but doesn’t need verbatim. If the parent could comfortably do the work in its own context, there’s no isolation gain to harvest.
No follow-up integration. Outputs are consumed independently. Each lands in its own destination file, or a small bounded integration step is all that’s needed. If integration is itself a large, judgment-heavy step, that step is where the real work was. Splitting the upstream just moved the bottleneck.
All four pass: spawn. Any one fails: don’t.
When manual beats parallel
For anything decision-shaping (ambiguous scope, novel patterns, work where you’d want to course-correct midway), serial in one context beats parallel every time. The reason is that judgment can’t be parallelized. Subagents will all make their own calls, and you’ll be re-making those calls during integration anyway.
This includes most exploration. It includes most first-time work. It includes any time the “right answer” is one you’ll only recognize after seeing a draft.
Parallel is for execution against a locked plan. The plan has to exist first.
Markers — you’re spawning subagents you shouldn’t
You’d phrase the brief differently if you were writing it mid-flight. Sign that the spec isn’t locked. Subagents launched against a spec you’d revise will produce work you’ll revise harder.
Two or more subagents are loading the same reference files. If the redundant loads are large, you’re paying for that load N times for one piece of information. Better to load it once in the parent and pass the relevant slice down.
The integration step is the actual hard part. When the post-parallel stitching takes longer than the parallel work itself, the work was never parallelizable. It was integration with some lookup attached.
You’re hoping parallelism will reveal the right structure. Subagents are not a substitute for thinking through the structure. If you don’t know the shape before spawning, you’ll know it after, plus the cost of the bad spawn.
When any of these hit, the right move is to collapse the parallel dispatch back into a serial run. Not “make the parallel cleaner.” Stop spawning until the structure is decided.
What I’m giving you, and what I’m not
You have everything you need to apply this: the four-condition test (locked spec, parallelizable units, isolated-context need, no integration).
The “manual beats parallel” cut for ambiguous work.
The four over-spawning markers.
The four-condition test is itself a small example of the 30% orchestration layer: encoded once as a checklist, not re-derived every time you reach for a subagent. Article 6 unpacks where 30% fits in the bigger 60-30-10 picture.
What I’m not giving you: my specific patterns for which jobs I parallelize, my dispatch templates, my internal split rules. Those are shaped to the workers I run and the jobs they do. Your jobs will split differently.
Subagents are a real tool. They’re not the default. The default is one session doing the work it can do.