From Copilots to Teams

Somewhere in the last year, a team lead reading Claude Code’s documentation hit a one-line example — “Spawn three teammates to review PR #142: one on security, one on performance, one on test coverage” — and thought: why not do that on the actual refactor sitting in the backlog, not just a review. So they tried it. Three teammates spun up, each with its own context window, each burning tokens independently. Twenty minutes later there were three partial branches, a merge conflict none of the teammates had been told to expect, and a bill that looked like four single-agent sessions rather than one three-times-faster one.

Nothing about that outcome was a bug. It was the predictable result of applying a pattern good for one kind of work to a different kind of work, because the industry’s marketing does not distinguish between the two kinds. This chapter draws the line as carefully as the evidence allows: where the multi-agent trajectory has actually delivered, where it has not, and what vocabulary is worth having before Volume VI goes further.

The lineage nobody markets

The starting point of this trajectory is duller than the endpoint everyone talks about. GitHub Copilot launched as a technical preview on June 29, 2021, described by GitHub itself as “a new AI pair programmer that helps you write better code” — a tool that “draws context from the code you’re working on” to “suggest whole lines or entire functions” as a developer typed. That is the entire ambition: one model, one developer, autocomplete. No planning, no tool use, no delegation. It is worth stating plainly because it is easy to forget, four years and several paradigm shifts later, that the industry’s single most widely adopted AI coding tool started as nothing more than a very good autocomplete.

The next stage widened the unit of work without widening who was in the room. A subagent, in Claude Code’s own framing, is a specialized assistant that runs a side task — research, a log search, a large file read — “in its own context window” and “returns only the summary” to the agent that spawned it. The main session stays in charge; the subagent never talks to anyone but its caller. This is delegation, not collaboration — a single developer’s single conversation getting help clearing clutter out of its own context, which Volume I named Context Debt when it goes unmanaged.

The stage after that is the one the industry is currently excited about, and it is the one this volume exists to examine skeptically: multiple independent sessions that coordinate with each other directly, rather than reporting to a single caller. Claude Code calls this pattern agent teams — one lead session, several teammates, a shared task list, direct messaging between teammates — and its own documentation is explicit that the feature “is experimental and disabled by default.” That single phrase, buried in a warning box rather than a headline, is a more honest data point about where this trajectory actually stands in mid-2026 than most of what gets written about it.

The number everyone quotes

The evidentiary anchor for the entire multi-agent argument is a single Anthropic engineering post from June 13, 2025, describing the system behind Claude’s research product: a lead agent (Claude Opus 4) that plans and decomposes a query, spinning up several subagents (Claude Sonnet 4) to search in parallel, each returning findings the lead synthesizes into an answer. Anthropic reports that this architecture “outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.” That figure has become the industry’s go-to justification for multi-agent everything, coding included.

The eval it was measured on matters as much as the number. Anthropic describes the tasks as “breadth-first queries that involve pursuing multiple independent directions simultaneously” — open-ended research where the right answer requires gathering from many disconnected sources and no single subtask depends on another’s output finishing first. That is a specific shape of problem. It is not the shape of most software engineering work, and Anthropic says so in the same post.

Most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.

Anthropic, “How we built our multi-agent research system,” 2025-06-13

The caveat inside the headline

That sentence is doing more work than the 90.2% figure, and it comes from the one organization with the clearest commercial incentive to oversell multi-agent architectures. Two separate claims sit inside it. First, a structural one: coding tasks decompose into fewer genuinely independent pieces than research does, because most nontrivial changes touch shared state — a schema, a shared module, a test suite — that creates real dependencies between the pieces, unlike ten unrelated web searches. Second, a capability one: even when a coding task does decompose cleanly, the agents doing the work are not yet reliably good at negotiating who owns what and when, in real time, without a human arbitrating.

Anthropic’s own product documentation for agent teams says the identical thing in product-manual language rather than research language: teams “add coordination overhead and use significantly more tokens than a single session,” work “best when teammates can operate independently,” and for “sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective.” The company that built both the research system and the coding product is telling its own users, in its own documentation, to default to the smaller unit — and it ships the feature off by default.

Vocabulary for the trajectory

Three stages, then, each widening the circle of who — or what — is doing the work, and each with a different evidentiary basis. None of these names are this Library’s coinage; they are the terms the tools themselves use, laid out in one place because nobody has done that plainly before. The task list a team of agents claims work from, notably, is a scaled-up cousin of what Volume V calls a Flight Plan at the single-session level: a decomposed set of steps with dependencies, gating what can start until something else finishes.

The cost column is not in the table because it is not evidence about quality — it is a constraint that applies regardless of which stage wins on a given task. Anthropic reports that agents in general use roughly four times the tokens of a single chat interaction, and multi-agent systems roughly fifteen times; token usage alone explained about 80% of the variance in how well its research system performed. Claude Code’s own background-agent documentation states the plainer version of the same fact for a fleet of unattended sessions: running ten agents in parallel “uses quota roughly ten times as fast as running one.” Multi-agent work is not free parallelism. It is parallelism purchased at a price that scales with the number of agents, whether or not the task benefits from being split.

Infrastructure catching up to ambition

Two pieces of infrastructure exist to make the later stages of this trajectory practical, and both are worth naming here without developing them — Chapter 7 of this volume takes each apart in depth. Anthropic open-sourced the Model Context Protocol in November 2024 as “an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools,” solving how one agent gets access to context and tools. Google announced the Agent2Agent protocol in April 2025 to let “AI agents built by different vendors or frameworks” communicate and coordinate directly, solving a different problem — agents talking to other agents rather than to tools. Both are still young enough that most teams building agent-to-agent systems today are wiring their own coordination layer rather than adopting either standard wholesale.

Field data

Where the trajectory actually stands

The honest summary, as of mid-2026: the trajectory from copilot to team is real and the vocabulary above describes something genuinely happening in production tooling, not a speculative roadmap. But the evidence for the multi-agent end of that trajectory is concentrated almost entirely in research and review work — open-ended, breadth-first, low-dependency — and the vendor with the strongest results and the strongest incentive to generalize them says, in its own words and its own default settings, that most coding work does not fit that shape yet. The next chapter in this volume makes the contrarian case directly: when not to reach for multiple agents, and how to tell in advance whether a task is actually shaped like the research eval Anthropic measured, or shaped like the refactor that produced three unreconciled branches.