When to Use Multiple Agents Instead of One

The short answer

This guide assumes you have one agent working, or working badly, and someone has said the words "maybe we need a multi agent system". If you are still deciding whether the job wants an agent at all, read agent or workflow first. A good share of proposed multi agent systems are really a directed graph with a model bolted onto three of the nodes.

What a second agent costs before it earns anything

The bill arrives in five places. Price them before you decide, because the benefit is usually one crisp thing and the cost is diffuse.

• Context re-reads. Whatever the second agent needs to know is sent again. A 6,000 token shared brief across four agents is 24,000 tokens per run, before any agent says anything of its own.
• Serialisation loss. State that lived implicitly in one context window now has to be written down, and anything you forget is gone. The receiving agent invents a substitute rather than asking.
• Compounded error. Two steps at 95 percent are 90 percent together. Five are 77 percent. Nothing announces this. It shows up as runs that are subtly wrong rather than loudly broken.
• Latency addition. Sequential agents add their latencies, and a supervisor spends turns deciding who goes next. A three hop chain is often slower than one agent with a longer prompt.
• Debugging surface. One trace becomes a tree. Pricing produced a wrong number because intake dropped a field, and the log that proves it is two spans away.

The four seams that justify a split

A split pays for itself when it lands on a seam that already exists in the work. Seams are structural: you can point at one without mentioning models, and it survives a change of provider.

A fifth boundary is organisational: if two teams change two halves on different schedules, split them so deploys do not collide. Write that down as an org decision, so nobody later hunts for a technical rationale that was never there.

The topologies and what each is good for

Most systems described as multi agent are one of six shapes. Pick the shape from the work, not from a diagram you liked.

Two of these are not really multi agent systems, and that is the point. A router with specialists is a classifier and some prompts, a pipeline is a workflow, and both are cheaper to run and easier to explain on call.

The handoff is the whole problem

Whatever crosses the boundary between two agents is the actual design. Get it wrong and you have built a game of telephone with a token meter attached. Hand over a record, never a transcript.

A transcript invites the receiver to re-derive intent from narrative, differently on every run. A record is typed, carries ids instead of retellings, and states what done means in a way a machine can check. If the receiver genuinely needs the sender's reasoning, the seam is in the wrong place, so move it rather than widening the pipe.

{
  "handoff_version": "1.2",
  "run_id": "run_8f31c2",
  "from": "intake",
  "to": "pricing",
  "objective": "Price the three line items in quote Q-4471 using the 2026 rate card.",
  "inputs": {
    "quote_id": "Q-4471",
    "customer_id": "cust_1099",
    "line_item_ids": ["li_1", "li_2", "li_3"],
    "rate_card_version": "2026-01"
  },
  "evidence": [
    {"kind": "document", "id": "doc_7a1f", "sha256": "9c1e...", "why": "signed MSA, clause 4"},
    {"kind": "record", "id": "crm/opportunity/55210", "fetched_at": "2026-08-26T09:14:02Z"}
  ],
  "constraints": [
    "Do not contact the customer.",
    "Do not apply a discount above 12 percent without escalating."
  ],
  "done_when": {
    "check": "every line_item_id has unit_price, currency and rate_card_line",
    "machine_checkable": true
  },
  "budget": {"max_steps": 8, "max_tokens": 40000, "deadline": "2026-08-26T09:20:00Z"},
  "on_failure": {"return_to": "intake", "allowed_retries": 1, "must_report": "partial_result"},
  "forbidden_tools": ["send_email", "update_crm_stage"]
}

1. Objective is one imperative sentence. If it needs two, you are handing over two tasks and the second will be dropped silently.
2. Evidence carries ids and content hashes, not pasted paragraphs, so an audit can prove months later which version the agent saw.
3. done_when must be machine checkable. "Pricing looks reasonable" is not a completion criterion, it is a mood.
4. Budget is enforced by the caller, not requested politely in the prompt. Steps, tokens and wall clock, all three.
5. forbidden_tools belongs in the runtime, not only the text. The prompt is a suggestion; the tool registry is the boundary.

Run the arithmetic before you draw the diagram

Two numbers settle most of these debates: what the split does to your input token bill, since shared context is sent once per agent, and what it does to end to end reliability without verification. Use your own figures. Read the token price off your provider's current pricing page rather than trusting any article, including this one.

The reliability output ends arguments. At four agents and 95 percent per step, roughly 81 percent of runs come out clean, and the other 19 percent will not spread evenly across your customers. Your options are fewer hops, a verifier at the expensive hop, or a human at the irreversible one, which is keeping a human in the loop where it matters.

Failure modes that only exist once you have two agents

Single agent failures are mostly about tools and context. Multi agent failures are about coordination, and they are harder to see because every individual span looks fine.

• Duplicate side effects. Two workers both decide the email is theirs to send. Ownership lives in data, not prose: one logical action, one idempotency key from the run id plus a hash of the action, checked against a ledger before execution.
• Circular delegation. The supervisor delegates down, the worker hands it back as a clarification, and the loop runs politely until the budget dies. Bound delegation depth and break on the second identical action signature.
• Intent dilution. Each hop paraphrases the goal slightly, and by hop four the agent is confidently solving an adjacent problem. Pass an immutable objective string, unchanged from the origin.
• The confident empty handoff. A worker returns done with an empty payload because nothing forced it to prove completion. Machine checkable done_when removes this class.
• Straggler timeouts. Thirty nine documents finish, one hangs, and the reducer waits or quietly drops it. Per item deadlines, and a reduce step that lists failures by id.
• Supervisor summary drift. The summary of worker output becomes the record, so raw results are unreachable during an incident. Keep worker output addressable and treat the summary as derived.
• Shared memory write conflicts. Two agents write the same key in one run and last write wins silently. Scope memory per agent, or make writes append only with a writer id.

Cheaper moves to try before splitting

Before accepting the coordination tax, exhaust the changes that keep one trace and one context.

• Fix the tool descriptions first. Most "the agent got confused" reports are two tools whose descriptions overlap, and rewriting them takes an afternoon. See designing tools an agent can actually use.
• Make a subagent a tool call. A summariser with its own small context, called as a function returning a typed result, gives you context isolation without a coordination protocol. Highest value move here, and usually enough.
• Route, then run one specialist. A cheap classifier in front of three focused prompts beats a supervisor reasoning about which prompt to use, and it is directly measurable.
• Cut the tool list. Twenty tools where six would do is a selection problem solved by deletion, not by architecture.
• Add one verifier, not four agents. If quality is the complaint, an independent check on the final artifact recovers more than restructuring the pipeline.

How to split an agent that has outgrown itself

When the seam is real, treat the split as a measured refactor, not a rewrite. The first two steps are the ones people skip.

1. Freeze a golden set from real runsBefore touching anything

   Thirty to a hundred real inputs with the outcome you wanted, taken from production traffic rather than written by whoever is doing the refactor. Without it you cannot tell a better architecture from a differently broken one.

2. Instrument the agent you haveOne week of data

   Log per step: tool, arguments, latency, result status, step index, and whether the run hit the budget cap. The seam usually shows up as a cluster of failures around one class of work.

3. Name the seam out loudTen minutes, in writing

   Write the sentence: we are splitting because the halves need different X, where X is context, permissions, cadence or independence. If the sentence needs the word cleaner, stop and fix the prompt.

4. Write the contract before the promptsHalf a day

   The JSON schema first, with done_when, budget and forbidden tools. Prompts written before the contract encode assumptions the contract then has to bend around.

5. Run both versions in shadowOne to two weeks

   Same inputs into both, monolith serving production. Compare golden set success, cost per run, p95 latency and override rate. Expect the split to lose on cost and win on the seam you named. If it loses on both, you have your answer.

6. Ship behind a flag, keep the old path warmOne month

   Runnable, not commented out. The teams who can fall back in a minute at 4pm on a Friday are the ones who kept the old path deployable.

7. Add per agent evals and a disagreement alarmOngoing

   Each agent gets a small eval set against its own contract. Alert when a critic's disagreement rate collapses toward zero, which means it stopped checking.

The vocabulary, used precisely

Terms worth pinning down

Multi agent system

A system in which two or more model driven components hold separate contexts and exchange typed messages, with at least one of them deciding what happens next. If the sequence is fixed in code, it is a workflow with several model calls, not a multi agent system.

Handoff contract

The typed record passed from one agent to another, carrying an objective, typed inputs, evidence references, constraints, a machine checkable completion condition and a budget. It is the interface of the system and should be versioned like one.

Supervisor

An agent whose tools are other agents. It decides who runs next and when the work is done, which makes it both the coordination point and the most common bottleneck.

Delegation depth

How many nested handoffs deep a run may go before the runtime refuses. Bounding it is what stops two polite agents passing a task back and forth until the token budget dies.

Side effect ledger

An append only record of actions with external consequences, keyed by an idempotency key and checked before execution. It is what stops a retried or duplicated plan from sending the same email twice.

Disagreement rate

The share of artifacts a verifying agent rejects or amends. Tracked over time it tells you whether a critic is doing work; a rate drifting toward zero usually means the critic has been given the author's context.

If a supervisor is the right answer for your case, the build, the tracing and the evals are multi-agent systems and agent observability.