Claude Code Agent Teams vs Subagents: When to Use Each

I run most of my automation through Hermes, an agent layer I built on top of the Claude Agent SDK, and delegation is the default posture for anything that isn't a single quick call. Before Agent Teams existed, delegation meant one thing: spin up a subagent, give it a scoped job, let it work in its own context window, and read back what it returns. That's a hierarchy — a lead session handing out tickets and collecting results. It's cheap because a subagent only costs you the tokens for its own work; the calling session never sees its intermediate reasoning, just the final answer.

Agent Teams, which Claude Code shipped as an experimental feature in early 2026, is a different shape entirely. Instead of a hierarchy, teammates share a live task list — closer to a kanban board than an org chart. A lead agent seeds the board with tasks, teammates claim work off it, post results back to it, and can message each other directly without routing through the lead at all. Each teammate gets its own git worktree so simultaneous file edits don't stomp on each other on disk.

The row that trips people up is failure mode. A bad subagent result is cheap — you read it, discard it, retry. A bad teammate is more expensive precisely because Agent Teams is designed for the group to act on each other's output: if one teammate posts a wrong finding to the shared board with enough confidence, the others can build on it before you ever see the mistake. That asymmetry alone is a reason to keep teams reserved for work where cross-checking is the point, not the risk.

Subagents are the right default whenever you only care about the result, not the deliberation that produced it. A code review, a targeted debugging pass, an architecture sanity-check, a research question that needs a few tool calls and a summary — all of these are one-way trips. You hand off a scoped task, the subagent burns its own context figuring it out, and you get back a clean answer without any of the noise it took to get there. That isolation is also what keeps subagents cheap: the calling session's context never grows with the subagent's working notes, only its conclusion.

I went deep on exactly why that isolation carries a token premium of its own — spinning up a fresh context costs more than it looks like on paper — in why Claude subagents cost 4x more tokens, and it's still worth paying in the cases above, because the alternative — doing it all in the main session — bloats the one context you actually need to stay sharp for the rest of the task.

Sequential work is the other clear win for subagents, or no delegation at all. If step two genuinely depends on step one's output, there's no parallelism to unlock by adding a team — you'd just be paying coordination overhead to serialize work that was already going to run in order. Same for anything that edits a single file: two agents can't usefully collaborate on one function at the same time, worktree or not.

Agent Teams earns its overhead when the work is genuinely parallel andbenefits from the agents seeing each other's output mid-task, not just at the end. A few shapes come up again and again:

• Competing hypotheses on a hard bug — two or three agents chase different root causes at once, and the first one to confirm a theory can flag it so the others stop chasing dead ends.
• A review split across independent modules — separate teammates own separate files or services, post findings to the shared board, and a lead synthesizes the combined picture.
• Implementation paired with live verification — one teammate builds while another writes and runs tests against the in-progress work, catching regressions before the build is even called done.
• Migration or incident work where multiple independent fronts need progress at once and nobody wants to be the bottleneck relaying status between them.

Notice the common thread: in every case, the value comes from agents comparing notes while working, not from parallelism alone. If you just need three independent things done and don't care whether the workers talk to each other, three subagents running in parallel and reporting back to you individually gets the same wall-clock speedup for a fraction of the coordination cost.

Git worktrees are the piece that makes Agent Teams safe to run unattended: each teammate gets its own working directory backed by the same repository, so two agents editing different files never collide on disk mid-run. That solves exactly one problem — simultaneous file collisions — and it's easy to read that guarantee as bigger than it is.

The fix is boring and easy to skip when a team run feels self-managing: decide who reviews and merges the worktrees before the team starts, not after three branches have already diverged on the same shared file. I treat it the same as any other control-flow discipline I put around autonomous loops — deterministic state and a clear owner beat trusting the run to sort itself out, the same lesson from the cost controls I wire into every autopilot loop.

Four questions, in order, and the first one that gives you a clear answer decides it:

• 1Is the work actually parallel? If step two needs step one's output, or everything touches one file, there's nothing to split — use a single session or one subagent.
• 2Do the agents need to see each other's output mid-task? If each piece is independent and only you need the combined result at the end, use subagents that report back individually.
• 3Is the coordination overhead worth it? Agent Teams spends real tokens on the shared task list and peer messaging on top of the actual work — only accept that when the parallel time savings clearly beat it.
• 4Who merges the worktrees? Decide before the team starts. If you can't answer this one, you're not ready to run a team unattended.

It's the same discipline I use when deciding between a subagent and a packaged Skill for a repeated task — the question isn't “which feature is fancier,” it's “what does this specific job actually need,” which I broke down in Claude Skills vs Subagents. In my own delegation, that ordering plays out lopsided on purpose: the large majority of what I hand off is scoped enough to be a subagent, and Agent Teams gets reserved for the smaller slice of work that's truly collaborative. That's also exactly the split covered in the official Claude Code Agent Teams documentation, which flags the feature as best for parallel research and review rather than as a default replacement for subagents.

• Subagents are a hierarchy: delegate, isolate, report back. Agent Teams is a shared task list with peer-to-peer messaging — a genuinely different coordination model, not a bigger version of subagents.
• Default to subagents. They're cheaper, and most delegated work is scoped enough that you only need the final answer, not agents comparing notes mid-task.
• Reach for Agent Teams only when work is genuinely parallel and benefits from agents seeing each other's output while working — competing hypotheses, split reviews, build-plus-verify pairs.
• Git worktrees stop file collisions during the run. They do not merge themselves — decide who owns the merge before the team starts.
• If you can't say in one sentence why the work needs teammates to talk to each other, it's a subagent job.