Multi-Agent Systems Explained: How They Actually Work

What multi agent systems are

A multi-agent system splits one job across several large language model agents that each hold their own context window, then coordinates their output into a single result. Instead of one model doing everything in sequence, a lead agent, a router, or a fixed pipeline hands pieces of the task to specialist agents and combines what comes back.

Multi-agent systems are groups of LLM-driven agents that work on parts of the same task, each with a separate context window, coordinated by a lead agent, a router or a fixed sequence. They exist because a single agent runs out of context, speed or focus on large, parallel or highly specialized jobs, and they cost more tokens in exchange for that capacity.

How multi-agent systems work

Google Cloud's explainer breaks a multi-agent system into three parts: the agents themselves, the shared environment they act in, and the communication mechanism that lets them coordinate, from simple message passing to formal agent communication languages like FIPA ACL, to coordination methods such as auctions, voting or contract nets. Modern systems mostly skip the formal languages and use an orchestrator: a lead agent or a fixed graph decides which agent runs when, and passes results between them through a shared state object.

Anthropic named the same three patterns in practice when it built the multi-agent architecture behind Claude's Research feature: a lead agent plans the work and spawns subagents, each of which runs its own web searches with its own context window and returns findings, and a separate citation agent processes the final report afterward. In Anthropic's internal evaluation, a lead Opus 4 agent coordinating Sonnet 4 subagents beat a single Opus 4 agent by 90.2 percent on a breadth-first research benchmark. The team also found that token usage alone explained 80 percent of the variance in the BrowseComp benchmark score, with tool call count and model choice explaining the rest, which is why multi-agent systems that throw more parallel agents at a problem tend to do better on tasks that reward exhaustive search.

That capacity is expensive. Anthropic's own numbers: agents typically burn about four times the tokens of a normal chat turn, and a multi-agent system burns about fifteen times a chat turn's tokens. A multi-agent system only pays for itself on tasks valuable enough to justify that multiplier.

Two engineering posts from June 2025, one from Anthropic and one from Cognition, reached what looks like an opposite conclusion but actually agrees on the hard part: context engineering. Cognition's Walden Yan argues that splitting a task across agents is fragile because each agent's actions carry implicit decisions the other agents cannot see, and when two agents make conflicting decisions the result breaks. Cognition's example: ask two subagents to build a Flappy Bird clone, one for the background and one for the bird, and each will make independent visual choices that clash when combined. Cognition's rule for avoiding that: share full agent traces between agents, not just individual messages, and default to a single-threaded agent unless the task truly needs to be split.

Anthropic's Research system avoids that trap by keeping the split to "read" work: subagents search and gather, but a single agent does all the writing, because Anthropic found that reading in parallel is far less likely to produce conflicting outputs than writing in parallel. As LangChain's Harrison Chase put it after reading both posts, multi-agent systems that primarily read are far easier to make reliable than ones that primarily write.

Examples

Google's Agent Development Kit documents eight concrete coordination patterns for building this kind of system, four of which map directly onto real jobs:

• Sequential pipeline: a parser agent, an extractor agent and a summarizer agent each hand off to the next through a shared session state key, used for document processing pipelines.
• Coordinator and dispatcher: a router agent reads the user's intent and hands the conversation to a billing specialist or a technical support specialist, used for customer service bots.
• Parallel fan-out and gather: a security auditor, a style checker and a performance analyst review the same pull request at the same time, then a synthesizer agent merges their three reports into one review comment.
• Hierarchical decomposition: a report-writing agent treats a whole research assistant agent, which itself manages a web search agent and a summarizer agent, as a single tool call.

Anthropic's own research gives a harder example of what happens when agents genuinely have to coordinate rather than just hand off work. In one experiment, the company gave 45 agents their own virtual machines, a shared forum to post findings on, and an arbiter agent to judge submissions, then set them loose finding vulnerabilities across 15 open source projects. The coordinating swarm running on Claude Mythos Preview found 266 vulnerabilities over a 27 million token run, against 21 vulnerabilities from the same number of agents searching independently over 6.5 million tokens. Only 12 of those vulnerabilities were found by both methods, meaning the coordinating swarm's ability to redirect its own attention found bugs the independently assigned agents were never pointed at.

A second Anthropic experiment tested whether agent swarms could build something together rather than just search in parallel: groups of 10 to 80 agents, each on its own virtual machine with a shared repository and forum, were given 12 hours to build a text-based fantasy game. Merge rates fell steeply as the swarm grew from 10 to 80 agents for Claude Sonnet 4.6 and Opus 4.6, which opened 876 and 980 pull requests respectively but closed few of them because their changes kept conflicting. Opus 4.8 and Mythos Preview "solved" the conflict problem by barely sharing code at all, each agent sticking to files it already owned. Only Claude Sonnet 5 kept a high merge rate while agents were still directly sharing and editing the same files.

When to use it (and when not)

Multi-agent systems are worth the token cost when a task is genuinely parallelizable into independent pieces, when it needs more knowledge or more tool calls than fit in one context window, or when different parts of the job call for genuinely different tools or specializations, such as a security review that needs a static analyzer, a style linter and a performance profiler running at once.

They are the wrong choice for tasks that are mostly sequential, mostly about writing rather than reading, or small enough for a single agent's context window. Claude Code is Cognition's own example of getting this right: its subagents never run in parallel with the main agent and are only ever asked to answer a question, never to write code, specifically because a subagent lacks the context to make a coding decision the main agent would agree with. Cognition's broader advice: default to a single-threaded linear agent, and only split into multiple agents once you have confirmed the task's actions do not carry conflicting implicit decisions.

What's new (as of 10 September 2026)

Anthropic's Frontier Red Team published its multiagent coordination research, including the 45-agent vulnerability swarm and the 80-agent code-sharing experiment described above, on 13 August 2026. Google's Agent Development Kit reached general availability across more languages through the year: ADK for Go reached general availability on 30 June 2026, and ADK for TypeScript reached general availability on 21 August 2026 with graph workflow support added at the same release. Microsoft's Agent Framework, the successor to both Semantic Kernel and AutoGen built by the same teams, now ships a Go SDK in public preview alongside its stable Python and .NET packages, adding graph-based workflows for explicit multi-agent execution control on top of AutoGen's simpler agent abstractions. The OpenAI Agents SDK remains one of the frameworks builders compare against ADK and Microsoft's Agent Framework when picking how to wire agents together.

Key takeaways

• A multi-agent system splits one task across several LLM agents, each with a separate context window, coordinated by a lead agent, a router or a fixed pipeline.
• Anthropic found a lead-and-subagent system beat a single agent by 90.2 percent on a breadth-first research benchmark, but multi-agent systems burn about fifteen times the tokens of a single chat turn.
• Systems built for reading in parallel, such as research and search, are far more reliable than systems that try to write in parallel, because parallel writes carry conflicting decisions that have to be reconciled.
• In Anthropic's 80-agent coordination test, only Claude Sonnet 5 kept a high pull request merge rate while agents directly shared and edited the same files; older models either failed to merge conflicting work or avoided sharing files at all.
• Google's ADK documents eight named coordination patterns, from sequential pipelines to parallel fan-out and gather, that map directly onto common jobs like document processing and pull request review.

FAQ

What is the difference between a single agent and a multi-agent system?

A single agent works alone in its own context window on the whole task. A multi-agent system distributes pieces of the task across several agents that each keep their own context window, then combines their outputs, which adds coordination overhead and token cost in exchange for more parallel capacity.

When should I build a multi-agent system instead of one agent?

Build one when the task is naturally parallelizable, needs more context or tool calls than one agent's window allows, or needs genuinely different specializations working at the same time, such as separate security, style and performance reviews of the same code. Cognition's advice is to default to a single agent and only split once you have confirmed the subtasks will not produce conflicting decisions when combined.

Why do multi-agent systems use so many more tokens?

Anthropic measured that agents typically use about four times the tokens of a normal chat interaction, and multi-agent systems use about fifteen times as many tokens as a chat interaction, because each subagent keeps its own context and often repeats some of the same research the others are doing.

What frameworks are used to build multi-agent systems?

Google's Agent Development Kit, Microsoft's Agent Framework and the OpenAI Agents SDK are the frameworks builders compare when wiring up multi-agent coordination; ADK documents eight named patterns for it directly, while Microsoft's framework adds graph-based workflows for explicit control over which agent runs when.

Source: How we built our multi-agent research system, Anthropic

Compare the agents, MCP servers and skills that implement these patterns on the AI Agents Listing directory.