Claude Opus 4.6 Agent Teams: Building Multi-Agent Workflows

On February 5, Anthropic shipped Opus 4.6 with a feature that caught my attention more than the benchmark scores: agent teams. A single Claude Code session can now spin up multiple independent agents, each with its own context window, working on different parts of a project at the same time.

I've been running agent teams on real projects since the day they launched. Here's what I've learned.

What agent teams actually are

In a normal Claude Code session, you talk to one agent. It reads files, writes code, runs tests. If you need parallel work, you can spawn subagents, but those are fire-and-forget: they do a task and report back. They can't talk to each other.

Agent teams are different. You have a lead agent (your main session) that creates a team, spawns teammates, and coordinates through a shared task list. Each teammate is a full Claude Code instance with its own context window. Teammates can message each other directly, claim tasks from a shared list, and work on separate files in parallel.

Think of it like a small dev team. The lead is the tech lead who breaks down the work. The teammates are developers who each own a piece, communicate when they need to, and report back when they're done.

The tools behind the scenes

The coordination happens through a set of tools that the lead and teammates all have access to:

TeamCreate initializes a team. It writes a config file and creates a shared task directory on disk. Every team has a name that acts as a namespace linking everything together.

TaskCreate and TaskUpdate manage work. The lead creates tasks with descriptions that serve as prompts for whoever picks them up. Tasks flow through three states: pending, in progress, completed. They can have dependencies, so task B won't unblock until task A is done.

SendMessage handles communication. Teammates can send direct messages to specific agents or broadcast to everyone. The lead gets notified automatically when a teammate finishes or goes idle.

TaskList lets any agent see what work is available, who's doing what, and what's blocked. When a teammate finishes a task, it checks the list and grabs the next unblocked item.

All of this lives on disk as JSON files under ~/.claude/teams/ and ~/.claude/tasks/. Task claiming uses file locking to prevent two teammates from grabbing the same work.

How a session actually looks

Here's a realistic workflow. Say I'm building a new feature that needs a database migration, an API endpoint, and frontend components. I tell Claude:

"Create an agent team. One teammate handles the database migration, one builds the API route, one works on the React components."

The lead creates three tasks, spawns three teammates, and assigns each one their piece. Each teammate gets the full project context (CLAUDE.md, MCP servers, installed skills) plus their specific task description. They don't inherit the lead's conversation history though, so the task description matters.

In my terminal, I can cycle through teammates with Shift+Down to check on progress or give additional instructions. If I'm running tmux, each teammate gets its own pane so I can see all the work happening at once.

The teammates work independently. When the migration teammate finishes the schema, it marks its task complete. If the API teammate was blocked on the schema, that task automatically unblocks and the teammate picks it up. The frontend teammate, meanwhile, has been working on components the whole time since it had no dependencies.

When agent teams actually help

After running these for a few weeks, the pattern is clear.

The highest-value use case is parallel research. I use this constantly: three teammates investigating different aspects of a problem, then challenging each other's findings. Sequential investigation suffers from anchoring - once you find one plausible answer, you stop looking. Multiple investigators don't have that problem.

It also works well when the work maps cleanly to separate files or directories. Frontend, backend, tests - each teammate owns their piece with no file conflicts.

Code review benefits from the same idea. One teammate focused on security, one on performance, one on test coverage. A single reviewer tends to fixate on one category of issues. Three specialists in parallel catch more.

My favorite pattern is competing hypotheses for debugging. Five teammates each testing a different theory about why something broke, actively trying to disprove each other. The theory that survives this adversarial process is more likely correct.

When they get in the way

Agent teams are not always the right tool. I've wasted tokens learning this.

If step 2 depends on step 1's output, a single agent is faster. The coordination overhead isn't worth it when most teammates are just waiting.

Two teammates editing the same file leads to overwrites - I learned this the hard way. You have to break work so each teammate owns different files, or you'll spend more time resolving conflicts than you saved by parallelizing.

And don't use a team to rename a variable. If the work takes a single agent five minutes, spinning up a team adds coordination time for no benefit. Similarly, if every task depends on every other task, the parallelism collapses and you're paying for multiple context windows while agents sit idle.

The C compiler experiment

Anthropic ran the most ambitious test so far: they tasked 16 parallel agents with building a C compiler in Rust from scratch. Over nearly 2,000 sessions, consuming 2 billion input tokens at a cost of about $20,000, the team produced 100,000 lines of code.

The compiler can build Linux 6.9 on x86, ARM, and RISC-V. It compiles QEMU, FFmpeg, SQLite, PostgreSQL, and Redis. It passes 99% of the GCC torture test suite. And yes, it runs Doom.

The coordination mechanism was simple: agents locked tasks via text files, pulled changes, merged, and pushed. But the key finding was about task quality. When agents hit the Linux kernel (one giant interconnected task), all 16 agents piled onto the same bug, fixed it in parallel, and overwrote each other's work. The parallelism only works when tasks are genuinely independent.

The other critical insight: "the task verifier is nearly perfect, otherwise Claude will solve the wrong problem." Good tests are the backbone of autonomous agent work.

Practical tips from real usage

The task description is the prompt. If you're vague ("handle the database stuff"), the teammate will make assumptions you don't want. Be specific about files, expected behavior, and constraints. I've found that five minutes writing a good task description saves an hour of wasted agent time.

If you're new to agent teams, don't jump straight to parallel implementation. Run a parallel code review or have teammates research different libraries. These have clear boundaries and low risk. You'll get a feel for the coordination dynamics without betting a feature on it.

Letting a team run unattended too long is expensive. Check in on teammate progress, redirect approaches that aren't working, and shut down teammates that have gone off track. I aim for 5-6 tasks per teammate - small enough to keep a rhythm of check-ins, large enough that each one produces a clear deliverable.

One practical annoyance: every time a teammate needs a permission it doesn't have, the request bubbles up to the lead. Pre-approve common operations in your permission settings before starting, or you'll spend half the session clicking "approve."

Current limitations

Agent teams are still in research preview. Some things to know:

You can't resume teammates after restarting a session. If you /resume, the lead might try messaging teammates that no longer exist. You'll need to spawn new ones.

Tasks sometimes don't get marked complete properly, which blocks dependent work. When something seems stuck, check whether the work is actually done and update the status manually.

Only the lead can manage the team. Teammates can't spawn their own teams or promote themselves. One team per session, one lead per team.

Context doesn't persist between sessions. Each teammate starts fresh with project context plus their task description. There's no shared memory between runs.

Token usage scales with team size. Each teammate has its own full context window. For research and review, the extra cost is usually worth it. For routine tasks, stick with a single agent.

What this means for how we build

Agent teams are rough around the edges, but the pattern is sound. Break complex work into independent pieces, assign specialists, let them communicate and self-coordinate.

What strikes me is how familiar the failure modes are. Vague specs lead to wasted effort - same as with humans. Too many dependencies and nobody can make progress. Shared files create conflicts. The teams that work best are the ones with clear ownership, which is also true of every engineering team I've been on.

If you're building AI agent workflows, agent teams are worth experimenting with. Start small, pick the right problems, and don't expect magic. The teams that work best are the ones where you'd want multiple humans on the job anyway.