Agent Teams

Coordinate multiple AI agents that communicate with each other, claim tasks from a shared list, and merge their own work — turning human-directed parallelism into automated collaboration.

Understand This First

• Parallelization – agent teams automate what parallelization requires you to manage by hand.
• Subagent – subagents delegate hierarchically; agent teams add peer-to-peer coordination.
• Worktree Isolation – each teammate works in its own worktree to prevent file conflicts.

Context

At the agentic level, Agent Teams represent a coordination primitive that sits above Parallelization and Subagent. Where parallelization requires a human to decompose work, assign tasks, monitor progress, and integrate results, Agent Teams push that coordination into the agents themselves. One session acts as team lead. It breaks the work down, spawns teammates, and maintains a shared task list. The teammates claim tasks, work independently in their own worktrees, and communicate with each other directly when they discover something relevant.

The shift matters because the human coordination bottleneck is what limits parallelism in practice. A developer can comfortably direct two or three agents. Beyond that, the overhead of context-switching between agent sessions, tracking who’s doing what, and reconciling conflicts eats into the throughput gains. Agent Teams remove that bottleneck by letting agents coordinate among themselves.

Problem

How do you scale agentic work beyond a handful of parallel agents without drowning in coordination overhead?

Manual parallelization works well at small scale. But as the number of parallel agents grows, the human director becomes the bottleneck. They have to decompose the work, write task descriptions, assign agents, monitor progress, answer questions, resolve conflicts, and integrate results. The agents themselves can’t talk to each other, so every piece of shared information routes through the human. At five or ten agents, the management burden can exceed the time saved by parallelizing.

Forces

• Coordination cost grows with agent count. Each additional agent adds management overhead for the human.
• Agents discover things during work that other agents need to know, but with no communication channel between them, those discoveries are trapped.
• File conflicts multiply when agents work on related parts of a codebase, and the human must resolve every merge conflict manually.
• Task dependencies shift during execution. A task that seemed independent turns out to need results from another task, but neither agent knows about the other’s progress.

Solution

Designate one agent session as the team lead. The lead decomposes the work into a shared task list with dependency tracking, then spawns teammates — each running in its own context window and worktree. The teammates self-organize: they claim tasks from the shared list, work independently, and communicate discoveries to each other through peer messaging. The lead monitors progress, resolves disputes, and coordinates the final integration.

Three coordination mechanisms distinguish Agent Teams from manual parallelization:

Shared task list. The lead creates a list of tasks with dependencies. Teammates claim tasks when they’re ready, rather than waiting for the human to assign them. When a task’s prerequisites are complete, it becomes available. This removes the human as a scheduling bottleneck.

Peer-to-peer messaging. Teammates can send messages to each other without routing through the lead or the human. When one teammate discovers that a shared utility function’s signature has changed, it notifies the others directly. This prevents the situation where three agents independently discover the same breaking change by trial and error.

Automatic worktree management. Each teammate gets its own isolated worktree, and the team infrastructure handles creating worktrees, merging completed work, and flagging conflicts. The human still reviews and approves merges, but the mechanical work of branch management is automated.

The human’s role shifts from director to reviewer. Instead of assigning tasks, monitoring chat windows, and ferrying information between agents, you review the team’s output, approve merges, and intervene only when the team gets stuck.

How It Plays Out

A developer needs to add a payment processing module with four components: a database schema, an API layer, a webhook handler, and an integration test suite. She starts a team lead session and describes the goal. The lead decomposes it into four tasks, notes that the API and webhook handler both depend on the schema, and spawns four teammates. The schema teammate finishes first. It messages the API and webhook teammates: “Schema is done, here’s the table structure.” Both pick up their tasks without the developer needing to copy-paste anything between sessions. The test teammate waits until the API is ready, then writes integration tests against the actual endpoints. The whole module takes forty minutes. The developer’s involvement was limited to describing the goal, reviewing the decomposition, and approving the final merge.

An engineering team is migrating a monolithic Python application to a package-based architecture. The lead agent analyzes the dependency graph and creates a task list of 12 extraction tasks, ordered so that leaf packages (those with no internal dependencies) are extracted first. Eight teammates work through the list over several hours, each claiming the next available task. When one teammate discovers that two packages have a circular dependency the original analysis missed, it messages the lead, which re-plans those two tasks as a single combined extraction. The human intervenes twice: once to approve a naming convention the agents disagreed on, and once to override a teammate’s decision to add a compatibility shim that would have made the migration harder to finish later.

Consequences

Agent Teams unlock parallelism at a scale that manual coordination can’t sustain. A team of five or ten agents working on a well-decomposed problem can accomplish in an hour what would take a full day of sequential work. The peer messaging means discoveries propagate without the human becoming an information bottleneck, and the shared task list means agents don’t sit idle waiting for assignments.

The costs are real. Team coordination consumes tokens: every peer message, every task status update, and every merge operation uses context in each involved agent’s window. For small, well-defined tasks that a single agent can handle in one session, spawning a team adds overhead without benefit. There’s also a trust question. When agents coordinate among themselves, the human has less visibility into why decisions were made. Good team implementations log all inter-agent communication, but reviewing those logs takes time.

The sweet spot is projects with clear module boundaries, well-defined interfaces, and enough independent work to keep multiple agents busy. If your codebase is a tangle of circular dependencies, agents will spend more time messaging each other about conflicts than doing productive work. Fix the architecture first, then parallelize.

Related Patterns

• Extends: Parallelization – parallelization is human-directed; agent teams automate the coordination.
• Extends: Subagent – subagent is hierarchical delegation; agent teams add peer-to-peer communication.
• Uses: Worktree Isolation – each teammate works in its own worktree to prevent file conflicts.
• Uses: Thread-per-Task – each teammate runs in its own thread with its own context window.
• Uses: Decomposition – effective team coordination requires effective task decomposition.
• Uses: Plan Mode – the team lead typically plans before spawning teammates.
• Related: Context Window – peer messaging and team coordination consume context in each agent’s window.

Sources

Anthropic shipped Agent Teams as an experimental feature in Claude Code in February 2026, introducing the shared task list and peer messaging primitives that distinguish teams from manual parallelization. Addy Osmani framed the architectural shift as the move from a “conductor model” (one agent, synchronous, limited by a single context window) to an “orchestrator model” (multiple agents with their own context windows, working asynchronously and communicating peer-to-peer). The pattern builds on decades of multi-agent systems research in robotics and distributed AI, but the 2026 implementations are the first to make it practical for everyday coding work.