Claude Code has several mechanisms for parallel work, and these are not different names for one feature but different models with different cost and purpose. A subagent works in a child context of one session and returns a result to the parent. A background subagent does the same, but the result comes later. The agent view coordinates several independent Claude Code sessions. An agent team is teammates that can talk and share a task list. A workflow is declarative orchestration of several steps. Confusing them means choosing the wrong tool for the task.
It helps to gather these mechanisms into a table once by context, way of communication, file handling and best scenario. Below is such a map - from a subagent to a workflow. You return to it when deciding how to parallelize work: for exploration and specialist review a subagent suffices, for many independent tasks the agent view with separate worktrees, for interdependent work a team, and for a repeatable process a workflow. Choosing the mechanism matters more than the mere fact of parallelism.
| Mechanism | Context | Files | Best scenario |
|---|---|---|---|
| subagent | Child within one session | Shared tree or worktree | Exploration, specialist review |
| background subagent | Child, result later | Depends on isolation | A long test, independent search |
| agent view | Several independent sessions | Separate worktrees | Many independent tasks |
| agent team | Teammates with coordination | Explicit ownership split | Interdependent work |
| workflow | Declarative orchestration | Set by the workflow | A repeatable process |
The agent view launches as a separate session-management interface: each has its own history, permission mode, model, effort and often its own worktree. It is the best choice when tasks must not share context - each goes on its own, and an operator coordinates. Agent teams, on the contrary, are needed when participants must coordinate among themselves, but they increase token spend and operational complexity, so you take them only where interaction is truly required.
The key rule for teams is to assign file ownership in advance. Two agents editing one module create not a speedup but a merge conflict and a divergence of assumptions: each proceeds from its own picture, and the results do not converge. Workflows express a durable process - for example, exploration, implementation, tests, independent review - but they are introduced only after the manual procedure has become stable and measurable. Otherwise uncertainty is automated, not order.
Safe decomposition gives each worker a minimal context, a definition of done, tool constraints and the expected output. It helps to see such a layout once: two read-only tasks to explore the API boundary and the test harness, one implementation task with ownership over its own directory in an isolated worktree and one independent read-only task to review the final diff. Results are accepted only after a shared integration test, not separately from each worker.
Cost control is a mandatory part of parallelism. Each session and subagent has its own context and its own model calls, so parallelism reduces wall-clock time but usually increases the total token spend. A cheaper model is routed to bounded lookups only after quality is measured; and you do not split into agents a task solved by one rg and reading a couple of files. A swarm of agents is a spend multiplier, and launching it without need is more expensive and dumber than a single pass.
The engineering conclusion about parallelism is simple and practical: you parallelize independent areas of knowledge or ownership, not sequential stages of one change. The stages of one change by definition depend on each other, and spreading them across agents means breeding desynchronization. The most predictable first step is two read-only researchers and one implementation owner: the exploration goes in parallel and cheaply, while only one changes files, and no conflicts arise.
The typical parallelism failures are predictable. Two agents on one module giving a merge conflict instead of a speedup. A team where independent sessions would suffice - excess spend and complexity. A workflow over a not-yet-stable manual procedure - automated uncertainty. And splitting into agents what a single pass solves. Choose the mechanism for the task, assign ownership in advance, accept results after an integration test, and parallelize the independent, not the stages of one change.
# Safe decomposition: minimal context and output per worker
Task A: explore the API boundary -> a map of callers (read-only)
Task B: explore the test harness -> commands and fixtures (read-only)
Task C: implement module X, ownership = src/x/**, isolated worktree
Task D: independent review of the final diff (read-only)
# merge/accept - only after a shared integration test