Skip to content

Multi-agent AI systems: when one agent isn’t enough

Once a first AI agent works, the next idea usually follows quickly: what if we had a team of them? A researcher, a writer, a checker and a manager agent handing out the work. Frameworks make this look easy to set up, and the diagrams look like a tidy org chart.

Sometimes splitting work between agents does help. More often it adds cost, slows things down and creates new ways to fail. This post explains what multi-agent systems are, the few patterns that hold up in practice, and how to tell whether you need one. If you’re new to agents, read What is an AI agent? first.

What “multi-agent” means

A multi-agent system is several AI agents, each with its own instructions, tools and working memory, passing work between them. In practice there are two common shapes:

  • An orchestrator with specialists. A lead agent receives the task, splits it into parts, hands each part to a specialist agent and combines what comes back.
  • A pipeline. One agent’s output becomes the next agent’s input: one extracts, the next checks, the next writes.

Orchestrator and specialists

Lead agent plans, delegates, combines
  • Research agent
  • Data agent
  • Writing agent
  • Review agent
Each specialist has its own instructions, tools and context. Underneath, it’s often the same model.

A “specialist” is usually the same model with different instructions and a different set of tools. It isn’t a different kind of AI. The split is about what each agent sees and what it’s allowed to do.

Why it can help

Each agent sees less

Everything a model works with has to fit into its context window: the text it can see at once, including instructions, conversation, documents and every tool result. On a big task that fills up, and quality drops as the model has more to sift through. A sub-agent can read 50 pages and return a one-paragraph summary to the lead agent, whose view stays clean. A construction company answering a public tender is a good example. One agent works through the 200-page tender documents and returns the 15 requirements that matter. The agent preparing the bid only ever sees those.

Narrow roles make fewer mistakes

An agent with 40 tools picks the wrong one more often than an agent with five. Splitting by role keeps each tool list short and each set of instructions focused. An agent that only writes needs no database tools; an agent that only looks up stock needs no email tools.

Separate permissions

The agent that reads incoming emails, which may contain anything, doesn’t need the tool that issues refunds. Splitting the work lets you give each agent only the access its job needs.

Parallel work

For wide research, several sub-agents can search at the same time. That makes the whole task faster, though not cheaper. Checking the price lists of ten competitors, or the public records of eight potential partners, takes roughly as long as checking one when each check runs in parallel.

The most detailed public numbers come from Anthropic, which described its own multi-agent research system in 2025. They show both the gain and the price.

What Anthropic measured

  • 90% better score for the multi-agent system than for a single agent on Anthropic’s internal research evaluation
  • 4× more tokens used by a single agent than by a chat interaction
  • 15× more tokens used by the multi-agent system than by a chat interaction
Source: Anthropic engineering blog, “How we built our multi-agent research system”, June 2025. Approximate figures from Anthropic’s own research tasks, not from typical business processes.

Read those numbers together. The better score came with roughly four times the usage of a single agent. Anthropic’s own analysis found that the amount of work done, measured in tokens, explained most of the difference in performance. Much of the gain came from doing more work in parallel, not from the team structure itself. Anthropic’s conclusion was that it pays off only when the task is valuable enough to cover the cost.

Why you often don’t need it

Those results came from broad research questions, where the work splits naturally into independent searches. Anthropic’s own write-up says that domains where all agents need to share the same context are not a good fit today. Most business tasks look more like that. Here’s what tends to go wrong:

  • Cost and time. Every extra agent means extra model calls and extra waiting. If the task isn’t valuable enough to justify several times the usage, the numbers don’t work.
  • Lost context. When the lead agent hands over a task, it passes a short brief, not everything it knows. Details get lost at each hand-off, much as they do between people.
  • Conflicting assumptions. Sub-agents working in parallel can’t see each other’s work. Cognition, which builds a coding agent, described this in 2025 with a game example. One sub-agent builds a background in one style, another builds a character in a different style, and the final agent is left with parts that don’t fit together.
  • Harder debugging. When the answer is wrong, you first have to work out which agent got it wrong and why. A 2025 study led by researchers at UC Berkeley, “Why Do Multi-Agent LLM Systems Fail?”, sorted failures in popular frameworks into three groups. The groups were poor system design, agents misunderstanding each other, and weak checking of results. Many of them had little to do with how capable the model was.
  • Tasks that need one shared picture. Drafting one coherent contract, building one piece of software or handling one customer conversation works best when a single agent sees everything.

One agent or several?

Single agentMulti-agent
Cost per task Lower Several times higher
Speed on wide research One step at a time Parallel, so faster
What each agent sees The whole task Its own part, plus a brief
Consistent output Yes Partly
Easy to debug Yes No
Separate permissions per role Partly Yes
Best for Most business tasks Wide research, independent parts, strict access rules
Typical trade-offs. Start in the left column and move right only for a named reason.

For the wider question of whether a task needs an agent at all, see When to use AI agents.

Three patterns that hold up

Orchestrator and workers, for wide research

Use it when a question breaks into independent parts. Imagine a distributor deciding whether to add five new suppliers. The lead agent sends one sub-agent per supplier to check the company register, recent news, price lists and delivery terms. Each returns a one-page summary in the same format. The lead agent compares them, and a buyer makes the decision.

Vetting five new suppliers

  1. Buyer asks Compare these five suppliers
  2. Lead agent plans One brief per supplier, same format
  3. Sub-agents research Register, news, prices, terms, in parallel
  4. Lead agent compares One table, sources linked
  5. Buyer decides
The sub-agents work in parallel. Every source they use is logged.

When a decision may have to be defended later, keep the record. In regulated industries, why a vendor was chosen matters as much as the choice itself. The platform we built for Dilly Labs helps financial institutions choose technology vendors. It keeps a record of each decision and its reasons, so teams can answer questions from colleagues, the board or regulators later. An agent system that supports decisions needs the same: every source, summary and step logged.

Writer and reviewer

One agent drafts. A second checks the draft against a checklist or the source documents and sends it back with specific fixes. An accounting firm could use this for client letters about tax changes: the writer drafts, and the reviewer checks every figure and date against the source and flags anything it can’t find. Limit it to two or three rounds, and send anything still failing to a person.

A recruitment agency could do the same with job ads. One agent drafts the ad from the client’s brief. A reviewer checks it for wording that could discriminate against candidates, and for promises the client never made.

This works because checking is easier than writing, and because the reviewer starts fresh, without the writer’s assumptions. It’s the multi-agent pattern most companies will actually use.

A pipeline that keeps untrusted input away from actions

A support team receives customer emails, which can contain anything, including text written to manipulate an AI. The first agent reads the email and fills in a structured form: customer, order number, type of request. It has no tools that change anything. The second agent works only from that form and has the tools to act. A hidden instruction in the email never reaches the agent that can issue refunds. Keeping AI agents safe covers this and other defences.

Start with one agent and good tools

The order we recommend:

  1. Build one agent with a short list of narrow tools. How AI agents use tools explains how to design them.
  2. Test it on real past cases and look at where it fails.
  3. Fix the cause. Most failures come from unclear instructions, a confusing tool or missing data. Fix those first; they’re cheaper than a second agent.
  4. Split only for a named reason: the context is overflowing, the work can genuinely run in parallel, or one part needs different permissions. An overflowing context has recognisable symptoms: on long tasks the agent forgets rules from its instructions, or mixes up details from different documents.
  5. Measure again. If the split didn’t improve results enough to pay for itself, undo it.

Agents from different companies

You may also hear “multi-agent” used for agents from different organisations talking to each other: your purchasing agent asking a supplier’s sales agent for prices and delivery dates, for example. Standards for this exist, such as the Agent2Agent (A2A) protocol that Google introduced in 2025 and that is now hosted by the Linux Foundation. For most companies it’s still early days. The same rules apply as inside your own walls: be clear what each side may do, log every exchange, and keep a person on any decision that commits money.

What to do next

Before you approve a multi-agent design, from a vendor or from your own team, ask these questions:

Questions for a multi-agent proposal

  • Which problem does each extra agent solve?
  • What did the single-agent version get wrong?
  • What does one task cost? Compared with one agent doing the same task
  • How long does one task take? End to end, including waiting for sub-agents
  • What is passed at each hand-off? A short brief, or everything the previous agent knew?
  • Can we see a full log of every agent’s steps?
  • Who reviews the result before it’s used?

If you’re weighing up an agent design, or wondering whether your use case needs agents at all, book a 30-minute call. We’ll tell you honestly if one agent, or a plain workflow, will do the job.

More articles.

  1. How to bring generative AI into your company: a 90-day plan

    A practical 90-day plan for generative AI: pick the first process, assign owners, choose tools, run a checked pilot, manage risks, avoid stalling.

  2. What is an AI agent? A plain-English guide for business teams

    What an AI agent is, how it differs from a chatbot and an AI workflow, what it’s made of, and where it’s worth using in an ordinary company.

  3. What is MCP? The Model Context Protocol explained for companies

    What the Model Context Protocol is, how it connects AI apps to your CRM, files and databases, when you need it and what to secure first.

All articles

Want a second opinion on your project?

Book a call and we’ll talk through your options.

JurajCEO, QikBuild

You leave the call with

  • What we would build first
  • A rough price range
  • Whether custom software makes sense for you
Book a 30-minute call

Or write to hello@qikbuild.com