Multi-Agent Systems: When Teams of AI Agents Beat One (and When They Waste Money)

Should you build a multi-agent system? The honest answer is: sometimes yes, mostly no. A multi-agent system is a team of AI agents working together instead of one agent working alone. Most jobs need one good assistant, not a committee. A committee only wins when the job is truly too big for one assistant. The rest of this post is the rule for telling the difference, with real numbers from a company that actually runs these systems in production.

In short

• A team of AI agents can beat one agent - but only for a small set of jobs.
• Teams cost more money (Anthropic reports their multi-agent research system used about 15x the tokens of a single chat), fail in more places, and are harder to fix.
• The rule: start with ONE agent. Add more only when you have MEASURED proof that one agent can't do the job.
• Patterns that earn their keep: a supervisor with specialists, relay-race handoffs, and assembly-line pipelines.
• If you can't trace every handoff between agents, you're not ready for a team.

The honest verdict, first

Imagine you have one great assistant who knows your whole life. She knows your calendar, your projects, and what you meant by that half-finished message on Tuesday. Ask her anything and she just handles it. Now imagine firing her and hiring a committee for every small decision instead. Where should we eat? Committee. What does this email say? Committee. Most days the one assistant wins, because she already holds all the context and doesn't need meetings to share it. The committee wins only when the job is truly too big for one person - like planning a huge wedding for 500 guests in a single afternoon.

Short answer: in the single agent vs multi agent choice, one well-equipped agent wins for most real work. Go multi-agent only when one agent measurably fails the job.

That's the honest verdict on multi-agent systems too. A multi-agent system is a team of AI agents working together on one job. And for most real work, one well-equipped agent is the right call. LangChain's own docs say it plainly: "a single agent with the right tools and prompt can often achieve similar results." Why pay for a team when one player scores the same points?

Anthropic - the company behind Claude, and one of the few that has actually run a big multi-agent system in production and told the whole story - agrees. Their engineering post on how they built their multi-agent research system is the best public evidence we have on this topic. And their advice, across their engineering posts, is simple: find the simplest solution possible, and add complexity only when it demonstrably improves outcomes. Not "when the demo looks cool." When it measurably wins.

So this post answers three questions:

1. What does a team of AI agents really cost? (More than you think.)
2. When does a team genuinely beat one agent?
3. What's the discipline for deciding, instead of guessing?

Let's start with the fantasy that pulls everyone in.

The orchestra fantasy (and the demo reality)

A demo of a multi-agent system looks like a perfect orchestra. The conductor waves once, every instrument comes in exactly on time, and the music just happens. It's beautiful. Real life sounds different. The violinist wanders off into a solo nobody asked for. Two drummers play the exact same beat because no one said who owns the drums. And the conductor gets excited and calls 50 players onto the stage for a one-note song. That's what a multi-agent system in the wild actually looks like - and Anthropic wrote down every embarrassing thing their own system did, which is exactly why we can talk about this honestly.

Do multi-agent AI systems work in production? Yes - but for unglamorous reasons: parallel search, compressed context, and clear separation of concerns. Not magic teamwork.

First, the definition in kid words. A multi-agent system is several AI agents - each one a language model using tools in a loop - working together. Anthropic's research system works like this: a lead agent makes a plan, then spawns subagents that search the web at the same time, each chasing one piece of the plan.

And here's the honest part: when it works, it works for unglamorous reasons. Anthropic names three. Compression: subagents explore in parallel, then hand the lead agent only the most important pieces. Separation of concerns: each agent gets its own tools, its own instructions, its own path. Parallel exploration: lots of agents can look in lots of places at once. But the sentence that cuts through all the hype is this one: "multi-agent systems work mainly because they help spend enough tokens to solve the problem." Tokens are the little chunks of text that AI usage gets counted in. In Anthropic's BrowseComp analysis, token usage alone explained about 80% of the difference between good runs and bad runs. Translation: the team mostly wins because a team can afford to look harder - not because ten brains are magically smarter than one.

Now the demo reality, straight from Anthropic's own build log. Their early agents "made errors like spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates." And their warning about shipping: "the gap between prototype and production is often wider than anticipated." The orchestra you saw in the demo is not the orchestra that answers real questions at 2am.

To be fair, teams do win sometimes. On Anthropic's own internal research eval, their multi-agent system outperformed their single agent by 90.2%. Their system, their eval, research-style tasks. It is not a universal law, and Anthropic never claims it is. The rest of this post is about when that win is real - and when it's a fantasy you're paying for.

What a team of agents really costs

Think of a relay race. One runner hands the baton to the next. Every extra runner you add is another chance to drop the baton. And here's the catch nobody mentions at the starting line: the team is only as fast as its slowest runner. One runner stops to tie a shoe, and the whole team waits. A team of AI agents works the same way - every agent and every baton pass is a new place where things can go slow or wrong, and the team can't move faster than its slowest link.

What does a team really cost? Anthropic's own data says their multi-agent system used about 15x the tokens of a single chat. It also fails in more places and is harder to debug.

Teams bill you in three ways:

• Money. More agents means more calls, and more calls means more tokens. Anthropic's own reported numbers, from their internal data: a single agent typically used about 4x the tokens of a plain chat, and their multi-agent research system used about 15x the tokens of a chat. Those are their numbers for their system, not a law of nature - but the shape is the point: teams multiply the bill. Anthropic's conclusion is worth quoting: multi-agent systems need "tasks where the value of the task is high enough to pay for the increased performance."
• Reliability. Here's some plain engineering reasoning (our label, not a benchmark): if a run has n steps and each step succeeds with probability p, the whole run succeeds at roughly p multiplied by itself n times. Say each step succeeds 95% of the time - sounds great, right? Chain 10 steps together and the whole thing succeeds about 6 times out of 10. Four steps out of ten just fail. More agents and more handoffs means more places to drop the baton. Anthropic saw this in production: "errors compound," "minor changes cascade into large behavioral changes," and "minor system failures can be catastrophic for agents." They also found that when the system runs in lockstep, one slow subagent can freeze the whole team while everyone waits.
• Debugging. You can't fix what you can't see. Anthropic again: "Users would report agents 'not finding obvious information,' but we couldn't see why." Until they built full production tracing, they were flying blind. And if you use a framework to manage your agents, the problem gets worse, because frameworks "create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug." The more machinery stands between you and the actual words the models exchanged, the harder every bug hunt becomes.

Anthropic's other engineering post, Building effective agents, makes the same point from the other direction: autonomy trades higher costs for "the potential for compounding errors." So before you add a second agent, ask: is this job valuable enough to pay three bills at once - the token bill, the reliability bill, and the debugging bill?

The patterns that earn their keep

Picture a company with a phone tree. You call and the receptionist answers. She doesn't try to fix your problem herself - she sends you to the right person for the job. The specialist takes over your call and handles the whole thing. Or picture a factory assembly line instead: the phone only rings once, and every station along the line does exactly one thing, in a fixed order, and the finished thing comes out at the end. Those are the three big multi-agent patterns. Let's walk through each one, pattern level, from the official docs (all as of September 2026 - APIs move around, and these could too).

The three multi-agent patterns that earn their keep: a supervisor with specialists, relay-race handoffs, and assembly-line pipelines. In the supervisor setup, one orchestrator agent owns the whole job.

• Supervisor + specialists (the receptionist pattern). One manager agent keeps control of the whole job. It calls specialist agents as if they were tools, takes their answers, and stitches them into the final result. In the OpenAI Agents SDK, that's literally the name of the pattern: agents-as-tools, via Agent.as_tool(). The OpenAI docs say this pattern is best when one agent should own the final answer, combine outputs, or enforce guardrails (safety checks) in one place. LangChain's multi-agent docs call the same idea subagents: a central main agent, usually called a supervisor, coordinates everything by calling subagents as tools. CrewAI's docs call the same idea the hierarchical process, where a manager (you set it up with a manager_llm or a manager agent) plans, delegates, and reviews the work. One rule inside LangChain's docs worth pinning: a supervisor is NOT a router. A supervisor is a full agent that remembers the whole conversation across turns. A router is a one-shot sorter - it labels your request and hands it off, then forgets you existed.
• Relay-race handoffs (the transfer pattern). The triage agent passes the baton, and a specialist "becomes the active agent for the rest of the turn," as the OpenAI docs put it. The baton is the conversation history: whatever the next agent needs to know about what you said so far. Handoffs look like tools to the model - a handoff to a "Refund Agent" shows up as a transfer_to_refund_agent tool - and the receiving agent sees the full conversation history unless you set a filter to trim it. The Agents SDK also gives you on_handoff callbacks and an input_type schema, so every baton pass can be logged and checked later. (LangChain's docs note the handoff term itself was coined by OpenAI, and LangChain implements the same idea with a state variable that remembers which agent is active.)
• Assembly-line pipelines (the predictable one). Each station does one thing, in order, and one task's output becomes the next task's context. CrewAI's sequential process works exactly like that: tasks run in list order, each one feeding the next. The key insight behind this pattern isn't from any one framework - the OpenAI Agents SDK docs say it best: when the flow is knowable, orchestrating through code "makes tasks more deterministic and predictable, in terms of speed, cost and performance." In kid words: if you already know the recipe, write the recipe down as code. Don't pay a model to guess the steps each time.

Two more things before we move on. First, the patterns stack: the OpenAI docs note that a specialist in a supervisor setup can itself call other agents as tools, so a subagent can have subagents. Second, LangChain's multi-agent docs (the live ones - the old LangGraph multi-agent pages were restructured as of September 2026) organize the landscape into five named patterns: subagents, handoffs, skills, router, and custom workflow. The menu is bigger than any one vendor's story, but the three patterns above are the ones this post builds on.

If you've never wired up even a single automation, start there first - one agent that does one useful thing end to end beats a diagram full of boxes. Our guide on building your first AI automation walks through that foundation before you graduate to orchestration.

When multi-agent genuinely wins

You hire a team when one person truly can't hold all the pieces - like researching every team in a whole sports league at once, where one person would still be reading the first division's roster when the league disbands. You don't hire a team because one person is "a bit busy." That's the difference between a real reason to go multi-agent and a shiny one.

When to use multiple agents: when the job is too big for one brain, the subtasks run in parallel, and one agent has already failed a measured test. All three, or stay single.

So here's the honest decision checklist. Graduate to a team ONLY when the failure is measured, not felt:

1. One agent failed a real test. A single agent with good tools actually failed a small eval set - about 20 real queries, which is exactly the sample size Anthropic started with. Not vibes. Not a hunch. A failed test.
2. The job's value covers the bill. Remember the 15x token figure from Anthropic's data. The job has to be valuable enough to pay it.
3. The job is too big for one brain. You've watched the information actually overflow a single context window. Context window means the agent's working memory - the text it can hold at once.
4. The parts can run at the same time. The subtasks are truly independent - like research-style breadth, where each agent digs in its own corner. Most coding is the opposite: the pieces lean on each other constantly.
5. The agent is drowning in tools. You measured one agent with too many tools demonstrably picking the wrong ones. That's tool overload, and LangChain's docs flag it as a real reason to split things up.
6. Nobody needs to share one evolving notebook. The agents don't all need the exact same, constantly-changing context. If they do, they'll spend more time syncing than working.
7. You built the debug setup first. Tracing, per-agent visibility, checkpoints, and evals - in place BEFORE the second agent exists, not after the first 3am failure.

If any of conditions 2 through 6 fails, or you've never run the test in condition 1: stay single-agent. Anthropic's own three fit conditions agree with the checklist: multi-agent fits tasks that are valuable and heavily parallel, information that overflows a single context window, and stacks of complex tools. Their bread-and-butter example is a breadth-first query - like listing the board members of every IT company in the S&P 500, where their single agent failed with slow, sequential searches while the team split the list and won.

One more honest note: the OpenAI Agents SDK ships with built-in tracing and eval tooling, which helps a lot with condition 7 - pick tools that let you see inside the machine before you build the machine.

When it wastes money

You know that phone tree that transfers you five times just so you can ask one question? Every transfer costs time. The answer doesn't get any better. And someone still has to pay the phone bill at the end of the month. Multi-agent systems waste money in exactly the same way - through transfers that add cost without adding answers. AI agent teams lose money when work is duplicated, when every agent needs the same changing context, or when the task's value can't cover the extra tokens. Here are the four big warning signs:

• Vague delegation, duplicated work. Anthropic watched it happen in their own system: when the lead agent gave fuzzy instructions, subagents overlapped - in one example, one subagent explored the 2021 automotive chip crisis while two others duplicated the same research - and left gaps elsewhere. They also found that "agents struggle to judge appropriate effort," so they had to hard-code rules for how hard to try: a simple fact-find got one agent with a few tool calls, complex research got ten-plus subagents. The lesson: teams don't self-organize. You write the rules, or you pay for the mess.
• The job is a bad fit for teamwork. From Anthropic's own list of poor-fit domains: jobs where all agents must share the same evolving context, jobs with heavy dependencies between agents, and most coding tasks - because "LLM agents are not yet great at coordinating and delegating to other agents in real time." If the work is more like a group project where everyone must constantly talk, a team of agents is the wrong tool today.
• The value can't pay the bill. Anthropic's 15x bill doesn't shrink; the value of your task isn't fixed. A low-value task that goes multi-agent is a machine that loses money on every run, faster.
• The demo seduced you. Remember the orchestra fantasy: the demo is curated, and Anthropic's own build log is where the 50-subagent failures live. If your evidence is a slick video, your evidence is marketing.

There's one more money-saving move worth naming: when the flow is knowable, orchestrate it in code instead of asking a model to manage the team. The OpenAI Agents SDK docs recommend this directly - structured outputs for routing, chaining one agent's output into the next, evaluator loops, parallelism via asyncio.gather. And Anthropic's Building effective agents post gives you the middle-ground workflows before full autonomy: routing, prompt chaining, parallelization, and orchestrator-workers. Translation for a kid: there are cheaper, simpler toys that do many of the same jobs. Try those first. When the steps are known, plain code is the cheapest AI agent orchestration there is.

If you want to see what this looks like when it goes wrong at scale - costs hiding inside automation you already run - our post on the hidden costs of AI automation covers where the money leaks. And for the industry-level reality of where multi-agent workflows are actually landing, see our piece on hyperautomation and multi-agent workflows.

Keep it debuggable: trace every handoff

Back to the relay race - but this time, every baton pass is filmed. When something goes wrong, you replay the tape and see exactly which runner dropped the baton. Without the tape, all you know is "the team lost," which helps nobody. That's the whole idea of this section: if you can't trace every handoff between your agents, you're not ready for a team.

Trace every handoff before the second agent exists. If you can't see inside the machine, you can't debug agent collaboration at all.

This isn't a nice-to-have. Anthropic says flat-out that full production tracing was what made their system fixable at all. Before they had it, "users would report agents not finding obvious information, but we couldn't see why." After they had it, they could ask the useful questions: were the agents writing bad search queries? Choosing poor sources? Hitting tool failures? The toolkit for keeping a team debuggable:

• Trace every handoff. The hooks exist at the SDK level - the OpenAI Agents SDK's on_handoff callbacks and input_type schemas let you log each transfer, and the SDK ships built-in tracing. No excuses.
• Watch decision patterns, not just errors. Anthropic monitors decision patterns and interaction structures at a high level - the shape of how agents talk to each other, not just whether a call failed.
• Deterministic safeguards. Retry logic, checkpoints, and resume-from-where-it-failed. Restarts are expensive; a checkpoint means you replay from the drop, not from the gun.
• Judge the final state. For agents that change things in the world, evaluate the end state - the answer, the artifact, the result - rather than grading every intermediate step like a strict teacher.
• The artifact pattern. Have subagents write their findings to a shared filesystem and pass lightweight references back, instead of whispering the whole result along the chain. Anthropic uses this to avoid a game of telephone where each agent re-summarizes the last one's summary, snowballing tokens and errors together.

The pattern underneath all of it: you can't fix what you can't see. Build the camera before you build the team.

Start single. Graduate on evidence.

Learn to ride a bike before you join a motorcycle gang. It sounds like a joke, but it's the real rule: the single-agent habit - clear tools, a small eval set, honest measurements - is exactly the skill that makes the team work later. The riders who skip it are the ones who crash.

The rule: start with one agent and add a second only on measured evidence that one agent failed the job.

So, restated once, cleanly. Start with one agent. Give it the right tools. Test it on a small set of real queries. Escalate to deterministic workflows - routing, chaining, orchestrator-workers - when you need more structure, because predictable code beats paying a model to guess. Only go full multi-agent on measured failure, backed by a job valuable enough to pay the 15x bill, with tracing already in place.

And hold this as the standard for the whole field: the best multi-agent builders are the ones who can prove why the second agent had to exist. If you can't prove it, you don't need it. If you can - genuinely, with a failed eval and a real bottleneck - then build the team, film every baton pass, and let it earn its keep.

Multi-agent FAQs

Is a multi-agent system always better than a single agent? No. LangChain's docs say a single agent with the right tools and prompt can often achieve similar results, and Anthropic's guidance is to add complexity only when it demonstrably improves outcomes. Teams win only when the measured-failure checklist from this post checks out.

How much more does a multi-agent system cost in tokens? Anthropic reports that in their internal data, single agents used about 4x the tokens of a chat, and their multi-agent research system used about 15x. Those are their numbers for their system - not a universal constant.

What is the supervisor pattern, and how is it different from a router? A supervisor is a full manager agent that keeps control of the whole job, remembers the conversation, and calls specialists as tools. A router is a one-shot sorter - it classifies your request, dispatches it, and keeps no ongoing state.

When should I add a second agent? Only on measured failure: your single agent fails a small eval set of about 20 real queries, the job's value covers the token bill, the context genuinely overflows, the subtasks are truly parallel, tools are demonstrably overloaded, and your debugging setup already exists. All of that, not hype.

Do agent frameworks require multi-agent systems? No. LangChain, the OpenAI Agents SDK, and CrewAI all support single-agent builds. LangChain's own docs say a single agent with the right tools and prompt can often achieve similar results. Multi-agent is an option, never a requirement.