spawn vs inline: when to branch threads

analysis of 4,656 amp threads comparing threads that spawn subtasks (via Task tool or tmux) versus threads that stay inline.

the numbers

task tool threads resolve at +18% higher rate than inline. but they also run ~2.5x longer. the resolution rate advantage comes with context cost.

tmux spawn threads show no resolution advantage over inline—same 54% rate but longer turns. this suggests the complexity of managing panes offsets any parallelization benefit for typical tasks.

chain depth matters

depth (how many handoff hops from root) correlates with outcome in a non-linear way:

the sweet spot appears around depth 8-15—high enough that context has been deliberately scoped across handoffs, but not so deep that coherence degrades.

extremely deep chains (16+) exist mainly from one marathon session: the “query_engine optimization saga” reaching depth 72. these long chains have elevated handoff rates (42%), suggesting context eventually fragments beyond recovery.

user-level patterns

users who spawn show different outcomes:

correction: prior analysis miscounted @verbose_explorer’s spawned subagent threads (“Continuing from thread…”) as failures. @verbose_explorer spawns at highest volume (231 agents) with 97.8% success — the most effective spawn orchestrator in the dataset.

hunch: spawn success correlates with deliberate, well-scoped delegation rather than aggressive parallelization.

spawn mechanics that work

from examining successful spawn threads, patterns emerge:

1. coordinator pattern

a root thread manages state and spawns specialized workers. seen in:

• T-019b9a3d: “PR #9 trpc-cli migration coordination”
• T-019b3650: “Create Linear CLI with bun”

coordinator threads carry explicit handoff context:

YOU ARE TAKING OVER AS COORDINATOR. read these guidelines first...
CURRENT STATE: [explicit state summary]
YOUR RESPONSIBILITY: [scoped mandate]

this pattern works because each spawn inherits minimal, curated context rather than full conversation history.

2. continuation chains

sequential handoffs where each thread advances one phase:

Continuing work from thread T-xxx. 
[file attachments]
[explicit context summary]
[scoped task]

success correlates with:

• explicit context in opening message (threads referencing other threads in first message show +25% success)
• file attachments to ground the handoff
• clear scope boundaries

3. task tool for isolated work

successful Task tool usage patterns:

• “run tests and report results” (fire-and-forget verification)
• “refactor this module using patterns from X” (isolated transformation)
• parallel file edits that don’t interact

spawn mechanics that fail

1. coordination overhead explosion

tmux spawn with multiple panes creates management burden. from T-019b33c2:

cancel both their actions, take their ids, and exit their sessions. Then spawn an agent besides us to handle the revert...

managing agent lifecycle becomes the task rather than the original work.

2. context loss across handoffs

62.5% of spawned threads show “orphan” patterns—no explicit closure or return to parent. the handoff succeeds but the synthesis never happens.

3. vague delegation

FRUSTRATED spawn threads often have vague initial prompts:

• “Fix this” (T-019b03ba)—no context, leads to guessing

vs successful spawns:

• “Optimizing FloatColumn SortMatches performance” (T-019affde)—specific, grounded

recommendations

spawn when:

• task is genuinely independent (test runs, isolated file changes)
• context would otherwise exceed useful window
• you have explicit state to hand off
• depth stays under ~15 hops

stay inline when:

• task requires back-and-forth refinement
• shared state is evolving rapidly
• you’re exploring rather than executing
• the overhead of context transfer exceeds the work itself

if spawning:

• front-load context in first message
• attach relevant files explicitly
• state current status + scoped mandate
• plan for synthesis—who consolidates the work?

limitations

this analysis treats Task tool usage as a proxy for intentional spawning. some threads use Task for one-off operations that aren’t really “spawn patterns” in the architectural sense.

tmux spawn detection via pattern matching may undercount implicit spawn patterns (manual terminal spawning without explicit keywords).

resolution rates don’t capture partial success—a thread marked HANDOFF might have accomplished 90% of its goal before passing on.

generated from 4,656 threads, 2,562 cross-thread edges, 1,824 continuation links