Subagents vs Agent Teams

The structural difference

Subagents                        Agent teams

    lead session                 session A ←→ session B
    ├── subagent (search)              ↕          ↕
    ├── subagent (review)        session C ←→ session D
    └── subagent (tests)
    ▲ results return here        peers, persistent, messaging

Subagents are a tree. Agent teams are a graph.

Why you would delegate at all

The honest reason is context, not speed.

“Find every place this pattern appears across the repository” is a question whose answer is one paragraph and whose process is thousands of tokens of file contents. Doing it inline means the main session carries those file dumps for the rest of its life.

A subagent pays that cost in a context window that gets thrown away, and returns the paragraph.

Against that: every subagent starts cold. It has none of the context the parent built up, so anything requiring the conversation so far has to be re-explained. Spawning one for a task you could do inline is a straight loss.

Why you would run a team

Different problem. Not “this subtask is expensive” but “these are four separate efforts that will run for hours.”

Cross-session messaging is what makes it a team rather than four unrelated sessions: one can tell another that the interface it depends on has changed.

Worktrees are documented alongside for the obvious reason — two sessions editing one working directory will conflict.

Custom subagents are a safety tool

A subagent can be constrained: a specific model, a restricted tool set, its own permissions. A read-only exploration agent genuinely cannot write, regardless of what it is asked. That is a stronger guarantee than instructing a general-purpose agent to be careful.

At scale

If you find yourself hand-building orchestration, Anthropic documents dynamic workflows as the pattern for coordinating subagents at scale, and has written about how the Claude Code team uses it internally.