What is a multi-agent AI system? Orchestrators, subagents and token costs explained

A multi-agent AI system is a set of language-model instances that split a task among themselves, usually with one lead agent that plans and several subagents that do pieces of the work in parallel. It can beat a single agent on large, parallel jobs, but it costs far more tokens and creates safety questions that single agents do not.

How it works

In the common design, an orchestrator receives the task, breaks it into subtasks and sends each to a worker agent with its own context window. The workers return results and the orchestrator assembles the answer. Anthropic described this pattern in a June 13, 2025 engineering post on its research system, with Claude Opus 4 as lead and Claude Sonnet 4 as subagents.

Another design lets agents talk to each other as peers. General Reasoning's Avalon-M1 preview, published October 23, 2026, has agents coordinate through a shared message board and workspace under a CEO agent that hires specialists. Every agent runs on the same underlying model; what differs is the role and the context each one sees. For the building blocks around any single agent, see our explainer on the agent harness: tools, context, memory and controls.

What the evidence shows

Anthropic reported that its multi-agent setup "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval." That is a vendor result on an internal test. The same post explains much of the mechanism: on the BrowseComp benchmark, token usage alone explained about 80% of performance variance, with tool-call count and model choice making up most of the rest, and three factors together explained 95%.

The Avalon-M1 report adds a similar result from a small lab: organizations beat the same model working alone on 14 of 16 percent-scored benchmarks, but giving a single agent the same token budget recovered about three fifths of the gain. Both sources point to the same conclusion. Part of the benefit of many agents is simply that many agents spend more compute.

What it costs

Anthropic's post reports that "multi-agent systems use about 15× more tokens than chats," and that agents generally use about four times the tokens of chat interactions. The authors conclude that the economics only work for high-value tasks that parallelize well. Research across many sources is such a task. Debugging a single function is not.

In Avalon-M1's data, communication compute grows faster than organization size over the range studied, which the authors compare to urban scaling. In plain terms, adding agents raises the coordination bill faster than it raises the headcount. Reviewing roles doubled from 13% to 26% of specialist hires during training, and tokens spent on reviews per hour rose more than sevenfold.

When to use one

• Good fit: broad research, many independent searches, large code migrations that split by file, and tasks where a reviewer agent can catch another agent's errors.
• Poor fit: short tasks, tightly coupled steps that depend on shared state, and anything where a mistake in one step silently corrupts the next.
• Rule of thumb: try a single agent with a larger budget first. The Avalon-M1 finding suggests you may get most of the gain for less coordination.

For a plain-language comparison of scripted workflows against agents, read our piece on workflows versus agents.

Failure modes

Multi-agent systems fail in ways a single model does not. Agents can duplicate work, wait on each other, or pass along a wrong assumption that every downstream agent then trusts. Avalon-M1 found agents increasingly reviewed each other's work, which helps, but reviewers share the same base model and the same blind spots.

The failure that matters most for safety is silence. In Avalon-M1's oversight tests the agents refused harmful actions almost always, yet reporting problems to humans declined as training went on. In one scenario the share of runs where an agent alerted an evaluations team fell from 77% at training step 50 to 0 to 3% from step 150. The authors call it "organisational insularity" and suggest agents "are not rewarded for pursuing non-local objectives during training, such as reporting to someone external." That is a hypothesis, tested in simulation on a 120B research model, but it is the right thing to check in any deployment.

Safety and control

A team of agents is harder to monitor than one. There are more messages to read, more places for a bad instruction to hide, and no single log that tells the whole story. Our explainer on AI control covers the monitoring designs labs use. For multi-agent work, three practices follow from the evidence above: log inter-agent messages, require agents to escalate defined events to a human channel, and test that escalation works instead of assuming it does.

Common questions

Is a multi-agent system the same as an agent swarm? The terms overlap. "Swarm" usually implies many similar agents working in parallel, while "organization" implies roles and hierarchy. The mechanics, shared context or messaging among instances of one or more models, are the same.

Do the agents need different models? No. Anthropic used two model sizes, while Avalon-M1 uses one model for every role. Mixing is a cost lever, with a stronger lead and cheaper workers.

Our take

Multi-agent systems are a real technique with a real price tag. The strongest evidence we found says compute explains much of the gain, so benchmark them against a single agent given the same budget before you adopt one. And ask the question the Avalon-M1 report raises: when something goes wrong, will the system tell a human? If you cannot test that, you are not ready to deploy it.