Multi-Agent AI: What It Costs and When It's Worth It

Key takeaways

• Multi-agent AI means several agents with distinct roles coordinating on work a single agent handles poorly. The term describes a topology. Agentic describes a capability.
• Anthropic's engineering team reported that "multi-agent systems use about 15× more tokens than chats," with single agents at roughly 4×.
• That multiplier is worth paying when the task is open-ended parallel search and the output is valuable. Anthropic's own condition: "the value of the task is high enough to pay for the increased performance."
• Coordination is model work. Agents deciding what to delegate, summarizing for each other, and reconciling results all spend tokens before any answer arrives.
• For repeatable work, the cheaper pattern is one agent that reasons through the problem once and emits a deterministic app that runs without a model afterward.

The actual definition

Multi-agent AI is a system in which two or more agents, each holding a defined role and its own context, coordinate to complete a task that one agent handles badly alone. The coordination is the definition. A pipeline where an agent calls a tool that happens to be another model falls outside it. A system where a lead agent decomposes a goal, hands pieces to subagents that pursue them independently, and reconciles what comes back sits squarely inside it.

Two properties do the work. Each agent holds a bounded role, which keeps its instructions and context narrow. And the agents exchange information through some protocol: a lead reading subagent reports, a router choosing a specialist, a handoff passing state between stages. For the layer beneath this, see what an AI agent is.

The field is older than the current wave suggests. Multi-agent systems have been active research under distributed artificial intelligence since at least the early 1990s, covering negotiation protocols, distributed constraint optimization, and swarm robotics (Wikipedia). The LLM version inherited the vocabulary and most of the hard problems. Coordination overhead, deadlock, and inconsistent local views were named decades before anyone put a language model behind an agent. What changed is that spawning an agent now costs a few lines of code.

Agentic AI vs multi-agent AI

Agentic AI names a capability. Multi-agent names a topology. An agentic system plans, calls tools, observes results, and adjusts across multiple steps toward a goal, and it can do all of that with exactly one agent. Multi-agent describes how many agents are involved and how they talk to each other.

Most content treats multi-agent as an advanced tier of agentic AI, which gets the relationship wrong in a way that costs money. A single agent running a twelve-step research task with tool use is fully agentic. Adding four subagents makes it wider, and changes its cost and failure profile. You can also build a multi-agent arrangement out of components that barely reason at all, which is what most routing setups are in practice. Agentic asks what the system can do. Multi-agent asks how you arranged it.

Why this matters now

Two years ago, building a fan-out of coordinating agents was a research project. Frameworks made it a configuration choice. The subagent pattern, the router, the handoff, and packaged skills are now defaults in the tooling rather than designs someone had to argue for (GitHub).

When an architecture becomes trivial to build, it stops getting evaluated. Teams reach for a supervisor and four workers because the template exists, not because the task shape demands it. The bill and the debugging burden arrive a quarter later, by which point the topology is load-bearing. See how the framework layers map.

The five sub-concepts that matter

Orchestration and the lead-agent pattern

The dominant shape is a lead agent that receives the goal, decomposes it, spawns subagents with narrow instructions, and synthesizes their returns. The lead holds the plan. The subagents hold the search. Anthropic's research system runs this way, and its guidance is that the lead must give subagents clear objectives, output formats, and boundaries, because vague delegation produces duplicated and conflicting work.

The failure point is delegation quality. A lead agent writing subagent prompts is a model writing instructions for other models, with no feedback until results return. For the broader picture, see coordinating models and agents.

Parallelism and what it really buys

Parallelism buys wall-clock time. Five subagents searching five sources simultaneously finish sooner than one agent searching five sources in sequence. That is a real gain for breadth-first tasks where the sources are independent.

Correctness is a separate question, and parallelism leaves it untouched. Five agents each with a partial view can each be confidently wrong, and the lead agent reconciling them has no privileged access to the truth. Anthropic notes that the whole system can stall anyway: "the entire system can be blocked while waiting for a single subagent to finish searching." Parallel until the slowest branch, which is the same arithmetic that governs any fan-out.

Coordination overhead

Every message between agents is generated and consumed by a model. The lead's decomposition is inference. Each subagent's report is inference. The synthesis pass is inference. None of it is the answer, and all of it is billed.

This is why the multiplier is steep rather than linear in agent count. Four subagents cost four subagent runs plus the lead's planning, plus the lead reading four reports, plus a synthesis that has to hold all of it in context.

State and error compounding

Anthropic states it directly: "Agents are stateful and errors compound." And: "One step failing can cause agents to explore entirely different trajectories, leading to unpredictable outcomes." A retry is not cheap either, since "restarts are expensive and frustrating for users."

Multi-agent multiplies the surface where this happens. Each subagent carries its own accumulated state, and a bad early tool result inside one branch propagates into that branch's every subsequent decision before the lead ever sees it. Debugging means reconstructing several concurrent trajectories rather than one, which is why observability for agent systems gets harder faster than the agent count grows.

Token economics

The figures, all from Anthropic's June 2025 engineering post: agents use "about 4× more tokens than chat interactions," multi-agent systems use "about 15× more tokens than chats," and in their evaluation "token usage by itself explains 80% of the variance" in performance, with tool-call count and model choice as the other two explanatory factors.

Scope that honestly. It is one vendor's internal data on one research workload, published in June 2025, with no reproducible methodology attached. "In our data" and "about 15×" are not independently verifiable, and model efficiency has moved since. Treat these as the best public order-of-magnitude figures available rather than a benchmark. They come from a company that sells the tokens and ships the architecture, which makes the direction of the number credible even where the precision is not.

The 80% finding cuts both ways. If token spend is the dominant predictor of quality on hard research tasks, multi-agent earns its cost on exactly those tasks. On tasks where quality is already adequate, the extra spend buys nothing.

What it costs, and how to size it

Anthropic published a sizing heuristic. This table applies it, and the agent and tool-call columns are their guidance quoted directly.

| Task shape | Agents | Tool calls per agent | Multi-agent worth it? | |---|---|---|---| | Simple fact-finding | "just 1 agent" | "3-10 tool calls" | No. One agent, no coordination cost. | | Direct comparison across a few known sources | "2-4 subagents" | "10-15 calls each" | Sometimes. Justified if latency matters and sources are independent. | | Complex open-ended research | "more than 10 subagents with clearly divided responsibilities" | High and variable | Yes. Breadth is the point and the value justifies the spend. | | Repeatable workflow run on a schedule | 1, once | However many it takes to work it out | No. Reason once, then run the resulting code. | | High-volume routing or classification | 1 plus deterministic routing | Low | No. The routing decision belongs in code. |

The comparison that decides most architectures:

| Dimension | Single agent | Multi-agent | |---|---|---| | Token cost | ~4× a chat interaction (Anthropic) | ~15× a chat interaction (Anthropic) | | Latency | Serial, slower on breadth-first work | Parallel, bounded by the slowest subagent | | Failure surface | One trajectory | One per agent, plus the coordination layer | | Cost curve with usage | Climbs with every run | Climbs faster with every run | | Debuggability | Single trace to read | Concurrent traces to reconcile | | Best-fit task shape | Bounded tasks with a known path | Open-ended search where breadth is the value |

When multi-agent genuinely wins

This is not an argument against the architecture. Some work is genuinely parallel and genuinely open-ended, and a single agent does it worse no matter how good the model is.

The clearest case is breadth-first search over a space you cannot enumerate in advance. When the task is "find everything relevant about X" and relevance is only discoverable by looking, subagents exploring independent branches with separate context windows outperform one agent trying to hold every thread at once. Anthropic's finding that token spend predicts most of the performance variance is direct evidence for this. Context compression is the constraint, and more agents means more total context to work in.

Two other cases hold up. Subtasks that require genuinely different tool inventories or credentials, where role separation is a security boundary rather than a stylistic choice. And work where wall-clock latency is the binding constraint and the extra spend is cheap relative to the delay.

Common misconceptions

More agents means better results. Anthropic's early agents were "spawning 50 subagents for simple queries" and "scouring the web endlessly for nonexistent sources." Agent count is a cost input. Quality comes from the task shape.

Multi-agent means more reliable. Each added agent adds a place for the run to break. Anthropic describes systems where "the lead agent can't steer subagents, subagents can't coordinate" and agents "distract each other with excessive updates."

Coordination is free. Delegation, reporting, and synthesis are all inference. The overhead is a meaningful share of the 15× and it grows with the number of agents.

Multi-agent is the same thing as agentic. Capability and topology, as above. One agent can be fully agentic.

This is a new field. Distributed AI has studied coordination, negotiation, and consensus among autonomous agents for over thirty years. The unsolved problems are mostly the old ones with a token bill attached.

What we're building at Major in response

The industry is optimizing the wrong variable. Agent count gets the attention; the number that decides whether an agentic workflow survives contact with a budget is how much work you have permanently removed from the model. A multi-agent system that re-reasons the same workflow on every run has a cost curve that climbs with usage forever, and no amount of orchestration flattens it, because the orchestration is itself the thing being billed.

The alternative is unglamorous. One agent reasons through the problem once, and what it produces is an app. Deterministic code, with its own database, its own logs, and its own scoped credentials. From then on, the repeatable stretch of the work runs without a model in the loop, the same way every time, and an auditor can read what it did in March.

That is what Major is built to do. When an agent works out how to handle a repeatable part of a task, it builds and deploys an app for that part and runs the app instead of reasoning through the work again. State lives in a managed database rather than a context window that ends. Actions carry permissions and audit because they live in code. Agents still reason, for the judgment calls and for building the app in the first place. They stop re-deriving the same conclusion on every run, which is the repeatable-work pattern most agent workloads turn out to be underneath.

This does not solve the open-ended research problem. If your task is genuinely breadth-first search over an unknown space, you need the fan-out and you should pay for it. What it does solve is the much larger category of work that only looked open-ended the first time and has been re-reasoned every run since. The smartest agentic workflow uses the least AI to run. If you are adding agents faster than you are removing model work, you are scaling the bill rather than the capability. See agentic workflow patterns and their limits for where that line usually sits.

If you have a workflow your agents keep re-deriving, the useful experiment is to have an agent build the app for it once and measure what the next hundred runs cost. That is how Major turns repeatable agent work into deterministic apps.

Related articles

• LLM Gateway: What It Governs, and What It Cannot
• AI Agent API: What Persists After the Request Ends
• LLM Orchestration: The Layer That Should Use Fewer Model Calls