Claude Opus 4.6 Agent Teams: How to Build a Multi-Agent Workflow

Anthropic shipped Opus 4.6 on February 5. One feature 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 these on real projects since launch day. 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. No communication between them.

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

A small dev team, basically. The lead plays tech lead, breaking down the work. The teammates are developers: each one takes a piece, communicates when needed, reports back when done.

The coordination tools

The lead and the teammates share the same toolset.

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.

TaskCreate and TaskUpdate manage the work. The lead creates tasks whose descriptions serve as prompts for whoever picks them up. Three possible states: pending, in progress, completed. A task can depend on another: task B won't unblock until task A is done.

SendMessage handles communication. A teammate sends a direct message to a specific agent or broadcasts to everyone. The lead gets notified automatically when a teammate finishes or goes idle.

TaskList shows every agent what work is available, who's doing what, what's blocked. A teammate that finishes a task checks the list and grabs the next unblocked item.

All of it lives on disk, as JSON, under ~/.claude/teams/ and ~/.claude/tasks/. Task claiming uses file locking so two teammates can't grab the same work.

A typical session

I'm building a 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, assigns each one their piece. Each teammate gets the full project context (CLAUDE.md, MCP servers, installed skills) plus its own task description. It doesn't inherit the lead's conversation history. The task description carries all the weight.

In my terminal, I cycle through teammates with Shift+Down to check progress or give an extra instruction. With tmux, each teammate gets its own pane, so I can see all the work at once.

The teammates move independently. The migration teammate finishes the schema, marks its task complete. The API teammate, who was waiting on that schema, unblocks on its own and picks up the work. The frontend teammate, meanwhile, has been on the components from the start: no dependency to wait on.

When agent teams actually help

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

Parallel research is the use case I reach for most. Three teammates investigate different angles of a problem, then compare notes. Sequential research suffers from anchoring: once a plausible answer shows up, you stop looking. With multiple investigators, that problem goes away.

It also works well when the work splits naturally across separate files. Frontend on one side, backend on another, tests on their own: each teammate owns its piece, zero conflicts.

Code review follows the same logic. One teammate 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 test a different theory about why a bug happened, actively trying to disprove the others. The theory that survives has good odds of being the right one.

When they get in the way

Agent teams aren't always the right tool. I've burned tokens confirming it.

If step 2 depends on step 1's output, a single agent is faster. The coordination cost doesn't pay off when most teammates are just waiting.

Two teammates editing the same file end up overwriting each other's work. I learned that one the hard way. You have to split the work so each teammate owns different files, or the time spent resolving conflicts outweighs the time saved by parallelizing.

Don't spin up a team to rename a variable. If a single agent takes five minutes, the coordination overhead makes no sense. Same when 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: tasking 16 parallel agents with building a C compiler in Rust, from scratch. Nearly 2,000 sessions, 2 billion input tokens, a cost of about $20,000. Result: 100,000 lines of code.

The compiler builds 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. It runs Doom.

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

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

Practical tips

The task description is the prompt. Stay vague ("handle the database stuff") and the teammate will make assumptions you don't want. Be specific about files, expected behavior, constraints. Five minutes writing a careful description saves an hour of wasted agent work.

New to agent teams? Skip the jump straight to parallel implementation. Run a parallel code review. Have your teammates research different libraries. The boundaries are clean, the risk is low. You get a feel for the coordination without betting a feature on it.

Letting a team run unattended too long gets expensive. Check on teammate progress, redirect approaches that lead nowhere, shut down the ones that drift. I aim for 5 to 6 tasks per teammate: small enough to keep a rhythm of check-ins, large enough that each task produces a clear deliverable.

One annoying detail: 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 the team. Otherwise you'll spend half the session clicking "approve."

Current limitations

Agent teams are still in research preview. A few things worth knowing.

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

Tasks don't always get marked complete correctly, which blocks dependent work. Something looks stuck? Check whether the work is actually done and update the status by hand.

Only the lead manages 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 its task description. No shared memory between runs.

Token usage scales with team size. Each teammate carries 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 changes for how we build

The current version has rough edges. The model, though, holds up: 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 work, same as with humans. Too many dependencies and nobody moves forward. Shared files create conflicts. The teams that work best are the ones with clear ownership, exactly like every engineering team I've been on.

Building agent workflows? Agent teams are worth the test. Start small, pick the right problems, don't expect magic. The teams that work best are the ones where you'd also want several humans on the job.