Parallel Subagent Spawning

In a hub-and-spoke multi-agent system, a coordinator decomposes a task, delegates pieces to subagents, then aggregates the results. The key performance lever: multiple Task calls emitted in one response run concurrently.

If a research job needs three independent lookups, you don't have to do them one after another. Spawn all three in a single turn and they execute in parallel, collapsing three round-trips into one wave.

The rule is precise: every Task call the model emits in the same assistant response is dispatched at the same time. There is no special API flag — concurrency is a property of how many Task calls share one response.

• Three Task calls in one response → three subagents run in parallel.
• One Task call, wait for the result, then another Task call next turn → sequential.

So parallelism is a decomposition decision, not a configuration toggle.

A coordinator can only spawn subagents if its allowedTools includes "Task". Without it, the model has no mechanism to delegate and will try to do everything itself.

This is part of least-privilege design: only the coordinator gets Task; leaf subagents usually do not, so they can't recursively spawn more agents.

This is the single most-tested fact about subagents: a subagent does NOT inherit the coordinator's conversation history. It starts with a clean context.

Therefore all context a subagent needs must be passed explicitly in its prompt — the question, relevant constraints, prior findings, output format. If you assume the subagent "already knows" what the coordinator discussed, it will hallucinate or under-perform.

Because context isn't inherited, each parallel Task prompt should be fully self-contained. Notice how each spawned subagent below carries its own topic and the same explicit instructions — nothing is left implicit.

Parallel spawning is the right move when sub-tasks are independent — none needs the output of another.

• Multi-topic research: each topic is its own lane.
• Per-file local code review: review each file independently in parallel, then a separate cross-file integration pass.
• Fan-out lookups: several catalogs or APIs queried at once.

If task B needs A's result, that's a sequential dependency — use a fixed pipeline / prompt chaining instead, not parallel spawning.

Match the decomposition pattern to the work:

• Parallel Task fan-out → independent subtasks, latency-sensitive, results merged at the end.
• Fixed pipeline / prompt chaining → known sequential steps where each feeds the next.
• Adaptive decomposition → open-ended investigation where the next step depends on what you just found.

Forcing inherently sequential steps into one parallel wave produces agents working with missing inputs — a correctness bug, not a speedup.

After a parallel wave returns, the coordinator's job is to aggregate: merge the findings, deduplicate, and resolve conflicts. Don't arbitrarily pick one number when two subagents disagree — annotate the conflict (dates often resolve apparent contradictions).

The coordinator also routes follow-ups: if one lane came back thin, it can spawn a targeted second wave.

When you fan out, one lane may fail while others succeed. Do not abort the whole workflow on a single failure, and never silently suppress it.

• Recover transient faults locally inside the subagent (retry).
• Escalate non-recoverable failures with partial results and structured context: failure type, attempted query, what did succeed.

The coordinator should annotate coverage gaps ("topic 2 unavailable") rather than presenting incomplete output as complete.

Each subagent's allowed_tools should be scoped to its role — least privilege. A researcher needs read/search tools; it does not need Task (no recursive spawning) and it does not need write or refund tools.

Remember the tool-count guideline: 4-5 tools per agent is optimal; 18+ degrades selection reliability. Narrow, role-scoped subagents pick the right tool far more reliably than one overloaded mega-agent.

Parallelism doesn't change the control flow. The coordinator still runs the standard agentic loop: send request → inspect stop_reason → if tool_use, run the tools (the parallel subagents) and append their results to history → repeat until end_turn.

Terminate on stop_reason, never by parsing text for words like "done". Iteration caps are a safety net, not the primary stop mechanism. Whether one Task or three ran, the loop logic is identical.

A coordinator must research three independent topics as fast as possible. Which approach correctly spawns the subagents in parallel?

Key takeaways for parallel subagent spawning:

• Multiple Task calls in one response run in parallel — there's no flag, it's a decomposition choice.
• The coordinator's allowedTools must include "Task".
• Subagents do not inherit history — pass all context explicitly in each self-contained prompt.
• Use parallel for independent subtasks; use a pipeline/chaining for sequential dependencies.
• On partial failure: recover transient faults locally, escalate non-recoverable ones with partial results — never abort the whole workflow or suppress silently.
• Scope subagents with least privilege (4-5 tools), and keep terminating on stop_reason, never on parsed text.