Orchestrating Multiple Subagents: Parallelism, Pipelines, and Trade-offs

Parallel vs. sequential subagent dispatch

When you spawn multiple subagents, they can run in two patterns:

Parallel dispatch

Multiple subagents work simultaneously. The main agent spawns all of them at once and waits for all to finish.

Example: Three-reviewer code review

Main agent spawns:
  - security-reviewer (checking auth, data handling, injection risks)
  - performance-reviewer (checking loops, memory, algorithms)
  - maintainability-reviewer (checking readability, architecture, test coverage)

All three work at the same time.
Main agent waits for all three results.
Main agent synthesizes findings into one report.

Time: ~5 minutes (the slowest reviewer) Tokens: 3× the cost of one reviewer

When to use:

• Independent analyses (no dependencies between subagents)
• Time matters more than cost
• Subagents can work without each other's output

Sequential pipeline

Subagents work one after another. One subagent's output becomes the next subagent's input.

Example: Code refactoring pipeline

Main agent:
  1. Spawn analyzer subagent: "Find all code smells in src/"
     → Analyzer returns a list of issues

  2. Spawn refactorer subagent: "Fix these issues: [list from step 1]"
     → Refactorer fixes them

  3. Spawn test-runner subagent: "Run tests and report failures"
     → Test-runner confirms fixes work

  4. Main agent commits and opens PR

Time: 5 + 8 + 3 = 16 minutes (sum of all stages) Tokens: 1× cost of analyzer + 1× cost of refactorer + 1× cost of test-runner

When to use:

• Dependencies exist (later work depends on earlier results)
• Cost matters more than time
• Each stage builds on prior findings

Comparing orchestration patterns: subagents vs. agent teams vs. workflows

Three patterns exist for multi-agent coordination:

| Pattern | Who coordinates | Context sharing | Best for | Cost | Complexity | | :--- | :--- | :--- | :--- | :--- | :--- | | Subagents (parallel) | Main agent, turn by turn | Main agent receives final summary only | Few independent tasks; quick parallel review | Lower | Low | | Subagents (sequential) | Main agent, turn by turn | Main agent passes input/output between stages | Linear pipeline; each stage refines | Medium | Medium | | Agent teams | Lead agent coordinating teammates | Shared task list; teammates message each other | Complex multi-agent collaboration; teammates debate | Highest | High | | Dynamic workflows | JavaScript runtime script | Agents' results stored in script variables | 100+ agents; massive scale; cross-check findings | Highest | Very high |

Subagents

Pros:

• Simple to use (main agent orchestrates)
• Main conversation stays clean
• Good for 2-5 parallel subagents
• Lower cost than teams

Cons:

• Subagents cannot talk to each other
• Scale limits (practical limit ~5-10 subagents per prompt)
• Main agent must synthesize all findings

Agent teams (experimental)

Pros:

• Teammates work fully independently
• Can message each other and coordinate
• Good for 3-5 teammates doing complex work
• Shared task list prevents duplication

Cons:

• Higher token cost (each teammate is a full Claude instance)
• Requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Coordination overhead
• Session resumption is limited

Dynamic workflows

Pros:

• Massive scale (10s to 100s of agents)
• Repeatable orchestration (script is saved and reusable)
• Advanced patterns (adversarial review, cross-check, iterate)
• Agents run outside conversation context

Cons:

• Highest cost
• Requires explicit workflow syntax
• Less interactive (results come at the end)
• Best for tasks you will run multiple times

Guidance:

• 1-3 subagents in one prompt: Use subagents (parallel or sequential)
• 3-5 agents that need to coordinate directly: Use agent teams
• 10+ agents, repeatable task, cross-validation needed: Use workflows

Cost and context trade-offs

Multi-subagent orchestration uses more tokens than single-agent work. Manage cost carefully:

Illustrative cost estimate: parallel three-reviewer example

The following is a worked, illustrative estimate (not a published benchmark) to show how costs stack up across subagents. Assume the code under review is ~5 KB and pricing follows list-price-per-token rates published on the Claude API pricing page at the time of writing:

| Reviewer | Model | Input tokens (approx.) | Output tokens (approx.) | Estimated cost | | :--- | :--- | :--- | :--- | :--- | | Security | Opus | 8K (code + prompt) | 500 | ~$0.25-0.30 | | Performance | Sonnet | 8K (code + prompt) | 400 | ~$0.05-0.08 | | Maintainability | Sonnet | 8K (code + prompt) | 400 | ~$0.05-0.08 | | Total | — | — | — | ~$0.35-0.45 |

Actual costs depend on current list pricing, prompt caching, and how much context each subagent actually needs to load — always check the current pricing page rather than treating this table as a fixed quote. The broader point holds regardless of exact numbers: a few cents of model usage is far cheaper than the equivalent human reviewer time for the same diff.

Cost control strategies

1. Use cheaper models for subagents

---
name: test-runner
description: "..."
model: haiku
---

Haiku is 80% cheaper than Opus. Use it for straightforward work like test analysis.

2. Limit subagent tool access

tools: Read, Grep, Glob

Fewer tools means simpler reasoning and lower costs.

3. Scope subagent input carefully

Instead of:

Review the entire codebase for issues

Do:

Review src/auth/ (authentication module) for security issues

Smaller scope = fewer input tokens.

4. Avoid redundant parallel subagents

Running five reviewers with identical prompts wastes cost. Run 3-5 specialists with different focuses instead.

Failure handling and resilience

Multi-subagent workflows must handle failures gracefully:

Rate limits

If a subagent hits a rate limit, the main agent receives partial output. Handle it:

Main prompt: "Use security-reviewer to audit the codebase.
If the reviewer hits a rate limit, report what was checked so far
and suggest next steps."

Tool unavailability

If a subagent requests a tool not in its tools list, it cannot use it. Design subagents to work with restricted tools:

---
name: web-safe-reviewer
description: "Reviews code without external web access"
tools: Read, Grep, Glob
---

Review code for issues. Work only with the code; do not fetch external resources.

Long-running subagents

Set max_turns to prevent infinite loops:

---
name: careful-auditor
description: "..."
max_turns: 10
---

After 10 turns (plan-act-observe cycles), the subagent stops and reports findings.

Common mistake

Running too many subagents in parallel and expecting them all to finish before the main agent moves on. Claude Code runs subagents in the foreground by default, but they are not guaranteed to finish in any particular order or time. If you spawn 10 subagents and one is slow, the main agent waits for all 10.

Instead: spawn 3-5 subagents in parallel, let them finish, then decide what to do next. If you need more parallelism, use background: true and poll results, or switch to agent teams or dynamic workflows.