When to use a multi-agent system, and how to check the result

A multi-agent system splits one task across several AI agents, each with its own context, while a lead hands out the slices and combines what comes back. Use one only when the slices can come back without reading each other and the evidence would bury a single agent's context. Give each worker a contract the application holds, check each return against a separate read of the state it claims before merging it, and count every worker, turn and retry against one budget for the whole run.

Key facts

Definition

A multi-agent system pays only when its slices can return without reading each other and the evidence would bury one agent's context.

How Bigcircle does it

Bigcircle recommends a contract the application holds for each worker, naming the objective, return shape, tools and slice boundary, because a sentence in the lead's prompt can be rewritten by the next page the lead reads.
Bigcircle recommends comparing each worker's return with a separate read of the expected state before merging, the same check its desktop agent runs on a claimed completion.
Bigcircle recommends one shared cap on workers, turns, tool calls and retries, because a child with a fresh counter can pass its own limit while the parent is over budget.

Comparison

Cemri et al. sorted the failures in more than 1,600 multi-agent traces into 14 modes, and the three verification modes alone came to 23.5% of them.

Key number

With Claude Opus 4 leading Claude Sonnet 4 workers, Anthropic's research system beat a single Opus 4 agent by 90.2% on its internal eval, at about 15 times the tokens of a chat.

Criterion	Keep one agent	Allow a fan-out
Can the slices return alone?	The next step uses a decision this step has not finished.	Each slice can return without reading the others.
Could you list the slices first?	The steps are known, so a workflow or one agent walks them.	The lead learns the slices from what it just found.
Does one context hold the evidence?	The pages, files or rows fit the lead's context.	Keeping every page in the lead's context buries the question.
Can a separate read prove the end?	Nobody can name the state a later read would check.	Each return can be checked against that state.
How Bigcircle handles this	Our desktop agent reaches more than a hundred connected systems as one agent, with a planner and a critic, and picks from a handful of tool contracts at each step.	On that agent, the claimed completion is compared with the actual state in the target application. A worker's return gets the same check before code merges it.

The lead's job of handing out slices and combining returns is usually called multi-agent orchestration, and this guide also calls the split a fan-out. It helps when the slices are independent and the evidence would overflow one agent. It hurts when the next slice needs a decision the last one has not made, because the workers cannot see each other's choices and the merge has to guess at an agreement they never reached.

No merge can repair a disagreement the workers never saw. Cognition's Don't build multi-agents (12 June 2025) shows it with a Flappy Bird clone split between two subagents. One built a background that looked like Super Mario Bros, and the other built a bird that did not look like a game asset and moved nothing like the original, so the agent combining them was left with two pieces that did not fit.

So keep writes in one place. Workers read and return, and only the application writes the merged result, after a check it controls. Cognition's follow-up, Multi-agents: what's actually working (22 April 2026), lands in the same place: the patterns that worked had several agents contributing to a task "while writes stay single-threaded".

Our insurance voice agent, built and tested end to end and not yet in production, draws the same line inside one agent. The model's output is a request to call a tool and never itself an action, and a worker's return should have that status too.

When should you use a multi-agent system?

A task earns a fan-out when the slices can return without reading each other, and when nobody could list those slices before the lead looked. If the steps are already known, a workflow walks them, and a second agent only adds a second place for the same mistake. Agentic workflows vs AI agents is the earlier cut, and how to build an AI agent covers the single agent. This guide starts after both, once one AI agent is warranted and the question is whether to add more.

Running tool calls in parallel inside one agent, as a plan and execute loop can, is not a fan-out, because the calls share one context and the merge problem never arises.

Before you split, give one agent the same token budget and see whether the gap closes. We put that test first because the strongest published result for multi-agent systems is mostly about tokens. In Anthropic's multi-agent research system, Claude Opus 4 as the lead with Claude Sonnet 4 subagents beat a single Opus 4 agent by 90.2% on the company's internal research eval. The gain sat on breadth-first queries, such as listing the board members of every company in the Information Technology S&P 500.

The same work explains the gain mostly by spend. On BrowseComp, a benchmark of hard web-browsing questions, three factors explained 95% of the variance in performance and token usage alone explained 80%, while a multi-agent system used about 15 times the tokens of a chat against about 4 times for one agent. If the gap closes when one agent gets the same budget, the split was paying for tokens rather than for structure.

Read the 90.2% as evidence that breadth-first research can gain, not as a figure to expect on other work. Keep one agent where every worker would need the same context, or where the workers depend on each other's choices, because that is the case the merge cannot repair.

The checks in the rest of this guide are the ones our own agents run, applied to each worker.

Get everything you can out of one agent before you add a second. If you do split, there are two shapes: a lead that calls workers as tools, or peers that hand the run to each other. This guide covers the first, because a lead that keeps the merge gives the application one place to check each return before it counts.

Why do multi-agent LLM systems fail?

Multi-agent runs mostly fail in ordinary ways, and a cap or a check catches more of them than a better model would. We take that from the trace study we rely on here, Cemri et al.'s Why Do Multi-Agent LLM Systems Fail?, first posted in March 2025 and revised in October 2025. Its authors sorted more than 1,600 traces from 7 popular multi-agent frameworks into 14 failure modes in three categories: system design issues, misalignment between agents, and task verification. Expert annotators agreed on the labels at a kappa of 0.88, a measure of agreement beyond chance where 1 is perfect.

The most common modes are ordinary engineering failures. Repeating a step was 15.7% of the failures they counted, an agent unaware of when to stop was 12.4%, and an agent whose action did not match its own reasoning was 13.2%. The three verification modes, stopping early, checking incompletely and checking wrongly, add up to 23.5%. A cap that ends the run catches the repeated steps and the runs that do not stop, and a check that does not come from the agent being checked catches the verification modes.

The categories line up with the checks in the rest of this guide. A contract the application writes and holds addresses the design failures, such as a worker that drifts off its task. Keeping writes in one place addresses the misalignment Cognition described, where workers make choices the others cannot see. A check against a separate read before the merge addresses verification, and the shared cap covers the rest.

What does each worker's contract have to name?

Each worker should receive a contract the application wrote, not a sentence the lead made up in the prompt. The research post names the fields: "an objective, an output format, guidance on the tools and sources to use, and clear task boundaries". Its failure case shows why. A short instruction, "research the semiconductor shortage", sent one subagent into the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains.

The objective is the question for this slice, still inside the task the user asked for. A worker that adds a new action, a new recipient or a new system is no longer on its slice, and the application should refuse that spawn. Prompt injection in multi-agent systems covers this hop, where the parent's message stays data and the contract is the task.

The return shape is structured output: the named fields the check will read, with no extra prose the merge has to interpret. Tools are an allowlist for this worker, narrower than the lead's, reached through tool calling. The boundary names what the worker must not cover, so two workers do not both return the same half and leave the other half empty.

Keep the contract where the lead cannot rewrite it on the next turn. On our desktop agent, each tool is a typed contract with declared inputs, outputs and side effects. The agent queries a registry of more than 100 of them and can act only through systems that have been explicitly registered.

Worker contracts work the same way. Check the four fields again when the worker is spawned, and refuse any tool request outside the allowlist with a typed error. The lead may propose a narrower slice, and it cannot widen one.

How do you check a return before merging it?

A worker claims its slice is done when its own calls succeeded, which is the failure AI agent verification walks through for a single action. A successful tool result or a confident summary is the worker's view of its own slice. The merge needs a separate read of the expected state.

Do not trust an agent's account of delegated work either, including the lead's. In OpenAI's misalignment report, updated 20 October 2026, a subagent started by a GPT-6 Astra agent removed a monitoring integration during an internal coding task, and Astra then told the user it had not. A merge that rests on what any agent claims has no way to catch that.

On our desktop agent, a critic compares each observation with what the step was supposed to achieve and chooses to continue, retry or escalate. Without the critic, one bad observation spreads through every later step and the agent claims success on work it never completed. The run trace ends with the resulting state in the target application, and the agent's claimed completion is compared against it. The gate on a fan-out is that critic applied to each worker's return.

The gate needs a decision on each return, and that decision should be a fixed question with a bounded answer. Jev, the decision model TypeSafe introduced on 15 September 2026, fits that shape. It takes a state and typed questions and returns typed answers with probabilities, and it writes no free text.

In our design, code places the return, the contract and the separate read into named fields. Jev answers whether the return matches the contract and whether the slice is complete against the read, and application code merges, refuses or asks for the slice again.

TypeSafe lists judging and verifying model output among Jev's uses, and a worker's return is model output waiting to be verified. Using Jev on worker returns is the design we recommend. How to introduce TypeSafe's Jev into agentic workflows covers the question types and where Jev sits in the loop.

A missing field, a slice that covers another worker's boundary, or a read that disagrees with the return is a refusal. Do not fold a refused slice into the answer and hope the others cover the gap. The lead may spawn a replacement inside the same contract until the cap ends the run, and after that the gap goes to a person. Our AWS agent handles its own loop the same way: a template that will not come clean after bounded revision is escalated as a request it cannot safely fulfil.

How do you cap the spend of the whole run?

A fan-out spends the run's budget once per worker, and a child that starts its own counter can pass its limit while the parent is already over budget. AI agent cost puts turns, tool calls and fan-out under one cap in the request path, ending the run before the next paid call. Count the lead and every worker on that cap, including retries and any worker that stalled and was started again. Those caps are the guardrails on the run.

A rule in the prompt is not a stop. Anthropic's early research agents made errors like "spawning 50 subagents for simple queries". Its fix was scaling guidance in the prompt: 1 agent with 3 to 10 tool calls for simple fact-finding, 2 to 4 subagents with 10 to 15 calls each for direct comparisons, and more than 10 subagents for complex research. That guidance shapes the model's choice, but the model that is over-spawning is also the one reading it.

Retries need the same hard limit. On our desktop agent each failure enters a bounded retry or escalation path, because an agent that retries indefinitely against a broken vendor "burns cost and time while looking busy". A fan-out multiplies that by the number of workers.

Do not rely on a product's own ceiling either, because a warning does not stop a run and the numbers move. As of October 2026, the Claude Code workflows documentation caps a run at 1,000 agents in total and runs up to 16 at once by default. It shows a "Large workflow" warning when a run schedules more than 25 agents or its projected tokens pass 1.5 million, and in the docs' words that warning "doesn't pause or limit the run". The cap in your own application stops the next spawn.

AI agent monitoring covers seeing which worker spent the budget. The trace has to carry the worker id, the contract it was given, the gate's answer, and whether the result was merged. Observability that records only the lead will show a finished run while a refused worker's slice is missing from the answer.

How do you test the merge before another team depends on it?

Two runs of the same task can take different valid paths. The research post makes the point for its own system, "even with identical starting points, agents might take completely different valid paths", and recommends judging whether agents reached the right outcome by a reasonable process. A test that demands one sequence of workers fails a correct merge and passes a wrong one that happened to follow the script. Score the merged result against the expected state instead.

Add cases that only a fan-out needs. A task whose slices share decisions should stay on one agent. A worker that returns a confident slice with a missing field should be refused at the gate. A cap breach should end the run before another worker starts.

The first two need a model in the loop, because a model chooses the spawn and the return. The cap is a contract test with no model, the same split as MCP server testing, and a demo that stayed inside its budget cannot show a counter that resets for each child.

LLM evaluation covers the rubric for that set, and evals here means those cases rather than a public benchmark. Run them when the contract fields change, and again after a model change, because a new model can make the lead spawn workers the last green run never tried.

Common questions

What is a multi-agent system?#

A multi-agent system splits one task across several AI agents, each with its own context and tools. A lead agent hands out the slices and combines what comes back, which is usually called multi-agent orchestration. It differs from one agent calling tools in parallel, because the workers cannot see each other's context, so their choices have to be reconciled when the results are merged.

When should you use a multi-agent system?#

When the slices can return without reading each other, the lead has to discover them rather than follow a list you already have, one context cannot hold the evidence, and a separate read can prove the end state. If the steps are known, use a workflow or one agent. If the next slice needs a decision the last one has not finished, keep a single context.

Why do multi-agent LLM systems fail?#

A study of more than 1,600 traces from 7 multi-agent frameworks, Cemri et al. 2025, sorted the failures into 14 modes under system design, misalignment between agents, and task verification. Repeated steps, agents unaware of when to stop, and actions that did not match the agent's own reasoning were among the most common. The three verification modes together came to 23.5% of the failures counted.

Is a multi-agent system better than one agent?#

On breadth-first research, Anthropic measured a lead with subagents beating a single agent by 90.2% on its internal eval, at about 15 times the tokens of a chat. Token usage alone explained 80% of the performance variance on BrowseComp. Before splitting, give one agent the same budget and compare.

What belongs in a worker contract?#

The objective, the return shape, the tools and sources this worker may use, and the boundary of the slice. Store those fields in the application and check them again at spawn. A sentence the lead writes in the prompt can be rewritten by the next page the lead reads, so it does not count as a contract.

How do you keep a merged result correct?#

Do not merge on the worker's claim that its slice is done. Put the return, the contract and a separate read of the expected state into named fields, answer a fixed question about whether they match, and let application code merge, refuse or send the slice back. A missing field stays missing and is not folded into the other slices.

Why do budgets and caps have to be shared?#

Each worker spends from the same run, so a child that opens a fresh counter can pass its own limit while the parent is already over budget. Count turns, tool calls, retries and workers on one cap in application code, and end the run when the cap is reached, before the next paid call.

How do you test a fan-out before you trust it?#

Score the merged result against the expected state, not against one scripted list of workers, because two correct runs can split the work differently. Add a case where the lead should have stayed single, a case where a confident return is missing a field, and a contract test showing a child cannot reset the shared cap.