Why Splitting a Task into 5 Subagents Can Be Slower Than a Single Agent

Task Structure Precedes Agent Count: Dependency Chains Lock Total Duration

The official docs advise parallelism only when research paths are independent. When tasks depend on each other, the recommended approach is a serial chain where each subagent finishes, returns results to the lead agent, which then passes context to the next.

If any of the five tasks contains a dependency chain A→B→C, the total time is bound by that chain—the critical path—because each step must wait for the previous result, and each hand‑off incurs an extra round‑trip cost.

This mirrors Amdahl's Law: adding processors cannot overcome the serial portion of work, and coordination costs between agents are far higher than between CPU cores.

Therefore, before counting agents, draw a dependency graph to identify truly parallelizable parts, which are often fewer than expected.

Tax #1: Re‑learning Context for Each Subagent

Subagents start without the knowledge accumulated in the main conversation. They must reread files like CLAUDE.md, scan directories, and grep the same set of files, repeating this work five times.

Anthropic’s blog notes that insufficiently detailed task descriptions cause agents to duplicate effort and miss information. The lead agent’s prompt must include four elements—goal, output format, tool and source guidance, and clear task boundaries—each of which adds token cost when re‑packed for subagents.

Tax #2: Scheduler Limits and Blocking

Default concurrency: subagents run in background (v2.1.198+).

Blocking condition: execution blocks until a required result is available.

Concurrency limit: default 20; exceeding this returns an error, not a queue.

Session limit: up to 200 subagents per conversation.

Nesting: disabled; subagents cannot spawn sub‑subagents.

Mutual communication: not supported; subagents cannot exchange information.

Exceeding the 20‑agent limit triggers immediate errors, and retrying without waiting for running agents to finish wastes additional cycles.

Tax #3: Shared File Ownership Complications

Read‑only subagents incur negligible conflict, but once any subagent writes, ownership must be clearly defined. The author recounts a case where five animation‑generation subagents unintentionally shared a player component, leading to interface mismatches and extensive rework.

The solution is to assign exclusive write zones per agent, freeze shared code, or handle shared modifications in a separate preparatory task.

Claude Code offers worktree isolation, which provides physical write separation but does not automate merging or resolve semantic conflicts. Moreover, worktrees are created from the repository’s default branch, so unmerged changes in the current session are invisible to subagents.

Tax #4: Single‑Point Aggregation and Acceptance

After subagents finish, the lead agent must collect, verify, and merge results. Detailed subagent outputs can fill the lead agent’s context, negating any isolation gains.

Anthropic confirms that lead agents execute subagents synchronously, waiting for the entire batch before proceeding. The acceptance phase is strictly serial: each deliverable is read, aligned, merged, and tested one by one.

Errors in any subagent are only discovered after all have completed, amplifying the impact and delaying detection.

Cost Accounting: Official Numbers

Anthropic’s engineering blog reports that a single agent consumes roughly four times the tokens of a normal conversation, while a multi‑agent system consumes about fifteen times. They recommend multi‑agent architectures only for high‑value tasks that can afford this premium.

Typical scales: simple fact‑checking uses 1 agent with 3–10 tool calls; comparative tasks use 2–4 subagents with 10–15 calls each; complex research may justify more than 10 agents. Coding tasks generally have lower parallelizability.

Interview Answer Framework (60‑90 seconds)

Break the intuition (15 s): Parallel speedup requires fully independent sub‑tasks, which is rare in coding work.

List the four taxes (30 s):

Repeated context loading for each subagent.

Dependency chains turning parallelism into serial execution.

File‑ownership conflicts; worktree isolates writes but not merges.

Single‑point aggregation and acceptance by the lead agent.

Provide numbers (20 s): Anthropic cites ~4× token cost per agent and ~15× for multi‑agent setups, stressing that only high‑value tasks justify this.

Conclude (15 s): Draw a dependency graph first; only tasks with clean ownership and objective, automatable acceptance should be parallelized.

Likely Follow‑Up Questions

How to define file ownership? Assign exclusive write directories per agent, whitelist read‑only tools, and centralize merges.

Does worktree solve conflict issues? It only provides physical isolation; it does not handle semantic conflicts or visibility of unmerged changes.

When does 5 agents beat 1? When tasks are fully independent, produce large intermediate artifacts but small final results, and have objective, automatable acceptance—e.g., large‑scale repository audits.

Final Takeaways

Parallel gains are dictated by task dependency structure, not agent count. The four taxes—re‑learning context, dependency serialization, file‑ownership conflicts, and single‑point aggregation—are documented in official docs and engineering blogs. Worktree offers write isolation but not merge automation, and its default branch source can hide recent changes.

Treat subagents primarily as a context‑management tool rather than a pure performance optimizer; when tasks cannot be cleanly split, a single agent often remains the fastest solution.