Multi-agent system, defined without the hype

What a multi-agent system is

Anthropic's Research feature, documented in its 13 June 2025 engineering post "How we built our multi-agent research system", is the cleanest public accounting of one: a lead agent that spawns parallel subagents — typically three to five at a time — with Claude Opus 4 as lead, Claude Sonnet 4 underneath. It beat single-agent Opus 4 by 90.2% on their internal research eval. It also burned about 15× the tokens of a chat interaction, against roughly 4× for a single agent. Anthropic's own analysis of that eval attributes about 80% of the performance variance to token usage alone, with tool-call count and model choice accounting for most of the rest. What the token bill buys, besides accuracy, is wall-clock: running subagents in parallel, each issuing three or more tool calls at once, cut research time on complex queries by up to 90% in the same write-up.

That ratio is the whole design question. You are buying parallel context and specialised instructions, and paying for them in tokens and debugging surface.

Where the term came from: 1980, and not from prompts

The idea predates language models by four decades. Reid Smith's Contract Net Protocol, published in IEEE Transactions on Computers vol. C-29, no. 12, December 1980, pp. 1104–1113 and drawn from his 1978 Stanford dissertation, described distributed nodes that announce tasks, bid on them, and award contracts to each other. The two roles were named manager and contractor, the worked domain was a distributed sensor network, and allocation happened with no central scheduler. Distributed AI grew out of that line of work: agents with their own goals, their own local view, and a published message protocol between them. That protocol layer was later standardised — FIPA, founded in Geneva in 1996, published its Agent Communication Language specifications in 2002, fixing a shared vocabulary of 22 communicative acts, among them inform, request, propose and cfp (call for proposals), and FIPA itself became an IEEE standards committee in 2005.

The LLM version is recent and dated. CAMEL (arXiv:2303.17760) put two role-playing agents in a conversational loop in March 2023. AutoGen's paper landed on arXiv in August 2023 (arXiv:2308.08155), out of Microsoft Research with Penn State and the University of Washington, and the framework was rewritten in January 2025 for v0.4 around an asynchronous actor model. The "Generative Agents" paper by Park et al. (arXiv:2304.03442), April 2023, ran 25 agents in a sandbox town called Smallville on a memory-stream, reflection and planning architecture, and reported coordination nobody scripted — the agents organised a Valentine's Day party. Everything after that — supervisor graphs in LangGraph, first released by LangChain in January 2024, handoffs in the OpenAI Agents SDK released March 2025 as the production successor to the experimental Swarm library from October 2024, agents-as-services in A2A, announced by Google on 9 April 2025 with more than 50 launch partners and donated to the Linux Foundation that June — is tooling on top of an idea that already had a literature.

Two different things share the name

When someone says "multi-agent system," they mean one of two things, and the engineering implications barely overlap.

A2A sits between them: agents published as addressable services, described by Agent Cards — JSON documents served at a well-known URL — that discover and call each other across vendor boundaries over JSON-RPC 2.0, with Server-Sent Events carrying streaming updates. MAS-classic plumbing carrying MAS-LLM workloads. It is worth keeping the two protocol layers apart: MCP, released by Anthropic on 25 November 2024 and adopted by OpenAI in March 2025, standardises how one agent reaches tools across the same JSON-RPC 2.0 transport; A2A standardises how agents reach each other. Neither turns a collection of agents into a system on its own. If you are reading a paper, assume MAS-classic. If you are reading a vendor blog, assume MAS-LLM.

What it is not: a single agent with more tools

The neighbouring term people collapse into this one is agentic workflow — a fixed sequence or DAG of model calls. Anthropic draws the line in "Building effective agents", published 19 December 2024: in a workflow, the paths are defined in code; in an agent, the model directs its own process. That post enumerates five workflow patterns — prompt chaining, routing, parallelisation, orchestrator–workers, evaluator–optimiser — and only the orchestrator–workers shape resembles a multi-agent system from the outside. A workflow with six steps and five prompts is not six agents.

Also not a multi-agent system: routing between models, one model calling another model as a tool, or the same prompt run five times and voted on. Those are useful. They have names.

A worked example, with the topology drawn

Anthropic's Research architecture is the reference implementation to reason from, because the numbers are public. A user asks a broad question. The lead agent decomposes it, then spawns subagents in parallel — each gets its own objective, its own tool set, and its own context window. They search, return summaries to the lead, and the lead decides whether to spawn more. A separate citation agent attaches sources at the end. The whole thing was graded by an LLM judge scoring each run on factual accuracy, citation accuracy, completeness, source quality and tool efficiency, starting from a set of about 20 representative queries rather than a large public benchmark.

Anthropic's post is also explicit about the guardrails that topology needed. The lead agent's prompt carries scaling rules — roughly one subagent and 3–10 tool calls for simple fact-finding, two to four subagents with 10–15 calls each for comparisons — because early versions spawned as many as 50 subagents for trivial queries and handed several of them the same instructions. Context is a hard boundary as well as a budget: when the lead's transcript approaches Claude's 200,000-token window, the implementation writes its plan to external memory and continues in fresh subagent contexts rather than truncating mid-run.

Anthropic's own read: this topology helps on breadth-first questions where subtasks are independent, and struggles when the subtasks are tightly coupled and each one depends on the last. That matches the failure literature. The MAST taxonomy (Cemri et al., 2025, arXiv:2503.13657) catalogues 14 failure modes in three categories — specification and system design, inter-agent misalignment, and task verification and termination — across seven multi-agent frameworks and more than 200 annotated execution traces, with inter-annotator agreement reported at 0.88 Cohen's kappa. A large share are coordination problems — agents that talk past each other, not models that reason badly.

Three questions that settle whether yours qualifies

1. How many loops are there? Count independent decide–act–observe cycles, each with its own context window. One loop with twelve tool definitions is one agent, however many personas the prompt mentions.
2. Who decides the next hop, and when? In the OpenAI Agents SDK, handoffs are given to the model as tools — a generated transfer_to_<agent> call it may choose — so routing is a runtime decision. If every edge is hard-coded, you built a workflow and called it a system.
3. Can one agent die without taking the rest with it? If a subagent times out and the run returns a degraded answer, you have a system. If it takes the process down, you have one process in costumes. That is the real line, and most demos fail it.

Unbounded loops are the most common production failure in any agent topology, and multi-agent makes them cheaper to create and harder to see, because no single transcript shows the whole run. The fix is not a better prompt. It is a step cap and a token budget enforced in the runner, outside the model — the same discipline as a single agent with three tools, applied per agent and again to the swarm.

Practitioner guidance converges on the same trade: a multi-agent topology is not the default for a task a single agent finishes in ten steps. Anthropic's stated conclusion is that the pattern earns its cost only on tasks valuable enough to absorb the token bill, and that it is a poor fit where subtasks share state or depend on one another — most coding work being the example they give. At roughly 15× the tokens of chat, you are paying a premium for parallel context — worth it for breadth, wasted on a pipeline — and the parts that actually hold in production are the caps, the traces, and the handoff contracts, not the org chart drawn for the agents.