Subagents, Worktrees, Agent Teams, or Cloud Agents: How to Pick the Right AI Orchestration Pattern

Cursor 3 shipped a full Agents Window in April 2026. Claude Code has shipped subagents, worktrees, and the experimental Agent Teams feature since February. Every week there is a new explainer telling you that multi-agent AI is here.

What most of them skip is the part developers actually need: which pattern fits which problem, and which ones will burn your token budget for no good reason.

There are four distinct orchestration primitives across these two tools right now. They solve different coordination problems. Picking the wrong one does not just waste money — it adds complexity that a simpler approach handles better. Here is how to tell them apart.

The four primitives#

The key question is not "which tool is more powerful." It is "how much do my agents actually need to coordinate with each other?" The answer maps directly to which primitive earns its overhead.

Pattern 1: In-session subagents#

This is the default multi-agent primitive in Claude Code and the one to reach for first.

When you ask Claude to delegate a sub-task to a specialist, it uses the Task tool internally. The main session acts as orchestrator. Each subagent spins up its own context window, runs a focused task, and returns results to the orchestrator. All of this happens inside a single terminal session.

What subagents are good at:

• Breaking a large task into focused specialist passes (one agent researches, another implements, another reviews)
• Writing and running tests in parallel with implementation
• Cross-layer work where a coordinator needs to synthesize results before deciding on next steps

What subagents are not good at:

Subagents cannot communicate directly with each other. They cannot challenge each other's findings. Every result flows back through the orchestrator. If you have 10 subagents and each one returns 3,000 tokens of output, your orchestrator context accumulates all of it — at scale, this causes the context to blow up.

One documented case hit 887K tokens per minute with a 10-agent pipeline before the orchestrator hit its context ceiling. For small to medium pipelines, subagents are efficient and cheap. For large ones, the orchestrator context is the bottleneck.

No special setup required. Just describe a task and ask Claude to delegate parts of it. Claude will use the Task tool automatically when the problem warrants it.

Pattern 2: Git worktrees#

Worktrees give each agent — or each session you open — an isolated branch and working directory. There are no cross-agent dependencies, no shared state, no coordination layer. You run separate sessions that cannot conflict with each other at the filesystem level.

Claude Code has had native worktree support since early 2026. The flag is --worktree:

# Start Claude in an isolated worktree named "auth-refactor"
# Creates .claude/worktrees/auth-refactor/ on a new branch
claude --worktree auth-refactor
 
# Let Claude name it automatically
claude --worktree

When you exit a worktree session without making changes, Claude removes the worktree and branch automatically. If you made changes, it prompts you to keep or discard them.

Cursor 3 brings the same concept into the IDE with the /worktree command in the Agents panel:

/worktree implement dark mode toggle

Cursor creates the branch, isolates the working directory, and spawns an agent scoped to it — all from a single chat command. The agent's progress appears in Agent Tabs so you can monitor multiple worktrees side by side.

When to use worktrees:

• Parallel independent features that have no shared code paths
• Exploring multiple solutions to the same problem simultaneously
• Long sessions where you want full isolation from your main branch

The tradeoff: Someone has to merge. Worktrees only prevent conflicts during execution — they do not resolve them at merge time. If the tasks are not truly independent, you will spend coordination time on the merge that you saved on the parallelism.

Pattern 3: Claude Code Agent Teams#

Agent Teams are the heaviest primitive. They are also the most capable when the task genuinely needs it.

The model: one Claude Code session acts as the team lead. It creates tasks and coordinates. Two to fifteen other Claude Code processes act as teammates. Each teammate has its own full context window, runs independently, and can communicate directly with any other teammate via a peer-to-peer mailbox.

Three coordination primitives that subagents lack:

• Shared task list with dependency tracking. Tasks have states (pending, in progress, completed) and can declare dependencies. A dependent task cannot be claimed until its prerequisites are done.
• Peer-to-peer messaging. Teammates can message each other directly using SendMessage, not just report back up to the lead. One agent can challenge another's finding, request clarification, or hand off partial work.
• File locking. When a teammate claims a task, it acquires a file lock. Two agents cannot overwrite each other's work simultaneously.

Setup:

Requires Claude Code v2.1.32 or later (claude --version).

# Check your version first — v2.1.32+ required
claude --version
 
# Enable per-session
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude

To enable permanently, add to ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "teammateMode": "tmux"
}

teammateMode options: "auto" (default, detects your environment), "tmux" (each teammate in its own pane), "in-process" (single terminal, keyboard shortcuts to switch between teammates).

With tmux mode, each teammate gets its own pane. You can watch all of them simultaneously. In-process mode runs everything in a single terminal, with keyboard shortcuts to navigate between teammates.

Once enabled, describe the team structure in plain language:

Create an agent team to implement user authentication. 
Use a 4-person team: one for the database schema, one for 
the API routes, one for the frontend forms, and a fourth 
to write integration tests once the other three are complete.

The lead parses this, creates tasks with dependencies, and coordinates the work. The database, API, and frontend tasks run in parallel. The test task becomes available only when all three are marked complete.

When Agent Teams are worth it:

• Complex features where multiple concerns need to develop in parallel and then converge
• Research tasks where you want agents to investigate different hypotheses and challenge each other
• Cross-layer work spanning frontend, backend, and tests where the agents need to share interfaces and coordinate decisions

The token cost reality:

Each teammate initializes with a full context window. A 4-person team loading the same codebase means 4x the initialization cost before any task work begins. Plan on 3–4x the token spend of a single session for a typical team.

Pattern 4: Cursor 3 cloud agents#

Cursor 3 introduced two modes of parallel execution. Local agents run up to 8 at once, each in a git worktree, visible in the Agents Window inside the IDE. Cloud agents are different in a meaningful way: they run in isolated Linux VMs that have nothing to do with your machine.

Each cloud agent gets:

• A full Linux VM with its own filesystem
• A terminal and browser
• A running instance of your development environment
• An async execution model: your laptop can be off

The workflow: you dispatch a task, close your laptop, and check results later. The agent clones your repo, runs the task, and pushes changes for review. No resource competition with your local session, no requirement to stay connected.

# In the Cursor Agents panel
/worktree fix the cart calculation bug and add a test for it

Cursor spawns the agent in a cloud VM, tracks progress in Agent Tabs, and surfaces the result for review when done.

When cloud agents earn their cost:

Cloud agents always bill usage-based on top of your $20/month Pro subscription. They are worth it when:

• The task is long-running enough that keeping your machine on is a genuine cost
• You are parallelizing tasks that would otherwise block each other
• You want visual monitoring through the IDE rather than switching to a terminal

What cloud agents are not:

They are not a coordination layer. Each cloud agent works independently, the same way worktrees do. There is no shared task list or peer-to-peer messaging between them. If the tasks need to coordinate, you need Agent Teams — or you need to sequence them yourself.

The decision table#

Use this as the first filter before spinning up anything:

The coordination-need diagnostic#

Before picking a pattern, answer these three questions:

1. Do my agents need to talk to each other during the task — not just report results? If yes, you need Agent Teams. If no, worktrees or subagents are cheaper.

2. Are the tasks genuinely independent — different files, different branches, no shared interfaces? If yes, worktrees. If they share code paths, you need coordination or careful sequencing.

3. Do I need to stay connected to my machine? If no, Cursor cloud agents. If yes, Claude Code worktrees or local Cursor agents.

For most tasks, the answer to question one is no. Agents do not need to debate. They need to produce output and let you decide what to merge. That means worktrees or subagents — the two lowest-overhead options — handle the majority of real-world parallel workflows.

Tradeoffs and caveats#

Agent Teams token cost can surprise you. The 3–4x multiplier is per teammate — a 5-person team costs roughly 5x a single session at initialization. For a task that would take one focused session an hour to complete, Agent Teams might save wall-clock time but cost significantly more in tokens. Track the cost before committing to large teams.

Worktrees require clean task decomposition. The isolation that prevents conflicts during execution becomes a liability at merge time. Tasks with overlapping touchpoints produce conflicts that have to be resolved manually. The coordination savings are real only when the decomposition is real.

Cursor cloud agents bill usage-based. You can run up to 8 in parallel, and each bills separately. For exploratory work or one-off tasks, this is fine. For high-volume automated workflows, the cost adds up. Monitor usage in the Cursor billing dashboard.

/best-of-n is partially broken. As of early April 2026, there are confirmed reports of /best-of-n falling back to a single-agent execution in some configurations. Verify the behavior with a quick test before using it on anything important.

Agent Teams are experimental. The feature is gated behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS for a reason. Expect rough edges, and do not use it in automated pipelines.

What to actually do#

Start with the simplest pattern that fits the problem.

For most tasks — even complex ones — a single focused Claude Code session with in-session subagents handles more than developers expect. The orchestrator context limit is the ceiling, and for anything under 5–6 subagents with bounded outputs, you will not hit it.

When tasks are genuinely parallel and independent, add worktrees. One flag, full isolation, no extra processes.

Only reach for Agent Teams when agents need to share state and coordinate decisions autonomously. The P2P messaging and shared task list are genuinely useful for the right problem — they are just expensive to use on the wrong one.

Use Cursor cloud agents when the task is long enough that asynchronous execution matters, or when you want the IDE's visual monitoring instead of terminal management.

The pattern that matches the coordination need is always the right one. The one that sounds most impressive rarely is.