Preface
There are some particularly poor reasons for building a multi-agent system. One is that a single agent has failed, and several of them, surely, can fail more impressively together. Another is that several agents look more convincing in an architecture diagram. Neither is a design principle.
The proper reason is that some problems are inherently distributed — the knowledge scattered, the objectives only partly aligned, the control decentralised, the resources contested — so that no single agent can dictate what everyone else should do. In such settings, intelligence is not merely a property of an individual agent: it is also a property — or, just as often, a regrettable absence — of the interactions among agents.
This book is about those interactions. And it exists because, at the precise moment those interactions have become buildable at scale, the two communities best equipped to reason about them have largely sailed past each other in the fog.
Two Tribes
On one side stand the multi-agent systems researchers, inheritors of more than three decades of careful work on autonomous agency, communication, cooperation, negotiation, organisations, norms, and collective decision-making — almost exactly the vocabulary the moment requires. The tradition’s canonical statements are a pair of 2009 books: Michael Wooldridge’s An Introduction to MultiAgent Systems (2009), deservedly still the standard entry point, and Yoav Shoham and Kevin Leyton-Brown’s Multiagent Systems (2009), the field’s mathematical anchor. Superb books, written entirely before the thing that makes their subject newly urgent had been invented: in 2009 an “agent” was a carefully constructed piece of Java under strict logical constraints — or, in the public imagination, an animated paperclip with an unhealthy interest in your margins.1
On the other side stand the practitioners of the new agentic engineering — builders of orchestrators, supervisors, routers, hand-offs, subagents, and swarms, armed with frameworks that did not exist three years ago and capabilities that did not exist three months ago. Their most accomplished statement is Victor Dibia’s excellent Designing Multi-Agent Systems (2025), an agent runtime built from first principles — precisely the hands-on treatment the field needed. What they have also been doing, with great energy and good cheer, is rediscovering things settled in the 1990s — occasionally badly, frequently under new names, in the sincere belief that they are unprecedented. Sometimes the coinages are genuinely new; sometimes they are old ideas wearing new API documentation, and telling the two apart is most of the intellectual work. Meanwhile the engineering runs on intuition, folklore, and copying whatever worked on the internet last week: engineers routinely re-enact the Prisoner’s Dilemma without recognising one, allocate scarce resources among agents without knowing that mechanism design is a field, aggregate the votes of several models without knowing that Arrow (1951) proved something inconvenient about exactly that, and stage debates without knowing that argumentation has a formal theory — the youth of a discipline, not a sin, but flying without instruments all the same.
The thesis of this book — stated plainly, so you may decide early whether to argue with it — is this: the classical theory of multi-agent systems was not wrong, nor obsolete, nor superseded. It was merely premature. It described agents that could not yet be built. They can be now, and the theory is, for the first time, applicable — to the exact systems thousands of engineers are building with no idea that the relevant results exist. But the bridge carries traffic in both directions, and the toll is paid in assumptions: the classical results were proved about agents with stable preferences, inspectable beliefs, and no capacity to deviate from protocol; ours are stochastic, suggestible, and only approximately rational; and some theorems mind the difference a great deal. So the translations in this book come with their terms stated — for each classical result, which of its assumptions the new agents satisfy, which they strain, and what actually transfers. A theory that was merely premature must still be revalidated against the machines that have finally arrived.
What This Book Is
This is, before anything else, a bridge. Wherever a modern technique has a classical antecedent, we name it, trace the lineage, and ask what the old theory teaches the new practice. A few examples, all treated fully later: The Agent-to-Agent (A2A) protocol is, in essence, a rediscovery of the agent communication languages — KQML and FIPA-ACL — and behind those, of speech act theory, with its distinction between exchanging strings and achieving mutual understanding; its sibling the Model Context Protocol (MCP) faces the tool rather than the peer, and with the model interface beneath both, the consolidation is one story told at three altitudes. The supervisor patterns dominating framework documentation are cooperative distributed problem solving, their canonical case Smith’s Contract Net protocol (1980). Multi-agent debate, critic–actor loops, and adversarial collaboration are computational argumentation in newer clothes. Ensembles, majority voting, and judge models are social-choice mechanisms, and inherit social choice’s impossibility results whether their designers like it or not. The belief–desire–intention architecture and the reasoning-and-acting loop are close cousins. None of this diminishes the modern work — the engineering is genuinely new and hard — it enriches it, handing practitioners a map of territory already partly surveyed.
It is also a pragmatic book. Theory that cannot be cashed out in working code is, for our purposes, decoration — philosophy with extra steps — so every significant concept comes with runnable code and exercises, written for someone who must ship something dependable on Monday. We treat the decision to use many agents as an engineering choice rather than an article of faith: plurality buys real things and sends a real bill, and Chapter 1 opens the book by pricing that trade. A committee of language models is still a committee; minutes should be kept. Throughout, we ask not only how to build a multi-agent system, but whether one should be built at all.
Finally, the book is coherent by design: one field, from symbolic and game-theoretic foundations through learning to foundation-model agents and production engineering, with evaluation, dependability, safety, and accountability beside capability — a system is not successful merely because it produced an impressive transcript.
What This Book Is Not
This is not a catalogue of agent frameworks; such catalogues age with remarkable efficiency. Nor is it a manual for prompting several models to impersonate a software company: four agents with impressive job titles are a role-playing exercise, not an organisation, and much of this book concerns the difference. It is not a claim that many agents always beat a single agent, a fixed workflow, or ordinary software: autonomy belongs where it is needed, not scattered decoratively. And it is not a book only about language-model agents: robots, economic agents, distributed software services, simulated societies, and reinforcement-learning agents remain essential to the field — foundation models broaden the subject; they do not define its boundaries.
A Note on Scope: Learning, and Where MARL Lives
One boundary is deliberate. Multi-Agent Reinforcement Learning (MARL) — the study of agent collectives that learn to interact through reward — is a major and beautiful area and a distinct tradition: taught honestly, it needs Markov Decision Processes (MDPs), value functions, and a good deal of deep learning before the word multi-agent even arises. Happily, that book exists and is, conveniently, free — Albrecht, Christianos, and Schäfer’s Multi-Agent Reinforcement Learning (2024) — and we will point the reader there repeatedly and without resentment. This book gives the subject a single, conceptual chapter: enough to map the terrain — non-stationarity, multi-agent credit assignment, self-play, emergent communication — and to pose the contemporary question: should coordination among capable agents be learned or composed? The depth is delegated; the connections are kept.
On Frameworks, Code, and the Perils of Being Specific
Writing about a field that reinvents its tooling every few months has an obvious hazard: the half-life of an agent framework appears to fall somewhere between that of a mayfly and a supermarket prawn sandwich, and any chapter too specific about a library’s API reaches its reader as a historical document rather than a tutorial. While this preface was being written, one major laboratory renamed its agent SDK, another merged two flagship frameworks into one, and a third shipped a 1.0 of its own. The book’s defence is to be principles-first and framework-plural. What a coordination protocol is for, why a topology fails the way it does, what makes an evaluation trustworthy — that content does not expire, and is where the book spends its weight; framework-specific material is illustration rather than scripture, spread across several systems so no vendor’s roadmap can date it; and Chapter 16 makes the choosing itself a procedure built to outlast the current versions. The primary teaching vehicle is LangGraph,2 chosen because its explicit, graph-structured model of agent control — typed state, reducers, checkpoints, conditional routing — maps unusually cleanly onto the classical concepts, and because it is model-agnostic, which keeps the pedagogy honest. Throughout, we also build the core machinery from scratch — you do not truly understand a thing until you have built a small one — so the frameworks become conveniences you understand rather than magic you depend upon. The companion code, described below, carries the burden of currency: a reader meeting the fifth renamed version of an API is not thereby obliged to purchase a new theory of cooperation.
A companion hazard: in a field this young, much of what is known about deployed systems — how they fail, what they cost, why a protocol took its shape — appears first, and sometimes only, in engineering reports and post-mortems: grey literature, cited here deliberately, held to the same standard as everything else — named authors, checkable claims, dates attached — with the archival sibling cited where one exists.
The Shape of the Book
Seven parts run from individual agency to the questions a deployed society of agents forces. Part I sets the scene and prices the decision; Part II builds the anatomy of a single agent — architectures, reasoning, tools, actions, memory, context. Part III is communication and coordination: speech acts to common ground, teamwork, and distributed problem solving under the constraints of communication cost, concurrency, and partial observability. Part IV is conflict and collective choice: games, votes, negotiation, markets, organisations. Part V is the concise account of learning and of emergence, with methodological cautions attached to the more theatrical demonstrations. Part VI is the engineering: choosing a framework, the runtime built from scratch, the patterns, the protocols, and — built twice, first in plain Python, then in LangGraph — the dependability and security that demonstrations postpone. Part VII holds the reckonings: evaluation against a strong single-agent baseline, because you cannot unit-test a vibe; accountability organised around three deceptively simple questions — who authorised an action, who could have stopped it, and who must explain it — with the changing role of human expertise; and the open problems — across theory, learning, engineering, economics, safety, and governance — left for the reader to solve.
How to Read This Book
The book is a reference superset, not a fixed syllabus — more than any course should attempt, built to be carved into subsets — and Table 1 names the natural ones, the notes beneath it defining its terms. Every path begins with Chapter 1: whether a multi-agent system should be built at all is the book’s first question, and no reader is exempt.
| Reader or course | The core, in reading order | The rest — sample or skip |
|---|---|---|
| Postgraduate course (either length) | Parts I–IV, the conceptual core | Parts V–VII, sampled by the course’s emphasis |
| One-semester course | Part I entire; the spines of Parts II and III; the Part IV chapters nearest the emphasis | Everything else, as time allows |
| Two-semester sequence | The whole book, broken between Parts IV and V | — |
| Theory-leaning course | Part I; Parts II–V entire, with Appendix A alongside; Chapter 21 | Part VI and the rest of Part VII |
| Engineering-leaning course | Part I; Parts II and VI entire; the Part III and IV chapters the project at hand needs; Chapters 20 and 21 | Everything else; Chapter 14 first where the project learns as well as composes |
| Systems-and-society course | Part I; Parts IV, V, and VII | Parts II, III, and VI; the spines of II and III as background |
| Practitioner | Chapter 1; the spine of Part II (Chapters 3 and 4); then Part VI; then Parts III and IV; then Chapters 20 and 21 | Everything else, Part V last |
| Practitioner in a hurry | Chapter 1, then Part IV | Everything else, when the hurry subsides |
| Curious reader | Part I, then Chapters 22 and 23 | Everything in between — every good bit of it |
Spines and seams. A part’s spine is the chapters the rest of the book leans on hardest: in Part II, Chapters 3 and 4; in Part III, Chapters 6, 7, and 8, plus Chapter 5’s speech-act half. The two-semester sequence breaks at the seam between Parts IV and V: the first term ends with agents that interact, the second opens with agents that learn. And one timetabling rule: Chapters 20 and 21 belong in the same term — 20 hands its instruments to 21 mid-argument, and the seam is not built to survive a term boundary.
Prerequisites are deliberately modest: comfort in Python and the basics of artificial intelligence and machine learning. The more advanced mathematical sections are marked with a star (*) so practitioners may postpone them without precipitating a constitutional crisis; a postgraduate course should read the stars as syllabus, not garnish — they carry the formal statements the prose argues from. Starred sections state rather than prove, citing where each proof lives; and an equation appears only where it says something more clearly than prose could. A glossary at the back — a Rosetta Stone translating classical terminology into its modern rebrandings and back — covers the moments the two vocabularies collide.
A Live Book, Written in Public
This book is being written in the open, published at https://books.bloo-mind.ai/masact/ and revised as the field — and the authors’ second thoughts — require; every page can be annotated and commented upon directly. Readers are warmly invited to argue with the text, flag what is wrong, and propose the joke we ought to have made instead: a book about communication and collective intelligence should practise what it preaches.
Disclosure of AI Assistance
A book so concerned with what capable agents can accomplish owes a plain statement about its own production: it was written with substantial AI assistance. Frontier LLMs (mainly Anthropic Claude and OpenAI GPT) and the agentic tools built on them worked throughout the drafting and revising — language editing, reference checking, inconsistency sweeping, code testing, diagram drawing: exactly the kinds of work this book teaches one to delegate well. One practice deserves explicit statement, because a sceptical reader will rightly probe it: no reference entered the bibliography on a model’s say-so — each was verified against its source or the publisher’s record as it was added — and the printed code was executed, not merely proofread. The original notes and the first draft — the thesis, the structure, the judgements, the jokes, and the cartoons — are the authors’ own; and it is the authors who take full and cheerful responsibility for every sentence of the final book, including this one.
The Companion Code
The companion code repository — https://github.com/bloo-mind/masact-code — is organised in three layers, all built and tested today, its README the setup guide. The foundations layer holds small, transparent implementations of the book’s algorithms and mechanisms, dependencies kept to a minimum so readers can see what the code is doing and, as importantly, what it is assuming. The systems layer holds larger projects on a modern orchestration framework — principally LangGraph — substantial enough to fail in educationally useful ways. The frontier layer holds versioned online laboratories against current platforms, kept apart so vendors may rename their APIs at leisure without disturbing the conceptual core.
Exercises close every chapter, from conceptual questions to implementation work. Those that step off the page are marked (lab): anyone assigning coursework can tell which need a pencil, which Python, and which an API key and a budget — though every lab also runs scripted and key-free, so the machinery can be marked offline; and the labs’ numbers being perishable by design, each asks for the model identifier and date beside the results — the durable finding is the comparison, not the absolute rate. One project runs throughout as the book’s spine: an autonomous software-engineering team — an orchestrator that decomposes a task, coder agents, a reviewer, and a tester, working over a real repository under a bounded token budget — cooperative in mission yet genuinely competitive over scarce compute, spanning both halves of the field without contrivance. A few satellite scenarios appear only where the spine cannot honestly reach: a simulated society for the chapter on emergence, and compact, abstract games where strategy is best shown stripped of context.
A Note on Terminology
The field has never agreed whether multiagent is one word, two, or hyphenated. This book writes multi-agent in ordinary prose while preserving the spelling used in names of books, systems, and established terms — a compromise that leaves every camp something to object to, which makes it an appropriately multi-agent outcome. We also say LLM agent — LLM for large language model — even where the model is multimodal: it denotes an agent system whose reasoning and control such a model substantially mediates, not a bare model wandering the machine room.
The Larger Aim
A successful textbook provides ways of thinking that survive the libraries changing, the leaderboards turning over, and this year’s revolutionary architecture quietly acquiring a compatibility layer. The enduring subject is not any particular model or framework: it is the design of intelligent behaviour in a world containing other sources of agency — a world that asks an agent to communicate, coordinate, negotiate, learn, trust, recover from misunderstandings, and occasionally recognise that another agent knows better. These are technical problems but also social ones, and as agents embed more deeply in human institutions the boundary grows harder — and more dangerous — to ignore.
The hope of the book is therefore modest only in the academic sense: to equip the reader to understand the principles, build with sound engineering judgement, evaluate with appropriate scepticism, and contribute to artificial societies capable without being chaotic, autonomous without being unaccountable, and collaborative without scheduling quite so many meetings.
Grab a cup of tea, open a terminal, and let us build some agents.
The Microsoft Office Assistant, Clippy to a generation: a cheerful paperclip that would spring up to observe that “it looks like you’re writing a letter” whether or not you were.↩︎
An open-source agent-orchestration library from the LangChain project: https://langchain-ai.github.io/langgraph/.↩︎