Subagents vs. Agent Teams: Two Ways to Split a Job

You’ve got a big job in front of your coding agent and a growing suspicion that one conversation grinding through it turn by turn is the slow way to do it.

You’re right. But “run more agents” isn’t one decision. It’s at least two different tools that look nearly identical in a demo and behave nothing alike once real work is moving through them.

The two that get confused most are subagents and agent teams. One is delegation. The other is a crew. Reach for the wrong one and you’ll waste tokens, or worse, quietly do work you can’t supervise.

The short version

A subagent is a worker you hand a task to. It goes off in its own context window, does the work, and returns a result. The intermediate noise never touches your main conversation.

An agent team is a lead plus teammates, each a full and independent session, sharing a task list and messaging each other directly while they work.

There’s a tempting one-liner here: subagents report up, teammates talk sideways. I’ve used it myself. It’s no longer quite true, and the way it broke is worth knowing.

The distinction that actually holds

Subagents can now message each other. When your agent spawns a subagent and gives it a name, that name becomes an address, and named subagents can pass messages between themselves. So “only teammates talk to each other” is a clean line that reality has smudged.

What survives, and what you should actually decide on, is who holds the plan.

With subagents, the main agent holds it. It decides turn by turn what to spin off, and every result lands back in its context. Picture a senior engineer farming out well-defined chores: go read this directory and tell me what’s in it. The four hundred lines of grep output stay outside the main thread. That context hygiene is the entire point, not a side effect.

With an agent team, a lead holds the plan but the teammates coordinate themselves, through direct messages and a shared task list they claim work from. Nobody funnels every result through one brain. Picture a crew with assigned owners who sort out the overlap by talking to each other.

So the two questions worth asking, in order:

1. Do the workers need to react to each other’s findings? If no, and only the results matter, subagents are simpler, cheaper, and cleaner.
2. Should coordination be centralized or self-managed? If you want your main agent orchestrating turn by turn, subagents. If the work is genuinely parallel and self-directing, a team.

The comparison

	Subagents	Agent teams
Shape	One session delegates; workers return results	A lead plus independent teammates working alongside each other
Communication	Return a result to the caller; named subagents can also message each other	Teammates message each other directly
Who coordinates	The main agent manages all work	Self-coordination, plus a shared task list
Context	Own window; result comes back summarized	Own window; fully independent
Token cost	Lower, you get the result rather than the transcript	Higher, every teammate is a full instance
Best for	Focused tasks where only the result matters	Work needing discussion, dissent, and convergence
Maturity	Generally available	Experimental, off by default

When to reach for which

Use subagents when a side task would flood your main conversation with output you’ll never re-read: searches, log dumps, a dependency scan, reading twenty files to find one thing. Delegate it and keep the summary. Use them when tasks are self-contained, and when you want least privilege, because a subagent definition can be restricted with a tools allowlist or a disallowedTools denylist so it cannot write no matter what it decides.

Use an agent team when the value is in the disagreement. The canonical case is a bug with several plausible causes. Spin up teammates who each argue a different hypothesis and actively try to disprove each other’s. A single agent anchors on the first plausible story and stops looking. A team that argues surfaces the explanation that survived scrutiny.

The same logic covers review with independent lenses: one teammate on security, one on performance, one on test coverage, all hitting the same pull request at once. A single reviewer drifts toward its favorite class of issue. Three with assigned lanes don’t. It also covers work that partitions cleanly across files, where each teammate owns a different area and they don’t collide.

Reach for neither when the work is sequential, edits the same files repeatedly, or is simply small. Coordination isn’t free. Three focused teammates beat five scattered ones, and one focused session beats both more often than anyone building this stuff likes to admit.

Supervising what you just bought

This is the part most write-ups skip, and it’s the part that decides whether you’re running a practice or a party trick.

More agents means more autonomous action, and autonomy is something you design around rather than simply enjoy. Field notes, verified against v2.1.263, because this feature is moving fast:

Teams are off by default, and turning them on changes ordinary delegation. You enable them with an environment variable, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, in settings or your shell:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

While that’s on, a subagent your agent names on its own launches as a full teammate. Teams can therefore form when you never asked for one. That switch has a blast radius; don’t leave it on globally and forget about it.

Permission posture is inherited at spawn. Teammates start with the lead’s permission settings. If you started the lead with prompts disabled, every teammate runs that way too, and you’ve multiplied that decision by the size of your crew rather than making it once.

Plan approval is the designed exception. A teammate’s plan is approved in the lead’s session as soon as it arrives, without a human reading it. Individual risky actions still hit permission prompts, which bubble up to the lead for you to answer. But “another agent thought the plan looked fine” is not the same as you signing off, and if your process says a human owns the judgment, read the transcript.

The platform does defend the boundary, and it’s worth knowing how. A message from another agent is labeled as coming from another session rather than from you. A teammate can’t grant consent on your behalf, and one that gets denied an action can’t relay it to a different teammate to launder it through. That’s a genuinely well-designed control, and it’s the shape every multi-agent system needs: privilege that can’t be escalated by asking a sibling nicely.

Know which settings layer wins. Managed settings apply after every other source, which is exactly why a policy layer that every agent inherits is worth maintaining. It’s also why the question of whether an agent may edit its own guardrails stops being theoretical the moment you’re running five of them.

The merge gate does not move. A team can open a pull request. A team does not merge it. The entire reason to run agents this way is so a human still reads the diff at the end, and scaling the number of agents is precisely the wrong reason to relax that.

None of this argues against teams. It’s the difference between running them like infrastructure and running them like a demo.

The actual decision

Subagents and agent teams answer the same instinct, that this job is too big for one thread, with opposite architectures. Delegation that reports back, or a crew that coordinates.

Choose by whether the workers need each other, and by who should hold the plan. Then, whichever you picked, make sure the autonomy you just bought is autonomy you can still supervise.

That last part is the job. The rest is tooling.