Multi-agent AI for business: when one agent is enough and when to split

A multi-agent system uses several AI agents, each with its own job, tools and permissions, coordinated so that together they finish a task. Most business processes don't need one. A single agent with a well-chosen set of tools is simpler to build, test and audit. Split the work only when you need separate permissions, when the context won't fit in one agent, or when parts of the job can run in parallel.

#What multi-agent means in practice

An AI agent is a model with a goal, a set of tools and rules about when to stop or ask a person. See what an AI agent is for the basics. A multi-agent system puts two or more of them together. One might gather facts while another drafts the response.

You'll see three common arrangements.

A manager agent breaks a task into pieces, hands each to a worker agent and combines the results. A pipeline passes work from one agent to the next in a fixed order, like stations on a line. A handoff passes a case from one agent to another when the topic changes, for example from a general support agent to a billing specialist.

None of this requires the agents to be smart about each other. In production the coordination layer is often ordinary code and workflow rules, which is what orchestration means. We'd rather have deterministic code decide who runs next and let the models do only the reading and drafting. Agents negotiating with each other is less reliable. The conceptual background is in our explainer on agentic AI. This piece covers the architecture and the cost of splitting.

#One example, built two ways

Take an invoice exception. A supplier invoice fails a three-way match because the invoice price is above the purchase order price. Someone has to work out why, decide what to do and tell the right people.

#Option A: one agent with tools

A single agent gets five tools. It can read the invoice, read the purchase order and goods receipt, read the vendor's recent invoices, draft an email to the buyer and create an exception ticket. It reads the case, calls what it needs, and writes a ticket with a proposed action.

This works because the job is short and the context is small. Everything the agent needs fits in one prompt. When a result is wrong, there's one transcript to read.

#Option B: two agents with separate permissions

The same job, split in two. An investigator agent has read-only access to the ERP and document store. It returns a structured finding: the cause (price change, partial delivery, duplicate, unit mismatch), the evidence and a confidence level. A resolver agent receives only that finding. It can draft a vendor email and create a ticket, but it has no ERP access at all.

The reason to do this is permissions. The agent that reads untrusted supplier documents can't write anywhere. The agent that writes never sees the raw document, which shrinks the damage if a PDF contains hidden instructions. That's a real security argument, and it's the best reason we know to split.

If your only motive is that two agents sounds more capable, Option A is the better build.

#What you pay for when you split

Anthropic published figures from its own research system that put numbers on the cost point. In its engineering write-up (opens in a new tab), it reports that agents use about four times the tokens of a chat interaction, and multi-agent systems about fifteen times. It also says multi-agent setups fit tasks with heavy parallelization, and suit poorly the domains where agents must share the same context or depend heavily on each other. Those are their numbers on their workload, so don't read them as a forecast for yours. The direction holds, though: more agents means more model calls.

#The failure modes that are new

Splitting trades one set of problems for another.

Context loss at handoffs. The investigator found that the price rose because the supplier switched pack sizes. The resolver gets a summary that says "price variance" and drafts a vague email. Fix it with a structured handoff format and tests on the interface itself.

Loops. Agent A asks B for more detail, B asks A to clarify, and neither stops. Cap the number of turns and the model spend per case, and have the coordinator end the case and escalate to a person.

Compounding errors. A small mistake in the first agent's output gets treated as fact by the second. Validate between agents in code, as you would between any two systems.

Unclear accountability. When a case goes wrong, which agent was responsible? Log each agent's inputs, outputs and tool calls under a case ID that links them.

Harder evaluation. You now test each agent in isolation, then the chain end to end. Our guide to AI agent evaluation covers the test set and the pass bar.

#When splitting is worth it

Run through this checklist. If you can't tick at least one box, stay with one agent.

1. Different permissions. One step reads untrusted content and another writes to a system of record, and you want a hard wall between them.
2. Context size. The material per case is too large for one prompt, such as a long contract plus its amendments, and each agent can work on a slice.
3. Parallel work. Independent sub-tasks can run at once, like checking one customer against five systems.
4. Different owners or models. One step needs a specialist (a fine-tuned classifier, a different vendor's model) and a separate team maintains it.
5. Independent checking. You want a reviewer agent that has not seen the drafter's reasoning, with a person approving the result.

These reasons are weak: it looks impressive in a demo, a framework made it easy, or the process diagram has a lot of boxes. A diagram with many boxes can often be one agent with several tools.

#How we'd approach it

We start with the simplest design that works. Where the steps are known, that's a fixed workflow. Where a step needs judgment, it's a single agent. Extra agents come in only when one of the reasons above shows up. Every agent gets its own scoped credentials and a tool allowlist, because narrow roles are the main benefit of splitting. A person approves anything irreversible, such as payments, bank detail changes or first-time external messages.

Key point: Split an agent for permissions, context size or parallel work, never for sophistication. Every extra agent adds model calls and handoffs that you will need to test, trace and own.

In the invoice case, we'd likely start with Option A for a first release, measure it, and move to Option B if the security wall or volume justifies it. The exact boundaries in our AI agents work depend on the process. If you're deciding whether a process needs one agent or several, book a strategy call and we'll map the steps and permissions with you.

#Frequently asked questions

#What is a multi-agent system?

It's a set of AI agents that each handle part of a task, with tools and permissions of their own, coordinated by a manager agent or by workflow code. Each agent does a narrow job, and the system combines their outputs.

#Is multi-agent AI better than a single agent?

Not by default. A single agent with the right tools is cheaper, faster and easier to test for most business processes. Multi-agent designs help when you need separate permissions, parallel work or more context than one agent can hold.

#What is agent handoff?

It's the point where one agent passes a case to another, along with the information needed to continue. Handoffs fail when context gets dropped, so use a structured format and test the handoff itself. A handoff to a human should carry a summary of what the agent found.

#How do agents coordinate with each other?

Usually through an orchestrator, which is either a manager agent or ordinary workflow code that decides who runs next and passes results along. We prefer code for the routing wherever the steps are known, and models for reading and drafting.

#Does multi-agent AI cost more to run?

Yes, generally, because each agent makes its own model calls and the coordination adds more. The size of the increase depends on the design. Measure cost per case on a test set before choosing, and cap model spend per case in production.