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; the first thing to say is that “because we can” is not a reason.

The proper reason is structural: some problems are inherently distributed, and dropping a single, all-seeing agent into one is not so much solving the problem as declining to acknowledge it. In such settings — the thread running through the entire book — intelligence is no longer the property of any individual agent, but of the interactions between them. None of which makes plurality free. A second agent is a second thing to be wrong, to bill you for tokens, and to blame the first when the deliverable fails to appear; the decision to deploy many agents is an engineering decision, not a declaration of architectural sophistication.

To keep the trade-off concrete, we 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; Section 1.4 looks at it more closely.

The chapter fixes what agent and multi-agent system will mean, sorts the genuine article from its look-alikes, prices the trade, and distils a decision framework whose purpose, more often than not, is to talk you out of the build; it closes with why an elaborate theory of agents spent thirty years waiting for its missing part.

1.1 When One Agent Is Not Enough

What makes a problem genuinely multi-agent is not the number of moving parts but four structural marks no single-agent cleverness can wish away: knowledge distributed, objectives divergent, control decentralised and concurrent, resources contested — and, in consequence, a competence residing in the interactions rather than in any participant. The software-engineering team exhibits all four; so does the warehouse robot fleet that opens Chapter 8 — the marks belong to problems, not software. None of it is new with the language model: distributed artificial intelligence organised itself around these concerns in the 1980s (Bond & Gasser, 1988), and most of contemporary practice already has a name in that older literature; a good part of this book’s work is the introductions. Table 1.1 previews the correspondences, each unpacked — and qualified — in its chapter.

Table 1.1: The Rosetta Stone, condensed. The pairings are kinships, not identities — part of each 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 C.
The Classical Idea Its Contemporary Shape The Bridge
Speech Acts, KQML, and FIPA-ACL Tool Schemas and the MCP/A2A Protocol Stack Chapter 5, Chapter 19
Belief–Desire–Intention Architectures The Agent Loop: Model + Harness Chapter 3
Practical Reasoning; Means–Ends Analysis Planning, Task Decomposition, Reflection Section 3.7
The Blackboard Architecture Shared Context and Common State Chapter 6
Joint Intentions and Commitments Planner–Executor and Supervisor–Worker Teams Chapter 7
The Contract Net Protocol The Orchestrator Delegating to Workers Chapter 7
Voting and Social Choice Ensembles, Self-Consistency, Judge Models Chapter 10
Computational Argumentation Multi-Agent Debate and Critic Loops Chapter 11
Auctions and Mechanism Design Allocating Work, Compute, and Tokens Chapter 12
Norms, Institutions, and Reputation Guardrails, Governance, and Trust Chapter 13
Verification and Model Checking Replay Suites, Runtime Monitors, and Guardrails Chapter 20
Adjustable Autonomy; Mixed-Initiative Interaction Human-in-the-Loop Approvals and Interrupts Chapter 22

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, privacy, timing, or sheer volume — across parties who cannot, or will not, consolidate it; the classical term is partial observability: each agent acts on a local, incomplete picture. The contemporary temptation is to deny the mark — gather everything into one enormous prompt and let a single capable model sort it out. Sometimes this works — take the win and read no further; but the everything is frequently larger than any context window, goes stale faster than you can copy it, and partly belongs to parties who would much prefer that you did not — the rocks that sank the single enterprise data warehouse. In the running example the knowledge is distributed by construction — the reviewer knows the standards, the coder knows why the function seemed reasonable an hour ago, the orchestrator knows the task but not the files — and assembling the union on demand is a substantial part of the engineering.

1.1.2 Divergent Objectives

The second mark is that the objectives in play are only partly aligned — even a nominally united team harbours local objectives that pull against the global one. Within the team the misalignment is deliberate — the coder incentivised to produce code that looks finished, the reviewer to find fault, the tester to break it outright; the friction is how the system catches its own mistakes — but it means the team cannot honestly be modelled as a single utility-maximiser. Genuinely divergent objectives cross a quiet border out of engineering and into economics — Part IV’s business — where the central question is no longer “what should the system do?” but “what is each participant incentivised to do?” They cannot be folded into a single agent without silently deciding whose prevails — 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 — rarely an oversight: autonomy, scale, fault tolerance, or plain lack of authority demands it. The contemporary agent system inherits every hazard of classical concurrency: while the reviewer reads version N of a file, a coder has produced version N+1, and the tester is dutifully testing a version that no longer exists. Decentralised control is also provably, steeply expensive: for even two cooperating agents that cannot freely share observations, an optimal joint policy — a finite-horizon decentralised POMDP — is NEXP-complete (Bernstein et al., 2002), the infinite-horizon version undecidable outright. 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, attention, and — the currency of the running example — tokens. The canonical statement of the hazard is Hardin’s tragedy of the commons (1968), every actor, rational on its own account, overgrazing a shared pasture into collective ruin; the pattern transfers unmodified to agents sharing a token budget or a rate limit. Here the marks converge: coders, reviewer, and tester draw on one bounded budget, and an agent that spends without restraint starves its colleagues — precisely where the cooperative mission acquires a competitive interior. Some mechanism must allocate the scarce resource, and how — budgets, priorities, internal markets — is the business of Chapter 12. 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 marks license a single, initially counter-intuitive conclusion: the competence to solve such a problem cannot be located in any individual participant, because it does not reside there. It resides in the structure of their interaction: who knows what, who talks to whom, who decides, who may overrule whom. The inversion is old — Minsky’s Society of Mind (1986) portrayed a single mind as a society of mindless components — and the wager of this book is that in the multi-agent setting it is not metaphor but engineering reality: the interaction structure — protocols, topology, allocation of authority — is the primary object of design, and it, far more than any individual’s capability, determines whether the system behaves capably. That is why so much of what follows concerns communication, coordination, and collective decision-making: they are where the intelligence of a multi-agent system actually lives.

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

Two terms have been doing a great deal of unexamined work; time to pay them the courtesy of a definition. Agent is among the most over-loaded words in computing — applied, with a straight face, to thermostats, web crawlers, chess programs, and lately anything with a language model inside it; three decades ago Franklin and Graesser surveyed the wreckage and asked whether a given program was an agent at all or merely a program with ideas above its station (1997). We will not adjudicate every contested definition — a task with no terminating condition — but fix working notions stable enough to outlast the current vocabulary.

1.2.1 What Makes Something an Agent

The most durable definition is also the most modest, absorbed by a generation from Russell and Norvig (2021): an agent is anything that perceives its environment through sensors and acts upon it 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 once and halting.

What turns the minimal loop into something worth the name is the cluster of properties in Wooldridge and Jennings’s canonical account of agency (1995): autonomy — acting without step-by-step instruction, retaining its own locus of control; reactivity — responding to a changing environment; pro-activeness — taking the initiative in pursuit of goals; and social ability — interacting with other agents. Of these, autonomy is load-bearing: a component that does only and exactly what 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.

Be clear, early and in bold, where the language model fits. 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: no memory between calls, no goals, no means of acting, no loop. An agent is what you get when you wrap the model in the missing parts — persistent state, tools, and a control loop from perception to action and back — a decomposition stated influentially by Weng (2023). The model supplies the deliberation; the agent supplies the agency. What the model provides and withholds is the business of Chapter 2; the anatomy of the wrapper occupies Part II.

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 — an approximation needing two refinements. The agents must interact: a dozen agents labouring in isolation are merely a dozen agents. And no single agent may hold complete authority over the rest: where one controller dictates every move, what you have is one agent and some marionettes — the substance behind the unkind observation that much of what is marketed as multi-agent is several prompts in a trench coat. Autonomy, interaction, and decentralised control do the defining work, and the standard treatments draw the boundary just so: autonomous agents, each with a partial view and its own locus of control, interacting in a shared environment (Shoham & Leyton-Brown, 2009; Wooldridge, 2009). Note what this does not demand: neither equality — hierarchies qualify, provided the workers retain genuine local discretion — nor cooperation, for marketplace adversaries qualify as readily as collaborators. The running example sits comfortably inside: each member runs its own loop, perceives its own slice of the repository, and decides locally; and though the orchestrator enjoys a measure of authority, it cannot, given the marks of Section 1.1, take every decision on the others’ behalf.

Note, finally, what neither definition demands: that the agents be artificial. A human satisfies every clause, and the marks apply to mixed human–agent collectives unamended — ask anyone who has reviewed machine-written code against a deadline. The running team is such a collective from the start: its fifth member is the person it answers to, who sets the objective, owns the budget, and — in the designs of Chapter 20 — holds the gate irreversible actions must pass through. The humans stay mostly offstage but never leave the theatre: when evaluation arrives, the unit under test is the human–agent whole (Chapter 21), and when accountability arrives, every thread terminates at a person (Chapter 22).

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 near-relations forever being mistaken for it — on occasion by their own designers. Each of the six neighbours below lacks at least one of autonomy, interaction, and decentralised control, and calling one by the wrong name reliably leads to building the wrong thing. Table 1.2 summarises the distinctions; the subsections give the reasoning.

1.3.1 Distributed Systems, Services, and Microservices

A distributed system spreads computation across networked machines coordinating by message-passing, with neither shared memory nor a global clock (Tanenbaum & van Steen, 2023). It shares the entire grim bestiary of Section 1.1, and much hard-won engineering wisdom besides; what it 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; a node that began pursuing goals of its own would be counted not clever but faulty. The microservice (Newman, 2021) comes closer — it owns its data, hides its internals, deploys independently, and is described in its literature, advisedly, as autonomous — but the autonomy is organisational, not behavioural: free to change how it works, it does not choose its goals, take the initiative, or decline a well-formed request. A service answers; an agent acts. The border is the point at which a service may say “no”, negotiate, or act unbidden — at which moment it has quietly become an agent, and the comfortable guarantees of request-and-response have left with it.

1.3.2 Ensembles and Mixtures of Experts

Machine learning contributes two more. The ensemble combines the predictions of several models — by voting, averaging, or a learned rule — into an output usually better than any member’s (Dietterich, 2000); but its members do not interact, perceive one another, or adjust to what the others do — a fixed rule imposed from outside reconciles their outputs. Aggregation is not interaction, and a fixed voting rule is not a coordination protocol — though the moment several agents vote, they inherit the whole apparatus of social choice, impossibility results and all (Part IV). The mixture of experts — specialised sub-models behind a learned gating network, from Jacobs, Jordan, Nowlan, and Hinton (1991) to the sparsely-gated layers of modern language models (Shazeer et al., 2017) — sounds more agent-like still, but it is one model with internal structure: the experts do not act in the world, hold goals, or speak to one another. Routing inside a model and delegation among autonomous agents are the same metaphor stretched over very different machinery.

1.3.3 Workflows and Pipelines

The next look-alike matters most in practice: it is what gets built when a multi-agent system was neither needed nor wise. A workflow — equivalently, a pipeline — is a fixed sequence of steps decided in advance and baked into code; the contrast is by now standard: predefined paths versus a model dynamically directing its own process (Schluntz & Zhang, 2024). A workflow may have a language model at every step; what it lacks is any component deciding, at run time, what the next step should be — Table 1.2’s tick for interaction is honestly earned, and only the freedom to redraw the route is missing. This is frequently a virtue — a fixed pipeline is easier to test, cheaper to run, simpler to debug, less inclined to surprise you — and a great deal of what is breathlessly marketed as “agentic” would be more reliable rewritten as a workflow. The genuine multi-agent system earns its keep only where the control flow cannot be fixed in advance; Section 1.6 attaches a decision procedure.

1.3.4 Delegating Single Agents

Contemporary practice invented the last look-alike, and a great many systems wearing the multi-agent label are exactly this. A delegating single agent spawns short-lived subagents as tools, chiefly for context hygiene: a subtask gets a fresh, narrow window, returns a summary, and ceases to exist, while everything that governs stays singular: one locus of control, one budget, one journal, no channel between workers. Judged against Section 1.2 it scores two of three — autonomous workers that interact — but control is not decentralised: their autonomy is leasehold, exercised inside a mandate the lead wrote and can revoke. Is an assistant farming out searches to disposable readers “really” multi-agent? Not quite, and the not-quite has a diagnostic: knowledge distributed by capacity, not ownership. Nothing but window size stops the lead reading everything itself: delegation is a remedy the lead chose, not a fact of the problem; the species keeps the single agent’s virtues while buying plurality’s two cheapest benefits — parallel hands and clean windows. The boundary to the genuine article is crossed the moment a worker acquires standing: an objective of its own, a channel to a peer, an authority the lead cannot overrule — our team’s reviewer, whose veto the harness itself will enforce, holds exactly such standing. Chapter 18 maps the spectrum under the supervisor pattern.

Table 1.2: The multi-agent system and its look-alikes: only it exhibits all three defining features at once, and each neighbour is told apart by what it lacks. The delegating single agent, practice’s newest near-miss, lacks decentralised control alone.
System Autonomous components Interaction Decentralised control
Distributed / concurrent system ✗ ✓ ✓
Service-oriented / microservices ✗ ✓ ✓
Ensemble ✗ ✗ ✗
Mixture of experts ✗ ✗ ✗
Workflow / pipeline ✗ ✓ ✗
Delegating single agent ✓ ✓ ✗
Multi-agent system ✓ ✓ ✓

1.4 The Running Example, Up Close

We met the software-engineering team in the opening and have leaned on it since; time to look at it directly. The example is not a thought experiment: ChatDev and MetaGPT assemble role-playing software teams (Hong et al., 2024; Qian et al., 2024), and SWE-bench measures, unsentimentally, whether such agents resolve real GitHub issues by the thousand (Jimenez et al., 2024). The orchestrator-and-workers arrangement is the workhorse topology of contemporary practice; Anthropic’s own research system is exactly this pattern, and reports, with disarming candour, consuming many times the tokens of an ordinary chat (2025).

What recommends the team is that it is genuinely multi-agent: the preceding sections found all four marks. A verdict about the system, not yet the problem: two of the marks are of our own making — the knowledge distributed because we split the context, the objectives divergent because we set them in opposition — and the sceptic who suspects a single capable agent, handed the whole repository and budget, might have served asks exactly the right question. It is the question Section 1.6 closes the chapter with, and Chapter 21 will put to instruments; the team enters the book as its standing candidate, obliged to earn, on evidence, the plurality it was given by design.

It also displays a duality that recurs throughout the book — the reason this example is the spine. 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 live in the tension between those two levels; we will not so much resolve it as learn to engineer with it. A final caution: job titles are not coordination mechanisms. A role is only as real as the information it is given, the decisions it may take, and the consequences it must answer for — the difference between a team and a group of language models sharing a letterhead.

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. Adding agents is a trade, worth making only when what you gain exceeds what you give up; this section sets out both sides of the ledger, and Section 1.6 turns them into a decision.

1.5.1 The Benefits

What can additional agents buy? Mainly these.

Specialisation. A single agent asked to do everything holds every instruction, tool, and standard in one context; dividing the work gives each agent a smaller, sharper brief — a reviewer thinking only about code quality, a tester only about breaking things — easier to instruct, evaluate, and keep on task.

Parallelism. Independent sub-tasks proceed at once; Anthropic reports exactly this orchestrator-led decomposition beating 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, and a well-drawn boundary contains damage: a failing, looping, or compromised agent can be retried or quarantined without bringing down the whole.

Diversity. Agents approaching a problem differently — different prompts, models, vantage points — can catch one another’s errors and surface options a single line of reasoning misses. This is the intuition behind multi-agent debate, and there is some evidence that arguing improves models’ factual accuracy (Du et al., 2024); whether it makes agents cleverer or merely more verbose is a question Part IV examines with some scepticism.

1.5.2 The Costs

Against them stands a ledger easy to underestimate, because most of it stays hidden until the system is running in earnest.

Cost and latency. Every agent is a model call, and a multi-agent system multiplies calls — repeated context, redundant reasoning, rounds of coordination. Anthropic’s research system consumed, by its own account, roughly fifteen times the tokens of a single chat exchange (2025) — a price worth paying only if you know you are paying it. One modern mercy: providers bill a cached re-read — a prefix already processed on an earlier call, Chapter 2’s serving-stack economy — at a small fraction of the fresh rate, a discount landing precisely on the multi-agent habit of re-reading the same instructions every turn. It rescales the bill without changing its shape: the text coordination mints — briefs, summaries, status traffic, fresh reasoning — no cache can discount, and prefixes that diverge agent by agent cache separately. Fifteen-fold tokens need not mean fifteen-fold spend, but the surcharge is real; Exercise 3 separates the part a cache forgives from the part it cannot.

Duplicated and inconsistent work. Agents that cannot see their colleagues’ work duplicate it and contradict one another — worse, they act on shared state that has quietly diverged, two coders editing the same file under different assumptions. Keeping a distributed view consistent is among computing’s oldest problems, and for one widely-read practitioner argument, fragile, divergent context alone is reason to prefer a single agent wherever one will do (Yan, 2025).

Failure modes all of their own. An empirical study of popular multi-agent frameworks catalogued fourteen distinct failure modes rife across more than two hundred tasks (Cemri et al., 2025); many had little to do with the model’s capability and everything to do with the organisation around it — agents talking past one another, dropping responsibilities each assumed the other had, 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 — as Part VII will argue, a genuine obstacle to accountability, growing 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.

1.5.3 The Trade, Priced*

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, of which a fraction p \in [0,1] can genuinely proceed in parallel while the remaining (1 - p) is sequential. Sharing the parallel portion among n agents shrinks it to p/n; but agents, unlike processor cores, must keep one another informed, and the keeping levies a coordination tax c(n), paid in tokens and latency: 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: it grows with the wiring, not the work — if every pair must talk, c(n) grows like the pair count \binom{n}{2}, quadratically — and Section 8.6 weighs topologies by how much wiring they prune.1 The speedup S(n) = T_1 / T(n) therefore rises only while each new agent removes more waiting than its conversation adds: the parallel gain is bounded 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.

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 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 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) were the talking free; Figure 1.1 plots the family, tax-free ceiling and taxed peaks together.

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 climbs to Amdahl’s ceiling, while each priced curve turns over at an interior optimum n^{*}, beyond which another agent makes the team slower and dearer.

None of this is a law: it is the simplest model that exhibits the trade, its parameters facts about your task rather than constants of nature, and it prices only time and tokens — specialisation, diversity, and quality 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 21 supplies the instruments.

1.6 Should You Build One at All? A Decision Framework

We can now answer the chapter’s opening question. The governing principle is parsimony: prefer the simplest architecture that solves the problem — the most reliable predictor that a multi-agent system will disappoint is that it was built before anyone checked whether a simpler thing would do. The framework is a descending ladder of off-ramps, its bias deliberate: at every rung it tries to send you home.

Begin by assuming you need exactly one agent, and try to talk yourself out of more: a single capable model with the right tools can accomplish a remarkable range of tasks that look like team work, and the practitioner consensus, hard-won and increasingly emphatic, is to start there and stay as long as you can (Schluntz & Zhang, 2024; Yan, 2025). If one agent cannot do the job, ask whether you 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; reach past it only when what to do next turns on judgements made as the work unfolds. If the steps cannot be fixed but the judging can stay in one head, try Section 1.3.4’s species — one deciding agent hiring ephemeral subagents, the honest ceiling for most systems currently wearing the team label; ask why the knowledge is distributed — if only by capacity, delegation cures it cheaply — and reach past it only when a worker needs standing a tool cannot have: an objective of its own, a peer it must speak to, a verdict the lead cannot overrule. A genuine multi-agent system earns its keep past that threshold, when the problem bears the marks of Section 1.1 in a way no single locus of control can absorb and the control flow cannot be fixed — and even then only when the benefits outweigh the costs for this specific problem (Section 1.5).

1.6.1 A Checklist

The ladder collapses to six questions (Figure 1.2); the first that sends you home 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 · Ephemeral helpers enough?"])
    Q3 -->|"yes"| A3["Build a delegating<br/>single agent"]
    Q3 -->|"no"| Q4(["4 · Inherently multi-agent?"])
    Q4 -->|"no"| A4["Clarify the<br/>specification first"]
    Q4 -->|"yes"| Q5(["5 · Benefits outweigh costs?"])
    Q5 -->|"no"| A5["Accept the simpler design"]
    Q5 -->|"yes"| A6["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,Q5 gate
    class A1,A2,A3,A4,A5 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 five to reach the multi-agent box at the bottom.
TipThe decision in six 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 steps cannot be fixed, would one deciding agent with ephemeral, tool-like subagents do — knowledge distributed only by capacity, no worker needing standing (Section 1.3.4)? If yes, build that. Stop.
  4. If not, does the problem truly bear the marks of Section 1.1 — distributed knowledge, divergent objectives, decentralised concurrent control, contested resources? If not, you are probably papering over an unclear specification; clarify it first.
  5. If it does, do the benefits of plurality outweigh its costs for this problem (Section 1.5)? If not, accept the simpler design.
  6. 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.

Reach the sixth question honestly and you are building a multi-agent system not because it is impressive but because the problem left you no honest alternative — the only good reason there has ever been. The rest of this book is about doing it well.

1.7 A Premature Theory: Where the Agent Idea Came From

This chapter has been leaning on the word classical, and it owes you the story: how the theory of agents reached completion decades before anything could run it, and why this book treats it as a live resource rather than a museum.2 The moral in advance: the theory was largely sound, the timing largely terrible, and it is worth knowing which was which before the present enthusiasm repeats the experiment.

1.7.1 The Idea Assembles

The agent emerged from a quarrel within artificial intelligence about what intelligence is and where it lives. The founding bet — Newell and Simon’s physical symbol system hypothesis — held that thinking is computation over symbols, and for two decades that paradigm more or less was artificial intelligence: one centralised reasoner deducing what to do (1976). But the world rarely arranges itself around one omniscient reasoner, and out of that discomfort grew distributed artificial intelligence — the Contract Net protocol (Smith, 1980), a manager announcing a task and contractors bidding, is very nearly our orchestrator, stripped of its language model. A third camp objected that the symbols were themselves the problem: Brooks’s mobile robots — a subsumption architecture of sensorimotor layers, no central representation — argued that the world is its own best model (1986, 1991). The manifesto overstated the case, as manifestos must, but the situated turn stuck: an agent is coupled to an environment in a loop — the framing Section 1.2 adopted — and every architecture since has balanced deliberating against reacting, the compromise Chapter 3’s hybrids strike.

There remained an embarrassment: researchers spoke freely of what their agents believed and intended, knowing the agents were a few hundred lines of Lisp. Dennett supplied the licence: to predict a complex system, adopt the intentional stance — describe it as if it were a rational agent, and ask what such an agent ought to do (1987). The stance makes no claim about what is inside; it is a bet that ascribing a mind is the most economical way to anticipate behaviour — the respectable name for agents pretending to be intelligent — and it licensed a methodology: if the ascription helps us design and predict, then belief, desire, and intention are legitimate engineering primitives, whatever the hardware beneath.

1.7.2 The Synthesis, and the Decade That Overspent It

The field took the licence literally. Bratman made the intention — a commitment to a future course of action — a distinct mental state whose whole point is that it resists reconsideration: an agent that re-derived its entire plan on every cycle would never get anything done (1987). Rao and Georgeff systematised it — already running spacecraft fault monitoring as Georgeff and Lansky’s Procedural Reasoning System (Georgeff & Lansky, 1987) — into the belief–desire–intention model, a loop whose craft lies in the balance between committing hard enough to make progress and reconsidering often enough to stay sane (1995). The perceive–deliberate–act cycle of a modern language-model agent is BDI with the serial numbers filed off; Chapter 3 makes the identification precise.

If agents are best described in beliefs and intentions, why not program them that way? That was Shoham’s agent-oriented programming (1993): a program as a mental state, behaviour specified as commitment rules rather than procedures. His language AGENT-0 is a museum piece, but the idea was prophetic — Shoham proposed programming in the intentional vocabulary three decades early, and every reader who has written a system prompt has since honoured the proposal. Beneath the architectures lay the formal logics of agency — Cohen and Levesque’s intention as choice with commitment (1990) — the layer that aged least kindly: not wrong, but the gap from modal logic to deployable agent proved enormous.

Handed a finished theory and a fast-growing internet, the 1990s declared agents the coming paradigm of computing, in three forms. Agents would act for you — Maes’s software assistants, quietly taking work off your hands (1994): the right vision in the wrong decade, for the agent had nothing intelligent to delegate to. Agents would travel, and foundered on the fact that no host should trust travelling code when the remote call required trusting no one. And agents would talk: on the foundation of speech act theory — Austin’s and Searle’s observation that saying “I promise” is promising (1962; 1969) — the KQML and FIPA-ACL languages organised agent talk around performatives: tell, ask, achieve (Finin et al., 1994). The last promise did not fail so much as wait: the questions those languages asked are being asked again — of the Model Context Protocol (MCP) and its kin (2024) — by people who have often never heard of them; Chapter 5 performs the introductions.

1.7.3 The Hollow Agent, and the Reversal

None of it happened, and for the deepest of reasons: the decade had produced exquisite containers for intelligence and very little to put in them. A BDI agent maintained beliefs and selected intentions impeccably, but the beliefs were hand-crafted, the plans hand-written, the competence exactly what its designers anticipated. Call it the hollow agent: an autonomous shell around a brittle, hand-built core, autonomous in roughly the way a wind-up toy is alive. The field’s own roadmaps named the gap (Jennings et al., 1998); no architecture ever closed it, because it was not an architecture problem — it was waiting on a general-purpose source of competence still twenty years away. Denied its killer application, the field retreated to ground it could defend — game theory, mechanism design, the formal logics of knowledge and intention — a genuine flourishing from which Part IV directly descends, and also, without quite saying so, a decision to wait.

Waiting was not idleness — mechanism design ran the spectrum auctions and came to underwrite keyword advertising (Edelman et al., 2007), a story Chapter 12 tells properly, and TD-Gammon opened the self-play line Chapter 14 follows (1995) — but it was waiting all the same.

The missing piece arrived from an almost unrelated quarter: very large neural networks trained to predict the next word. The surprise — genuine, to the practitioners as much as anyone — was that at sufficient scale the training yielded something startlingly close to general competence (Brown et al., 2020). A foundation model is not an agent — no goals, no memory, no loop, as Section 1.2 insisted — but it is exactly the deliberative core the classical shells were built to house and could never fill. After thirty years, the shell had something to put inside it.

The two halves of the story state this book’s thesis: the classical theory was not mistaken — it described real structure, correctly — there was simply nothing to instantiate it. The theory was premature, and the foundation model does not refute it but completes it; the chapters ahead treat the classical literature as answers kept in storage, whose questions have at last become askable. One caution: the present moment has the unmistakable shape of the last one — the vocabulary of imminent, autonomous agents back almost verbatim, today’s teams still failing in ways a veteran of the agent decade would recognise (Cemri et al., 2025). The agents are no longer hollow; but capability is not reliability, and an intelligent core exempts no system from needing coordination, evaluation, accountability, and restraint. The lesson of the last cycle is that enthusiasm is not a method — the field forgot that once, expensively, and now that the agents can finally do something, it can afford to forget it even less.

1.8 Summary

  • More than one agent is a means, never a merit. Plurality buys specialisation, parallelism, and diversity; it costs duplication, inconsistency, latency, and diffused responsibility — and the case for it rests on the problem’s structure, never the architecture’s appeal.
  • Some problems are inherently distributed. Distributed knowledge, divergent objectives, decentralised concurrent control, and contested resources are the four marks; where they hold, the competence lives in how the agents interact, not in any one of them.
  • 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, workflows, and delegating single agents each lack at least one of autonomy, interaction, and decentralised control.
  • Default to the simplest thing that works. A single agent, then a fixed workflow, then a delegating single agent; reserve genuine multi-agency for problems that leave no honest alternative.
  • The theory came first, the agents were hollow, and premature is not wrong. The classical synthesis specified agents decades before anything could animate them; foundation models supply the missing competence, making a thirty-year-old literature applicable rather than obsolete — while the failure modes of the last hype cycle remain on offer.

1.9 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. 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 2. 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 3. 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? (e) Providers bill a cached re-read — a prefix already processed on an earlier call — at a fraction \eta of the fresh rate (Section 1.5), so only the replication term is discounted: B_{\eta}(n) = 1 + \eta\,\rho\,(n - 1), with T(n) unchanged. Recompute (a)’s bill and (b)’s cost-effective optimum at \rho = 0.5, \eta = 0.1; show that discounting re-reads can move the cost optimum only toward the time optimum n^{*}, never past it; and name the team’s real token costs that \eta leaves undiscounted — exactly the ones Section 1.5 said no cache can forgive.

Exercise 4. Five 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) “Work out why last night’s build broke — the trail could run through any of a dozen services, their logs, and a week of commits, together far more text than one context holds; one engineer will read your conclusion and decide what to do.” (iv) “Churn is up; deploy an agent army to work out why users leave and fix it.” (v) “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 six 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 sixth 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 5. The reviewer of the running-example team, asked to gate a merge, ends its transcript: “I believe this patch is safe: the suite passes, and no public interface changes.” Mechanically, the reviewer is a language model invoked afresh on a context assembled for each call; nothing inside it persists between calls. (a) State one concrete prediction about the reviewer’s behaviour that the intentional stance licenses, and explain, by Dennett’s own criterion for choosing among stances, why neither the physical stance nor the design stance is a serious rival here. (b) Construct a specific two-call sequence of events under which your prediction from (a) fails, for a reason the intentional vocabulary cannot express; your scenario must involve no new evidence about the patch. (c) Propose one engineering change to the reviewer that gives the ascription “believes” a real referent — the classical synthesis of Section 1.7 built exactly this structure — and say which failure in (b) it removes and which residual gap it leaves.

Exercise 6. A coder agent holds a plan with k = 4 steps remaining; executing a step costs a = 200 tokens. Before each step the repository may shift under the agent — a colleague merges a conflicting change — with probability q, independently at each opportunity; once shifted it stays shifted, and every step of the old plan executed thereafter is waste. A shift is noticed only when the agent deliberates. Consider the two poles of the balance Section 1.7 describes: the bold agent deliberates only when the plan is exhausted, executing all four steps come what may, while the cautious agent deliberates before every step, at d = 60 tokens per deliberation, and so catches any shift before wasting a step on it. Two overheads distinguish the policies — the bold agent risks wasted steps, the cautious agent pays its four deliberations — and every other cost, replanning included, falls equally on both and may be ignored. (a) Show that the bold agent’s expected waste in tokens is W_{\mathrm{bold}} \;=\; a \sum_{t=1}^{k} (1-q)^{t-1}\, q\, (k - t + 1), evaluate it at q = 0.25, and say which policy is cheaper there. (b) Re-evaluate at q = 0.05. (c) With a few lines of Python, locate to three decimal places the volatility q^* at which the two policies break even, and state in one sentence what this arithmetic makes of Bratman’s claim that the whole point of an intention is that it resists reconsideration.

Further exercises for this chapter continue in the web edition’s exercise bank.

“And have we tried being a single agent?”

  1. Amdahl’s law plus a pairwise coherence penalty is Gunther’s Universal Scalability Law (Gunther, 2007); its retrograde region, where each added worker makes the system slower, is Brooks’s law given a formula (Jr. Brooks Frederick P., 1975).↩︎

  2. This section is the short version; the fuller history is a web-edition chapter at https://books.bloo-mind.ai/masact-extended/a-short-history-of-agents.html.↩︎