Claude Code now offers three ways to parallelize work: subagents inside a session, background sessions you monitor separately, and agent teams. Multiple independent Claude instances that message each other and share a task list. They sound like the same feature described three times. They're not. Picking the wrong one costs you tokens, pollutes your context, or strands work in a coordination dead-end.
I've run all three patterns in production across a personal agent fleet. This is the decision framework I wish had existed when agent teams shipped.
Same words, different architectures
Subagents spawn inside your current session. Each gets its own context window, does focused work, and returns a result to the parent. They cannot talk to each other. The parent manages all delegation and collects all output.
Agent teams (experimental, enabled via CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) spawn separate Claude Code instances coordinated by a lead. Teammates message each other directly, share a task list, and can challenge each other's hypotheses. Each teammate is a full session with full token cost.
Background sessions (what I run in tmux) are the third option the docs mention less prominently: independent sessions you dispatch and check on later, with no built-in parent-child relationship. See Claude Code in tmux background sessions for that setup.
The question isn't "should I use multiple agents." It's who coordinates, who talks to whom, and what happens to the context.
Subagents: isolated workers that report up
Reach for subagents when the task produces verbose output you don't need in the main context, like log scans, wide greps, or test runs. Or when the work is self-contained and returns a summary: research a library, review a single module, generate test cases for one file. They're also the right call when you want tool restrictions enforced per worker (a read-only research agent, a full-access implementer), and when tasks are independent and don't need cross-validation.
Don't reach for subagents when workers need to share findings and refine each other's work. And be wary of defining fifteen specialist agents. Flooding Claude with options makes automatic delegation less reliable. Three to five well-scoped agents beat a sprawling roster. Skip subagents too when the work touches the same files from multiple angles at once without a clean partition. You'll get conflicts.
Subagents are cheap relative to agent teams because only the synthesized result returns to your window. The exploration rot stays isolated.
Agent teams: peers that coordinate
Reach for agent teams when the task benefits from multiple perspectives on the same problem, like an architecture review, a security audit, or debugging a race condition. Reach for them when workers need to challenge each other's assumptions, not just report results upward, and when parallel exploration adds real value: one teammate investigates the frontend hypothesis while another tests the backend hypothesis, and they compare notes. They also fit when the task list is genuinely parallelizable with a file-level partition, across different modules or different repos.
Don't reach for agent teams when tasks are sequential or have heavy dependencies. A single session or subagent chain is cheaper and simpler. Skip them when multiple agents would edit the same files. Agent teams don't isolate teammates in git worktrees by default. And skip them when you only need the result, not the discussion. Subagents are strictly cheaper.
Agent teams add coordination overhead and use significantly more tokens than a single session. Anthropic's docs are explicit about this. They're for collaboration problems, not parallelism problems.
The decision matrix
Three questions separate the options. Who coordinates: the parent session for subagents, a lead plus self-coordination for agent teams, or you (or an orchestrator) for tmux sessions. Can workers talk to each other: no for subagents, yes for agent teams, only if you build it for tmux. What happens to context: a summary returns to the parent for subagents, N full sessions for agent teams, isolated per session for tmux.
If your goal is "parallelize side tasks and keep the main context clean," start with subagents. If your goal is "let several agents work like a small team, discuss, and cross-check," use agent teams. If your goal is "run workers overnight across different repos without me attached," use detached tmux sessions. That's what my omni orchestrator does, with filesystem state instead of in-session coordination.
Token economics
This is where theory meets invoice. A subagent that reads fifty files and returns three paragraphs costs you the subagent's window. Expensive in isolation, cheap for the parent, which never saw the fifty files.
An agent team with four teammates is four concurrent Claude instances. A thirty-minute team task can burn four times the tokens of a single session doing sequential work, even if wall-clock time is shorter. The trade is wall-clock speed and cross-validation quality against token spend.
For solo developers without an enterprise API budget, I default to: subagents for exploration inside a session, tmux workers for implementation across sessions, agent teams only for problems where I genuinely need adversarial review. Not for "make it faster."
What I run in production
My fleet doesn't use agent teams as the default coordination layer. It uses filesystem-as-database coordination: sprint folders, spec files, git branches, and a manager that dispatches tmux workers. Workers don't message each other. They read shared state from disk and write results back to disk. The workspace taxonomy article explains why undifferentiated multi-agent setups rot at scale.
Agent teams are the right tool inside a single complex debugging session. "spawn a security reviewer and an implementation reviewer and let them argue." They're the wrong tool for "run my GitHub backlog overnight". That's an orchestrator problem, and orchestrators need durable state, not in-session peer messaging.
Try both on a real task once. The distinction becomes obvious quickly: subagents feel like hiring contractors who email you a report; agent teams feel like putting people in a room with a whiteboard. Most daily work is contractor work.