When One Agent Is Not Enough

Imagine asking one assistant to plan a simple trip. It can search for a flight, compare a couple of hotels and put together an itinerary. For a straightforward trip, one assistant is plenty.

Now imagine the trip involves three cities, several meetings, a budget, and plans that may change halfway through the week. At that point, dividing the work starts to help. One AI agent can concentrate on flights, another on hotels, another on the schedule, while a coordinator brings their results together into one plan.

That is the simplest way to understand a multi-agent system: a small team of AI agents, each with a clear responsibility, working towards the same larger goal.

And immediately, the caution that has to travel with the idea. More agents are not automatically better. Very often one capable agent with good tools is simpler, faster and cheaper. The useful question is never how many agents can I use? It is would dividing this work make the system better?

What the phrase does and does not mean

Notice what the definition above does not say. It does not say the agents talk freely, negotiate, or have personalities. Those things are possible, and mostly not what working systems do.

Most production multi-agent systems are considerably more boring than the phrase suggests: a coordinator, some workers, clear assignments, and a place the results get collected. The interesting engineering is not in the agents. It is in the division of labour.

What genuinely changes when you add a second agent

Three things, and it is worth being precise, because only one of them is usually the reason people reach for it.

More total working memory. Each agent has its own context window. Five agents have five of them. For a task whose information will not fit in one context, this is not an optimisation — it is the only way the task fits at all.

Work happening at the same time. Independent work runs simultaneously instead of in sequence. This is what people usually want, and it only materialises if the work is genuinely independent.

Specialisation. Each agent can have a narrower brief, fewer tools and a cheaper model. A focused agent with four tools behaves far more predictably than a general one with forty.

When a second agent is worth considering

There is no single test that settles this, and anyone who offers you one is oversimplifying. What there is, is a list of benefits worth having. A second agent starts to make sense when you can point at one of these and say that one, specifically.

The work can genuinely happen at the same time. Two lookups that do not depend on each other's results.
Different parts need very different expertise. A legal reading and a pricing analysis are not the same skill.
Different stages need different tools. One part searches the web; another queries an internal database.
Separate permissions make the system safer. A drafting agent that cannot send, and a sending agent that cannot draft, is a stronger arrangement than one agent trusted with both.
Separate contexts prevent overload. The verbose, noisy work happens somewhere else and comes back as a summary.
An independent second opinion is valuable. A reviewer that has not seen the writer's reasoning will catch things the writer cannot.
One agent would otherwise carry too much. Sheer volume of information, beyond what one context can hold.

Having found your reason, ask three questions before acting on it:

Does the benefit justify the extra cost? Chapter 11 gave you the shape of that cost, and it is not small.
Does the handoff add complexity you do not need? Every place work passes between agents is a place something can go wrong.
Would one agent with an additional tool solve this more simply? Usually, yes. Which brings us to the most useful habit in this part of the book.

Start with one agent. Add another only when you can explain what the additional agent is buying you.

Ask whether a tool would do

Before adding an agent, ask whether a tool would do the job. This one question will save you more trouble than anything else in this chapter.

An agent that needs to search does not need a search agent. It needs a search tool. An agent that needs to run a calculation needs code execution, not a mathematician agent. Adding a tool costs one function and one description. Adding an agent costs a context, a set of instructions, a way of handing work over, and a step that combines the results.

Reach for a second agent when you need a separate context, a separate permission boundary, or a separate judgement — not merely a separate capability.

What it costs

Every one of these arrives with the second agent, and none of them exists with one.

Money. Substantially more computation, and therefore more spend.
A floor under how fast it can be. A fresh agent has to gather its own context before it can do anything. For short tasks that setup exceeds the work.
Information loss. Every handoff is a place where detail can be dropped. Anthropic's phrase for this — a game of telephone — is exactly right.
Coordination failures. Duplicated work, gaps between assignments, agents waiting on each other.
Harder debugging. There is no single conversation to read, and the same request may take a different path twice.
Surprising sensitivity. Small changes to one agent's instructions producing large shifts in the whole system's behaviour, because the effect travels.

None of this is an argument against dividing work. It is an argument for doing it where it pays, and for expecting the bill.

Table 12-1: Where dividing the work helps, and where it does not

Divide it	Keep it in one agent
Researching fifty companies — each lookup is independent	Refactoring a codebase — every change touches the others
Reviewing a long document from three angles at once	A conversation with a person — shared context is the whole point
Watching many data sources continuously	Anything short — coordination costs more than it saves

A worked judgement

Something concrete, to make the reasoning real. Suppose you want a system that reviews supplier contracts.

The obvious design: a legal agent, a finance agent, a risk agent and something to write the summary, all conferring with each other.

Now work through it properly. Is there a benefit to name? Yes, two: the three readings need genuinely different expertise, and they can happen at the same time because none of them needs the others' conclusions. Is the volume beyond one context? For a two-page contract, obviously not. For a hundred-page agreement with appendices, obviously yes. Is it worth the cost? A supplier contract, plainly yes.

So the answer depends on the contract, which is a much more interesting conclusion than either yes or no.

Short contracts: one agent, three instructions run in sequence. Spend the savings on better retrieval, which will help more.
Long contracts: a coordinator with three reviewing specialists, each holding its own portion, and a step at the end that produces one report.

That is the kind of reasoning this part of the book is trying to install. The architecture follows from the task, never the other way round.

Key takeaways

A multi-agent system is a small team of AI agents with clear responsibilities working towards one goal. Usually less exotic than it sounds.
What it buys: more total context, work happening at the same time, and specialisation.
Add an agent when you can name the specific benefit — parallel work, different expertise, different tools, permission boundaries, separate contexts, an independent opinion, or sheer volume.
Then check the cost, the handoff, and whether one agent with another tool would do.
Start with one agent. Add another only when you can say what it is buying you.
Ask whether a tool would do. Usually it would.
Every cost listed here arrives with the second agent. Expect the bill.

Deciding whether to divide the work is the hard part. Deciding how is more tractable, because there turn out to be only a handful of shapes these systems take — and each of them is something you have seen people do.