1  Why More Than One Agent?

The honest answer to the question in this chapter’s title is that, most of the time, you should not have more than one. An enormous amount of contemporary engineering effort goes into assembling committees of language models to do work that a single competent agent — or, frequently, a plain for loop — would do faster, more cheaply, and with considerably less drama. Before we spend the rest of this book on how to build multi-agent systems well, it is worth being clear about when to build one at all; and the first thing to say is that “because we can” is not a reason.

The proper reason is structural. Some problems are inherently distributed: the knowledge needed to solve them is scattered across parties who cannot or will not pool it; the objectives in play are only partly aligned; decisions must be taken concurrently, by participants answerable to no central authority; and the resources involved are finite and contested. Drop a single, all-seeing agent into a world like that and you have not so much solved the problem as declined to acknowledge it. In such settings — and this is the thread that runs through the entire book — intelligence is no longer the property of any individual agent alone, but of the interactions between them, where it shows up just as often as a conspicuous absence.

None of which makes plurality free. A second agent is a second thing to be wrong, to drift out of sync, to bill you for tokens, and to blame the first agent when the deliverable fails to appear. Multiplying agents can buy specialisation, parallelism, modularity, fault isolation, and a genuinely useful diversity of opinion; it can equally buy duplicated work, contradictory state, ballooning latency, and the particular managerial comedy of an organisation in which everyone is quite certain that someone else was responsible. The decision to deploy many agents is therefore an engineering decision, with costs to be weighed against benefits — not a declaration of architectural sophistication.

To keep that trade-off concrete, we will follow one example throughout the book. Picture a small team of LLM agents that ships software: an orchestrator receives a task — a bug report, a feature request, a failing test — and breaks it down; one or more coder agents write the changes; a reviewer checks them against the project’s standards; and a tester tries to break them. The four work over a real code repository and share a single, finite budget of tokens and time. We will call this the software-engineering team; it recurs in every chapter that follows, and we look at it more closely in Section 1.4.

This chapter lays the groundwork for making that decision well. We begin by characterising the problems that genuinely cannot be understood at the level of a single agent. We then fix what we will mean, throughout the book, by an agent and by a multi-agent system — and, just as importantly, distinguish the genuine article from the crowd of impressive look-alikes with which it is perpetually confused: distributed systems, microservices, ensembles, mixtures of experts, and workflows. We look more closely at that example, and weigh what plurality buys against what it costs. We close with a practical decision framework: a short sequence of questions whose purpose, more often than not, is to talk you out of building a multi-agent system, and to ensure that when you do build one, it is because the problem left you no honest alternative.

1.1 When One Agent Is Not Enough

What makes a problem genuinely multi-agent is not the number of moving parts, nor the fashionableness of the resulting architecture, but a small set of structural marks that no amount of single-agent cleverness can wish away — the four this chapter opened by sketching, now taken one at a time. A problem is inherently multi-agent when its knowledge is distributed, its objectives diverge, its control is decentralised and concurrent, and its resources are contested; and when, in consequence, the competence to solve it comes to reside in how the participants interact rather than in any one of them. They are not mutually exclusive: the interesting problems exhibit several at once, and the running example of this book, the software-engineering team, exhibits all of them. None of this is new with the language model. The field of distributed artificial intelligence organised itself around precisely these concerns in the 1980s (Bond & Gasser, 1988), decades before there existed anything as obliging as a general-purpose agent to instantiate them with. Indeed, most of what contemporary practice has built already has a name in that older literature, and a good part of this book’s work is the introductions. Table 1.1 previews the correspondences at a glance; each is unpacked — and qualified — in the chapter listed beside it.

Table 1.1: The Rosetta Stone, condensed. The pairings are kinships, not identities: in every case part of the classical idea transfers and part does not, and the chapter concerned is careful about which. The full glossary — old terms to new and back — is Appendix D.
The Classical Idea Its Contemporary Shape The Bridge
Speech Acts, KQML, and FIPA-ACL Tool Schemas and the MCP/A2A Protocol Stack Chapter 8, Chapter 22
Belief–Desire–Intention Architectures The Agent Loop: Model + Harness Chapter 4
Practical Reasoning; Means–Ends Analysis Planning, Task Decomposition, Reflection Chapter 5
The Blackboard Architecture Shared Context and Common State Chapter 9
Joint Intentions and Commitments Planner–Executor and Supervisor–Worker Teams Chapter 10
The Contract Net Protocol The Orchestrator Delegating to Workers Chapter 10
Voting and Social Choice Ensembles, Self-Consistency, Judge Models Chapter 13
Computational Argumentation Multi-Agent Debate and Critic Loops Chapter 14
Auctions and Mechanism Design Allocating Work, Compute, and Tokens Chapter 15
Norms, Institutions, and Reputation Guardrails, Governance, and Trust Chapter 16

1.1.1 Distributed Knowledge

The first mark is that no single participant sees the whole. The knowledge a problem requires is partitioned — by access rights, by physical locality, by privacy, by timing, or by sheer volume — across parties who cannot, or will not, consolidate it into one omniscient view. The classical term of art is partial observability: each agent must act on a local and incomplete picture of a world it cannot fully see.

The contemporary temptation is to deny the mark altogether — to gather everything into one enormous prompt and let a single capable model sort it out. Sometimes this works, and when it does you should take the win and read no further. But the strategy founders on the same rocks that sank the dream of the paperless office. The everything is frequently larger than any context window; it goes stale faster than you can copy it; and some of it belongs to parties — other teams, other companies, other jurisdictions — who would much prefer that you did not. In our running example the knowledge is distributed by construction: the reviewer agent knows the coding standards and the defect it is presently staring at; the coder that wrote the offending function knows why it had seemed reasonable an hour ago; the orchestrator knows the shape of the overall task but not the contents of any particular file until someone tells it. No participant holds the union, and assembling that union on demand — rather than assuming it — turns out to be a substantial part of the engineering.

1.1.2 Divergent Objectives

The second mark is that the objectives in play are only partly aligned. Agents range from the fully cooperative, through the cooperative-when-it-suits-them, to the frankly self-interested; and even a nominally united team harbours local objectives that pull against the global one.

This is easiest to see where the misalignment is deliberate. Within the team, the coder is prompted, trained, and tacitly incentivised to produce code that looks finished; the reviewer to find fault with it; the tester to break it outright. Their goals are set in opposition on purpose — the friction is the very mechanism by which the system catches its own mistakes — but it means the team cannot honestly be modelled as a single utility-maximiser with one coherent preference. The moment objectives genuinely diverge, you have crossed a quiet border out of engineering and into economics, where the relevant tools are those of game theory, negotiation, and mechanism design, and where the central question is no longer “what should the system do?” but “what is each participant incentivised to do, and does that add up to what we wanted?” Those tools are the business of Part IV; for now the structural point suffices. A problem with truly divergent objectives cannot be folded into a single agent without silently deciding whose objective prevails — which is less a solution than a coup.

1.1.3 Concurrency and Decentralised Control

The third mark is that decisions are taken at the same time, by parties answering to no central authority. There is no single thread of control to step through, and no instant at which the whole system holds still to be inspected. The absence of a global controller is rarely an oversight; it is usually the entire point, demanded by autonomy, scale, fault tolerance, or the simple fact that no one party holds the authority to command the rest.

The classical literature on concurrency and asynchrony — systems with no shared clock, in which messages arrive late, out of order, or not at all — supplies the vocabulary, and the contemporary agent system inherits every one of its hazards. In our running example, while the reviewer is reading version N of a file, a coder has already produced version N+1, and the tester is dutifully running against a version that no longer exists. Decentralised control is not merely inconvenient, however; it is provably, and steeply, expensive. For even two cooperating agents that cannot freely share what they observe, computing an optimal joint policy — a finite-horizon decentralised POMDP — is NEXP-complete (Bernstein et al., 2002), comfortably, and discouragingly, above the PSPACE-complete single-agent case, with the infinite-horizon version undecidable outright. Splitting one locus of control into several is therefore not a linear increase in difficulty but a jump in kind: the universe levies a heavy tariff at the border between one decision-maker and two, and charges it whether or not the two are on the same side.

1.1.4 Contested Resources

The fourth mark is that resources are finite and fought over. Compute, money, memory, attention, bandwidth, and — the currency of our running example — tokens: each is shared, each is scarce, and each invites overuse. The canonical statement of the hazard is Hardin’s tragedy of the commons (1968), in which every actor, behaving entirely rationally on its own account, overgrazes a shared pasture into collective ruin. The pattern transfers without modification to a collection of agents sharing a token budget, a rate limit, or a pool of database connections: left to their own devices, each will cheerfully consume the lot, and the system as a whole will grind to a halt, having achieved nothing in particular at considerable expense.

Here the marks converge on exactly this point. The coders, the reviewer, and the tester all draw on one bounded budget; an agent that spends without restraint does not merely overrun its own allowance but starves its colleagues of theirs. Some mechanism is therefore required to allocate the scarce resource — a budget, a priority scheme, an internal market — which is precisely where the cooperative mission of the team acquires a genuinely competitive interior. Shared resources can be governed rather than squandered; how to govern them, with auctions, prices, and incentive-compatible mechanisms, is a question we take up when we reach markets and mechanism design. For now it is enough that contention over a finite resource is, by itself, sufficient to make a problem multi-agent.

1.1.5 Intelligence in the Interactions

Taken together, the four marks license a single, and initially counter-intuitive, conclusion: when a problem bears them, the competence required to solve it cannot be located in any individual participant, because it does not reside there. It resides in the structure of their interaction — in who knows what, who talks to whom, who decides what, and who may overrule whom.

This inverts the folk intuition that intelligence is a possession, a quantity an individual has more or less of. The inversion is not new: Minsky’s Society of Mind (1986) famously portrayed a single mind as a society of mindless components, its intelligence an emergent property of their organisation rather than a faculty seated anywhere in particular. Minsky’s agents were sub-personal pieces within one head, and ours are autonomous agents distributed across a system, but the moral survives the change of scale: capability can be a property of organisation rather than of any of the parts. The wager of this book is that, in the multi-agent setting, this is not a suggestive metaphor but a literal engineering reality. The interaction structure — the protocols, the topology, the allocation of authority — is the primary object of design, and it determines whether a system of capable agents behaves capably far more often than the capability of any single agent does. It is also why so much of what follows concerns communication, coordination, and collective decision-making: those are not peripheral plumbing but the very place where the intelligence of a multi-agent system, or its absence, actually lives.

1.2 What We Mean by “Agent” and “Multi-Agent System”

Two terms have been doing a great deal of unexamined work in this chapter, and it is time to pay them the courtesy of a definition. Unfortunately, agent is among the most over-loaded words in computing: it has been applied, with a straight face, to thermostats, web crawlers, chess programs, automated holiday-booking systems and — lately — more or less anything with a language model inside it. Three decades ago Franklin and Graesser surveyed the wreckage and asked, plaintively, whether a given program was an agent at all or merely a program with ideas above its station (1997); the question has not grown any easier for the intervening explosion of things calling themselves agents. We will not attempt to adjudicate every contested definition — a task with no terminating condition — and instead fix working notions precise enough to build on and stable enough to outlast the current vocabulary.

1.2.1 What Makes Something an Agent

The most durable definition is also the most modest. In the framing that a generation of artificial-intelligence students has absorbed from Russell and Norvig (2021), an agent is anything that perceives its environment through sensors and acts upon that environment through actuators, in pursuit of some objective. The definition is deliberately catholic — it admits the thermostat — but its shape is what matters: an agent is situated, coupled to an environment in a loop — sensing and acting over time, rather than computing an answer once and halting.

What turns this minimal loop into something worth the name is a cluster of properties catalogued by Wooldridge and Jennings in their canonical account of agency (1995): autonomy — the agent acts without step-by-step external instruction, retaining its own locus of control; reactivity — it responds to a changing environment; pro-activeness — it takes the initiative in pursuit of goals rather than merely reacting; and social ability — it interacts with other agents. Of these, autonomy is load-bearing. A component that does only and exactly what it is told, precisely when it is told, is a function call wearing a lanyard; an agent is trusted to decide how, and sometimes whether, to pursue an end it has been handed.

It is worth being clear, early and in bold, about where the language model fits, because the contemporary habit of using agent and LLM interchangeably is the source of a great deal of muddled design. The model is a component of the agent, not a synonym for it. A language model, on its own, is a remarkably capable function from text to text: it has no memory between calls, no goals, no means of acting upon the world, and no loop. An agent is what you get when you wrap such a model in the missing parts — a persistent state, a set of tools through which it can act, and a control loop that carries it from perception to action and back again. The model supplies the deliberation; the agent supplies the agency. That decomposition — a language model serving as the brain, augmented with planning, memory and the use of tools — received an early and influential statement in a widely-read essay by Weng (2023), and some version of it underlies most contemporary agent frameworks. What the model does and does not provide is the business of Chapter 3, and the anatomy of the wrapper occupies the whole of Part II; for now it is enough to insist on the distinction.

1.2.2 What Makes a System Multi-Agent

A multi-agent system is, to a first approximation, several agents in one another’s company. But the approximation needs two refinements before it is of any use. The first is that the agents must interact: a dozen agents labouring in complete isolation, never exchanging information nor affecting one another’s environment, are merely a dozen agents, in the way that a dozen strangers reading on a train are not thereby a society. Interaction — communication, cooperation, competition, interference — is what makes the plural noun earn its keep. The second is that no single agent may hold complete authority over the conduct of the rest. Where one controller dictates every move of a set of obedient subordinates, reserving all the decisions for itself, what you have is one agent and some marionettes, however many language models are nominally involved. This is the substance behind the unkind observation that a good deal of what is marketed as multi-agent is really several prompts in a trench coat, doing an impression of a system.

The standard treatments draw the boundary in just this way: a multi-agent system is a collection of autonomous agents, each with a partial view and its own locus of control, that interact within a shared environment (Shoham & Leyton-Brown, 2009; Wooldridge, 2009). Note what this does not demand. It does not demand that the agents be equals: hierarchies, with managers and workers, make perfectly good multi-agent systems, provided the workers retain genuine local discretion rather than merely relaying a superior’s instructions. Nor does it demand that they cooperate; adversaries in a marketplace are as much a multi-agent system as collaborators on a team. Our running example sits comfortably inside the definition. The orchestrator, coders, reviewer and tester each run their own loop, perceive their own slice of the repository, and decide locally how to proceed; they interact through the code, the reviews and the shared budget; and although the orchestrator enjoys a measure of authority, it does not — and, given the marks of Section 1.1, cannot — take every decision on the others’ behalf. It is, in the full sense the rest of this book will hold it to, a system of agents.

1.3 What a Multi-Agent System Is Not

It is often easier to say what a thing is by saying what it is not, and the multi-agent system is surrounded by an unusually crowded field of near-relations, several of which are forever being mistaken for it — on occasion by their own designers. Each of the five neighbours below conspicuously lacks at least one of the defining features from Section 1.2 — some lack all three; the differentiator, in every case, is the combination of autonomy, local decision-making, and interaction. A system with all three is a multi-agent system; a system with only some is one of the look-alikes, and calling it by the wrong name leads, with great reliability, to building the wrong thing. Table 1.2 summarises the distinctions; the subsections give the reasoning.

1.3.1 Distributed and Concurrent Systems

A distributed system spreads computation across multiple networked machines that coordinate by passing messages, precisely because they share neither memory nor a global clock (Tanenbaum & van Steen, 2023). It has in common with the multi-agent system the entire grim bestiary of Section 1.1 — physical distribution, concurrency, partial information, and partial failure — and the two share a great deal of hard-won engineering wisdom as a result. What the distributed system lacks is autonomy in the strong sense. The nodes of a distributed database execute; they do not deliberate. They run a protocol they did not choose, towards an outcome about which they hold no opinion, and a node that began pursuing goals of its own would be regarded not as clever but as faulty. The boundary does blur at the edges — the actor model, in which concurrent “actors” encapsulate private state and communicate only by messages, is a recognisable ancestor of agent-based thinking — but the rule of thumb is reliable: if the components decide what to pursue and how, you have agents; if they faithfully execute a protocol, you have a distributed system, and you should be grateful, because it will be far easier to reason about.

1.3.2 Service-Oriented Architectures and Microservices

Closer to the agent, and more often confused with it, is the service — the unit of a service-oriented architecture or, in its modern fine-grained form, the microservice (Newman, 2021). A microservice owns its data, hides its internals behind a well-defined interface, is independently deployable, and is described, in that literature, with the word used advisedly, as autonomous. The resemblance is real, and the temptation to equate the two is understandable. But the autonomy of a microservice is organisational, not behavioural: it is free to change how it works without consulting its callers, yet it does not choose its goals, take the initiative, or decline a well-formed request because it is busy pursuing something it deems more important. A service answers; an agent acts. The border is exactly the point at which a service is permitted to say “no”, to negotiate the terms of a request, or to do something nobody asked for because its own objectives suggested it — at which moment the microservice has quietly become an agent, and the comfortable guarantees of request-and-response have left with it.

1.3.3 Ensembles

From software architecture we cross into machine learning, where two further look-alikes wait. The first is the ensemble: a collection of models whose individual predictions are combined — by voting, averaging, or a learned rule — into a single output that is usually better than any one member’s (Dietterich, 2000). In an age of language models it is tempting to watch a panel of models cross-checking one another and call it a society of agents. But the classical ensemble is not a society; it is a statistical device. Its members do not interact, do not perceive one another, and do not adjust their behaviour in light of what the others are doing: they are run independently, and their outputs are reconciled by a fixed rule imposed from outside. This is not to say the ensemble has nothing to teach the multi-agent designer. On the contrary — the moment several agents vote on an answer, they inherit, whether they realise it or not, the whole apparatus of social choice, impossibility results and all, which we take up in Part IV. But aggregation is not interaction, and a fixed voting rule is not a coordination protocol.

1.3.4 Mixtures of Experts

The second machine-learning look-alike is the mixture of experts, in which a set of specialised sub-models — the “experts” — is governed by a gating network that routes each input to whichever expert or experts suit it best. The idea dates to Jacobs, Jordan, Nowlan, and Hinton (1991) and has returned to prominence as the sparsely-gated layer that lets a single enormous language model activate only a fraction of its parameters for any given token (Shazeer et al., 2017). The vocabulary is positively agent-like — experts, routing, gating — and the confusion is correspondingly common. But a mixture of experts is one model with internal structure, not a system of agents. The experts do not act in the world, hold goals, or speak to one another; the gating is learned, differentiable, and wholly internal; and the entire assembly is trained end-to-end as a single object. Routing inside a model and delegation among autonomous agents are the same metaphor stretched over very different machinery, and the difference is precisely the autonomy and interaction that Section 1.2 requires.

1.3.5 Workflows and Pipelines

The last look-alike is the most important in practice, because it is the one most often built when a multi-agent system was neither needed nor wise. A workflow — equivalently, a pipeline — is a fixed sequence of steps whose control flow is decided in advance, by the developer, and baked into code. The contrast with the agent is by now standard in the practitioner literature: a workflow is a system in which models and tools are orchestrated along predefined paths, whereas an agent is one in which the model dynamically directs its own process (Schluntz & Zhang, 2024). A workflow may well have a language model at every step; what it does not have is any component that decides, at run time, what the next step should be. This is frequently a virtue rather than a limitation. A fixed pipeline is easier to test, cheaper to run, simpler to debug, and far less inclined to surprise you; determinism is a feature, and a great deal of what is breathlessly marketed as “agentic” would be more reliable, and no less capable, rewritten as a workflow. The genuine multi-agent system earns its keep only where the control flow cannot be fixed in advance — where the next step turns on judgements that can only be made as the work unfolds. We return to that distinction, with a decision procedure attached, in Section 1.6.

Table 1.2: The multi-agent system and its look-alikes. Only the multi-agent system exhibits all three defining features at once; each neighbour is told apart by what it lacks — a single feature for some, all three for the ensemble and the mixture of experts.
System Autonomous components Interaction Decentralised control
Distributed / concurrent system ✗ ✓ ✓
Service-oriented / microservices ✗ ✓ ✓
Ensemble ✗ ✗ ✗
Mixture of experts ✗ ✗ ✗
Workflow / pipeline ✗ ✓ ✗
Multi-agent system ✓ ✓ ✓

1.4 The Running Example, Up Close

We met the software-engineering team in this chapter’s opening, and have leaned on it ever since to make the marks of Section 1.1 concrete. It is time to look at it directly.

The example is not a thought experiment. Systems of very nearly this shape already exist and are studied: ChatDev and MetaGPT assemble role-playing software teams — chief executives, architects, engineers, reviewers — and march them through a development process (Hong et al., 2024; Qian et al., 2024), while benchmarks such as SWE-bench measure, unsentimentally, whether agents of this kind can resolve thousands of genuine GitHub issues drawn from real projects (Jimenez et al., 2024). The orchestrator-and-workers arrangement in particular is the workhorse topology of contemporary practice; Anthropic’s account of its own multi-agent research system describes exactly this lead-agent-delegating-to-subagents pattern, and reports, with disarming candour, that it consumed many times the tokens of an ordinary chat session for its trouble (2025). We will have a great deal to say, later, about whether that trade is worth making.

What recommends this team for our purposes is that it is genuinely multi-agent. The preceding sections leaned on it to illustrate each mark of Section 1.1 in turn — knowledge distributed across the reviewer, coder, and tester; objectives deliberately set in opposition; control decentralised across agents acting in parallel against a repository that will not hold still; a single budget contested by all of them — so we may simply record the verdict: it bears all four marks at once. A verdict about the system, note, not yet about the problem: two of the marks are partly of our own making — the knowledge is distributed because we split the context; the objectives diverge because we set them in opposition — and the sceptic who suspects that a single capable agent, handed the whole repository and the whole budget, might have served is asking exactly the right question. It is the question Section 1.6 closes this chapter with, and the one Chapter 24 will eventually put to instruments, running the team against a strong single agent and a fixed workflow and believing nothing it cannot measure. What can be said in advance is that the marks stiffen as the task grows: the repository outgrows any one context, a reviewer who shares the coder’s blind spots stops catching what matters, and the budget is contested however the roles are drawn. The team enters the book, then, not as a foregone conclusion but as its standing candidate — an architecture that must earn, on evidence, the plurality it was given by design.

It also displays a duality that recurs throughout the book, and that is the reason this particular example was chosen as the spine rather than something tidier. At the level of its mission the team is cooperative: everyone wants the change shipped and the tests green. At the level of its resources it is competitive: the shared token budget is a commons, and the agents are rivals for it. A great many of the book’s central problems — how to allocate scarce compute, how to keep a shared view consistent, how to make a reviewer’s veto stick, how to tell whether the team did any better than one agent would have — live in the tension between those two levels. We will not so much resolve that tension as learn to engineer with it.

A final caution, because the example invites a particular kind of self-deception. Giving four agents the titles “Chief Executive”, “Architect”, “Developer” and “Reviewer” does not, in itself, produce an organisation. Job titles are not coordination mechanisms; a role is only as real as the information it is given, the decisions it is permitted to take, and the consequences it must answer for. Much of what follows is concerned with supplying that substance — with the difference between a team and a group of language models wearing lanyards. The software-engineering team will be our standing test of that difference.

1.5 What Plurality Buys, and What It Costs

That a problem can take a multi-agent solution does not settle whether you should build one, because plurality is never free. Adding agents to a system is a trade, and like all trades it is worth making only when what you gain exceeds what you give up. This section sets out both sides of the ledger plainly; Section 1.6 turns them into a decision.

1.5.1 The Benefits

What can additional agents buy? Five things, mainly.

Specialisation. A single agent asked to do everything must hold every instruction, tool, and standard in one context at once; dividing the work lets each agent carry a smaller, sharper brief — a reviewer that thinks only about code quality, a tester that thinks only about breaking things. Specialisation is partly a matter of prompt hygiene: a focused agent is easier to instruct, easier to evaluate, and less easily distracted by the parts of the task that are not its concern.

Parallelism. Independent sub-tasks can proceed at the same time. When a question has six facets, six subagents can pursue them at once rather than one agent plodding through them in series; Anthropic reports that exactly this parallel, orchestrator-led decomposition beat a strong single agent by a wide margin on research tasks (2025) — at a cost we come to shortly.

Modularity and fault isolation. Agents with clean interfaces can be developed, tested, replaced, and reasoned about separately — the same argument that recommends modular software in general. And a well-drawn boundary contains damage: an agent that fails, loops, or is compromised can, if the system is designed for it, be retried or quarantined without bringing down the whole.

Diversity. Several agents approaching a problem differently — different prompts, different models, different vantage points — can catch one another’s errors and surface options that a single line of reasoning would miss. This is the intuition behind multi-agent debate and critic–actor schemes, and there is some evidence that making models argue improves their factual accuracy and reasoning (Du et al., 2024). It is also, we should say at once, an intuition that does not always survive contact with the data; whether argument genuinely makes agents cleverer or merely more verbose is a question we examine, with some scepticism, in Part IV.

1.5.2 The Costs

Against those benefits stands a ledger of costs that is easy to underestimate, not least because most of it stays hidden until the system is running in earnest.

Cost and latency. Every agent is a model call, and model calls cost money and time. A multi-agent system does not merely add these up; it multiplies them, through repeated context, redundant reasoning, and rounds of coordination. Anthropic’s research system consumed roughly fifteen times the tokens of a single chat exchange (2025) — a price that can be worth paying, but only if you know that you are paying it.

Duplicated and inconsistent work. Agents that cannot see what their colleagues are doing duplicate effort and contradict one another. Worse, they act on a shared state that has quietly diverged: two coders editing the same file under different assumptions, a reviewer approving a version the tester has already invalidated. Keeping a distributed view consistent is among the oldest and hardest problems in computing, and the practitioner literature is increasingly blunt about it — one widely-read argument against multi-agent designs holds that fragile, divergent context is reason enough to prefer a single agent wherever one will do (Yan, 2025).

Failure modes all of their own. Systems of agents fail in ways individual agents do not. A recent empirical study of popular multi-agent frameworks catalogued fourteen distinct failure modes — spanning unclear specification, misalignment between agents, and inadequate verification — and found them rife across more than two hundred tasks (Cemri et al., 2025). Many had little to do with the underlying model’s capability and everything to do with the organisation around it: agents talking past one another, dropping responsibilities each assumed the other had, or agreeing prematurely on a wrong answer.

Diffused responsibility. When a single agent fails, you know whom to interrogate. When a committee fails, the post-mortem is a circular firing squad of plausible explanations, each agent’s contribution tangled with the others’. This is not merely an operational nuisance; it is, as Section 1.3 hinted and Part VII will argue at length, a genuine obstacle to accountability, and it grows with every agent added.

A committee of language models is still a committee. It can deliberate, divide labour, and check its members’ work; it can also dither, duplicate, and produce confident minutes of a meeting that decided nothing. The question is never whether plurality has costs — it does — but whether, for the problem in front of you, the benefits are worth them. It is to that question that we now turn.

1.5.3 The Trade, Priced*

First, though, the ledger’s two sides can meet in a line of arithmetic — an Amdahl’s law for agents, after the classical argument that a parallel computer is only as fast as its stubbornly serial part. Suppose the task takes one agent a time T_1, and that a fraction p \in [0,1] of the work can genuinely proceed in parallel — six facets pursued at once — while the remaining (1 - p) is sequential, each step waiting on the last. Sharing the parallel portion among n agents shrinks it to p/n; but agents, unlike processor cores, must also keep one another informed, and the keeping levies a coordination tax c(n), paid in tokens and latency, so that n agents finish in roughly

T(n) \;\approx\; T_1\left[(1 - p) + \frac{p}{n}\right] + c(n),

where the tax is the term to watch, because it grows with the wiring rather than the work: if every pair must talk — who knows what, who talks to whom — then c(n) grows like the pair count \binom{n}{2}, quadratically; Section 11.6 weighs topologies by how much of that wiring they prune. The speedup S(n) = T_1 / T(n) therefore rises only while each new agent removes more waiting than its conversation adds, and not for ever: the parallel gain is bounded — infinitely many agents still leave the sequential (1 - p) standing — while the tax is not, so S(n) peaks at a finite n^{*}, the team size beyond which every additional colleague makes the system slower as well as dearer.

The model is cheap to interrogate. Price the tax at \kappa per talking pair, so that c(n) = \kappa\, n(n-1)/2, normalise T_1 to 1, and a few lines suffice to locate n^{*}:

def speedup(n: int, p: float, kappa: float) -> float:
    c = kappa * n * (n - 1) / 2       # the coordination tax
    return 1 / ((1 - p) + p / n + c)  # T1 normalised to 1

max(range(1, 101), key=lambda n: speedup(n, p=0.9, kappa=0.002))  # -> 8
round(speedup(8, p=0.9, kappa=0.002), 2)                          # -> 3.72

A task that is nine-tenths parallelisable, taxed at \kappa = 0.002, peaks at eight agents — and even the peak buys less than a four-fold speedup, comfortably short of the ten-fold ceiling 1/(1 - p) it would enjoy were the talking free. Edit the two numbers and n^{*} moves with them.

Speed-up versus number of agents: a tax-free curve rising to the ceiling, and taxed curves peaking at a finite optimum, with the worked-example optimum marked at eight agents.
Figure 1.1: Speed-up against team size. The tax-free curve merely climbs to Amdahl’s ceiling; once coordination is priced, each curve turns over at an interior optimum n^{*}, beyond which another agent makes the team slower as well as dearer.

None of this is a law. It is a model — the simplest that exhibits the trade — whose parameters are facts about your task, not constants of nature: p is how decomposable the work truly is, c(n) is how much the agents must say to stay consistent, and neither can be read off an architecture diagram. It also prices only time and tokens; specialisation, diversity, and the quality of what ships lie outside it. What it buys is a sharper question — not “would more agents be impressive?” but “where does this system’s n^{*} sit?” — and Chapter 24 supplies the instruments for finding out.

1.6 Should You Build One at All? A Decision Framework

We can now answer the question with which the chapter began. The governing principle is parsimony: prefer the simplest architecture that solves the problem, and add autonomy only where the problem genuinely requires it, rather than scattering it decoratively across the application. The framework below is a sequence of escalating questions, and its bias is deliberate — at every step it tries to stop you before you reach for more machinery than you need. The single most reliable predictor that a multi-agent system will disappoint is that it was built before anyone checked whether a simpler thing would do.

1.6.1 First, Try a Single Agent

Begin by assuming you need exactly one agent, and try to talk yourself out of more. A single capable model, given the right tools and the right context, can accomplish a remarkable range of tasks that a casual observer would assume required a team — and it does so as one locus of control, with one state to keep consistent and one place to look when something goes wrong. The practitioner consensus, hard-won and increasingly emphatic, is to start here and to stay here as long as you can (Schluntz & Zhang, 2024; Yan, 2025): a single well-instructed agent is easier to test, cheaper to run, simpler to debug, and far less inclined to develop opinions about its own remit. If one agent with good tools can do the job, the discussion is over; build that, and read the rest of this book for pleasure rather than instruction.

1.6.2 Then, Try a Fixed Workflow

If a single agent genuinely cannot do the job — the task has distinct stages, or wants different tools and prompts at different points — the next question is not “how many agents?” but “do I know the steps in advance?” Where the control flow is fixed and knowable, a deterministic workflow (Section 1.3) beats a multi-agent system on nearly every axis that matters, for the reasons rehearsed there. Reach past the workflow only when the sequence of steps genuinely cannot be fixed ahead of time — when what to do next depends on judgements that can only be made as the work unfolds.

1.6.3 When Multi-Agency Earns Its Keep

That is the threshold. A genuine multi-agent system earns its keep precisely when the problem resists both of the simpler forms — when it bears the marks of Section 1.1 in a way that no single locus of control can absorb. Knowledge may be irreducibly distributed across parties who cannot pool it; objectives may genuinely diverge, so that no single utility function honestly represents them; control may have to be decentralised and concurrent, with no global thread to serialise it; resources may be contested in a way that demands real allocation. Where one or more of these holds, and the control flow cannot be fixed, autonomy and interaction stop being indulgences and become the only faithful model of the problem. Even then the decision is not automatic: the benefits of plurality must, for this specific problem, outweigh its costs (Section 1.5). Multi-agency is the right answer more often than the sceptics of the previous section might suggest — but a great deal less often than it is the answer actually chosen.

1.6.4 A Checklist

The whole framework collapses to five questions, applied in order. The first “yes” that lets you stop is your answer.

%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}}}%%
flowchart TD
    Q1(["1 · One agent enough?"])
    Q1 -->|"yes"| A1["Build a single agent"]
    Q1 -->|"no"| Q2(["2 · Steps knowable in advance?"])
    Q2 -->|"yes"| A2["Build a deterministic<br/>workflow"]
    Q2 -->|"no"| Q3(["3 · Inherently multi-agent?"])
    Q3 -->|"no"| A3["Clarify the<br/>specification first"]
    Q3 -->|"yes"| Q4(["4 · Benefits outweigh costs?"])
    Q4 -->|"no"| A4["Accept the simpler design"]
    Q4 -->|"yes"| A5["Build the multi-agent system:<br/>observability, consistency, accountability"]
    classDef gate fill:#F7E6B5,stroke:#8A5A00,color:#16171B
    classDef exit fill:#DCEFE2,stroke:#1B6B5A,color:#16171B
    class Q1,Q2,Q3,Q4 gate
    class A1,A2,A3,A4 exit
Figure 1.2: The decision framework drawn as a descending ladder of off-ramps, its gates numbered as in the checklist below. Every gate is an attempt to send you home early; only a problem that is irreducibly structured, unfixable in advance, and worth the expense survives all four to reach the multi-agent box at the bottom.
TipThe decision in five questions
  1. Can a single agent, given the right tools and context, do the job? If yes, build that. Stop.
  2. If not, are the steps knowable in advance? If yes, build a deterministic workflow. Stop.
  3. If the control flow cannot be fixed, does the problem truly bear the marks of an inherently multi-agent one — distributed knowledge, divergent objectives, decentralised and concurrent control, contested resources (Section 1.1)? If not, you are probably reaching for agents to paper over an unclear specification; clarify it first.
  4. If it does, do the benefits of plurality outweigh its costs for this problem (Section 1.5)? If not, accept the simpler design and its limits.
  5. If they do, build the multi-agent system — and design it from the outset for observability, consistency, and accountability, because you are going to need all three.

If you reach the fifth question and answer it honestly, you are no longer building a multi-agent system because it is impressive, or because the architecture diagram seemed to demand it, or because a single agent once failed and several might fail more interestingly. You are building one because the problem left you no honest alternative — which is the only good reason there has ever been. The rest of this book is about doing it well.

1.7 Summary

  • More than one agent is a means, never a merit. The case for a multi-agent system rests on the structure of the problem, not on the failure of a single agent or the visual appeal of a busier architecture diagram.
  • Some problems are inherently distributed. Their marks are distributed knowledge, partly divergent objectives, concurrency and decentralised control, and contested resources. Where these are present, no single agent — however capable — can stand in for the collective.
  • Intelligence can live in the interactions. In a genuinely distributed problem, competence is a property of how the agents interact, not only of what each can do alone.
  • An agent is autonomous, situated, and goal-directed; a system is multi-agent when several such agents interact with no one of them in sole control. The language model is a component of an agent, not a synonym for one.
  • The genuine article has many look-alikes. Distributed systems, microservices, ensembles, mixtures of experts, and workflows each capture part of the picture and miss the rest; the differentiator is autonomy together with local decision-making and interaction.
  • Plurality is a trade. It can buy specialisation, parallelism, modularity, fault isolation, and diversity; it can equally cost duplicated work, inconsistent state, latency, money, and diffused responsibility.
  • Default to the simplest thing that works. Prefer a single agent, then a fixed workflow, and reserve genuine multi-agency for problems that leave no honest alternative — and when you do build one, keep the minutes, because observability and accountability are not optional extras.

1.8 Exercises

Several of the exercises below price teams with the model of Section 1.5: a task takes a single agent a time T_1, normalised to one, of which a fraction p can proceed in parallel, so that n agents finish in T(n) = (1 - p) + p/n + c(n) for a coordination tax c(n); the speedup is S(n) = T_1/T(n), and n^{*} is the team size at which it peaks. Unless an exercise says otherwise, the tax is the fully connected one, c(n) = \kappa\, n(n-1)/2, at a price \kappa per talking pair.

Exercise 1. A documentation overhaul is three-fifths parallelisable (p = 0.6), and the team that would take it on coordinates at \kappa = 0.01. (a) Compute T(2) and T(4) and the corresponding speedups. (b) Locate n^{*} by evaluating S(n) up to n = 6, and show — by comparing what the step from n to n + 1 saves in waiting with what it adds in tax — that no larger team needs checking. (c) What fraction of the tax-free ceiling 1/(1 - p) does the best team actually collect?

Exercise 2. Four candidates for the title of agent: (i) a job that runs every night at 02:00, sends the day’s support tickets to a language model under a fixed prompt, and emails out whatever comes back; (ii) a continuous-integration bot that re-runs a failing test suite up to three times, rebases the branch when it detects a conflict, and abandons the build after a fixed timeout — every behaviour enumerated in its configuration file; (iii) an incident responder that watches production metrics, decides for itself whether a drift merits an incident, chooses which runbook to try, watches the effect, and escalates to a human after two failed attempts; (iv) the bare language-model endpoint that (iii) calls when it deliberates. (a) For each candidate, deliver a verdict — agent or not — resting on the specific properties of Section 1.2 that decide it, and note any case where the minimal definition and the stronger cluster of properties disagree. (b) State the smallest additions that would make genuine agents of (i) and (iv).

Exercise 3. (a) Show from the model that

T(n) - T(1) \;=\; \frac{(n - 1)\bigl(\kappa n^{2} - 2p\bigr)}{2n},

so that a team of n beats a single agent exactly when n < \sqrt{2p/\kappa}. (b) Deduce that a pair pays its way exactly when \kappa < p/2, and that if the pair does not pay, no larger team will. (c) A tightly coupled schema migration has p = 0.2 and \kappa = 0.15; a well-partitioned localisation job has p = 0.8 and \kappa = 0.1. For each, list every team size that beats a single agent, and say what happens at n = 4 on the localisation job. (d) Which question of the checklist in Section 1.6 has this inequality made quantitative — and for which currency alone?

Exercise 4. Treat n as continuous and approximate the tax by \kappa n^{2}/2. (a) Show that T(n) is minimised at n^{*} \approx (p/\kappa)^{1/3}, confirm that the stationary point is a minimum, and state the direction in which the approximation biases the estimate, and why. (b) A data-annotation task has p = 0.64 and \kappa = 0.001: estimate n^{*} from the law, then find it exactly (a few lines of Python, or patience), and check the law against the worked figures of Section 1.5. (c) An infrastructure team offers to halve \kappa. How many extra colleagues does that buy here? What cut in \kappa would doubling n^{*} require, and what does the cube root therefore say about the price of large teams?

Exercise 5. Wire the team as a star instead: every worker talks only to the orchestrator, so the tax falls on n - 1 links, c(n) = \kappa(n - 1). (a) Derive the continuous optimum n^{*} \approx \sqrt{p/\kappa}. (b) For a code-migration task with p = 0.85 and \kappa = 0.003, find the exact optimum and the peak speedup under both wirings — fully connected and star — and compare them. (c) The linear tax prices the links but not the hub: say what the star costs the orchestrator itself, and which of the four marks of Section 1.1 its context window thereby becomes an instance of. Section 11.6 takes the wiring question up properly.

Exercise 6. Time is one ledger; tokens are the other. Suppose every agent beyond the first must re-read a fraction \rho of the single agent’s context, so that the team’s token bill, in units of the single agent’s, is B(n) = 1 + \rho(n - 1), while T(n) keeps the fully connected tax with p = 0.8 and \kappa = 0.005. (a) Find the time-optimal n^{*}, and the speedup and the bill at that size for \rho = 0.5. (b) Define the cost-effectiveness E(n) = S(n)/B(n), locate its maximiser, and prove that in this model the cost-optimal team is never larger than the time-optimal one. (c) How large must \rho be before the single agent is the most cost-effective choice of all? (d) Section 1.5 reports a research system that consumed roughly fifteen times the tokens of a single chat. Taking that system as an orchestrator with three subagents (n = 4), what \rho would the replication model require — and what does the implausible answer tell you about where the tokens actually go?

Exercise 7. A vendor markets DocuSwarm, “a five-agent document-intelligence platform”: an intake agent classifies each incoming document, an extraction agent pulls out its fields, a compliance agent checks them against policy, a summary agent drafts an abstract, and a publishing agent files the result. The five run in that order on every document, each a single model call under a role prompt, and a scheduler moves the documents down the line; nothing may skip, reorder, or repeat a step. (a) Test the platform against the three features of Section 1.3, and give it its honest name and its row in Table 1.2. (b) Make the strongest case that this shape is right for this problem, in the terms of Section 1.6. (c) A new release lets the compliance agent send a document back to extraction with questions, at most twice, and lets the intake agent split a bundled file into sub-documents processed in parallel lanes. For each change, say which defining feature it adds, if any, and rule on whether the release crosses the line into a multi-agent system. (d) Specify the smallest further change that genuinely would cross it, and name the first cost from the ledger of Section 1.5 you would then have to budget for.

Exercise 8. Four briefs land on your desk. (i) “A regression test is failing on a 40,000-line repository that fits comfortably in a context window; find the fault and propose a patch for one engineer to review.” (ii) “Every night, for each of our forty repositories: pull the day’s commits, run the static analyser, draft release notes for each component, assemble the changelog, and post it — the same five steps, in the same order, every time.” (iii) “Churn is up; deploy an agent army to work out why users leave and fix it.” (iv) “Twelve subsidiaries, each barred by regulation from sharing its raw ledger with the others, must produce one consolidated quarterly risk report and agree the inter-company adjustments, each subsidiary having an incentive to shade those adjustments in its own favour.” For each brief, run the five questions of Section 1.6 in order, name the gate at which you stop, and justify in one sentence each gate you pass through. For the brief that survives to the fifth question, identify all four marks of Section 1.1 with evidence from the brief, and say which of them are facts of the problem rather than artefacts of a chosen design — the distinction Section 1.4 drew for the software-engineering team.

Exercise 9. You have timed a report-compilation task on your own infrastructure at several team sizes, in units of the single agent’s time: T(1) = 1.00, T(2) = 0.63, T(3) = 0.51, T(4) = 0.46, T(6) = 0.42, T(8) = 0.43. (a) Show that with T_1 normalised the model is linear in the pair (p, \kappa), namely T(n) = 1 - p(1 - 1/n) + \kappa\, n(n - 1)/2, so that fitting it is least squares rather than a search in the dark. (b) Estimate (p, \kappa) by hand from the n = 2 and n = 4 measurements alone. (c) Write a short standard-library program that fits (p, \kappa) to all six measurements by minimising the sum of squared errors over a grid, and report the fitted pair and the n^{*} it implies. (d) The estimates of (b) and (c) differ; does the implied n^{*}? Use the law of Exercise 4 to explain why n^{*} is the most forgiving quantity this model predicts.

Exercise 10 (lab). The parameters p and \kappa are facts about your task; this exercise measures them. Choose a small real task with visible facets — answering a six-part research question, say, or fixing three unrelated failing tests in a toy repository. (a) Run it with one live agent, and record the wall-clock time and the total tokens. (b) Run it with teams of two and of four — an orchestrator that partitions the facets and merges the answers — holding the model, the per-facet prompts, and the acceptance check fixed, and repeating every configuration at least three times, because single runs are noise; Chapter 24 develops the method properly. (c) Normalise the mean times by T(1), fit (p, \kappa) with the fitter of Exercise 9, and locate your task’s n^{*}. (d) Set the measured token totals against B(n) from Exercise 6: which grows faster, and why? Before spending money, dry-run the design against the scripted, no-network sweep in the companion repository (frontier/scaling_lab/, run as python -m frontier.scaling_lab.run), whose coupled and parallel regimes bracket what to expect; the full instrument — team sizes crossed with topologies — is the capstone lab of Chapter 27. Record the model identifier and the date beside your results.