%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}}}%%
flowchart TB
T["Task (origin)"]
NOTE["one seat: initiative,<br/>arbitration, termination"]
S(["Supervisor<br/>the narrow waist"])
W1(["Subagent<br/>sees only<br/>its brief"])
W2(["Subagent<br/>sees only<br/>its brief"])
W3(["Subagent<br/>sees only<br/>its brief"])
G(["Verifier: saw the whole?"])
A["Integrated artefact"]
T -->|"whole task"| S
NOTE -.- S
S -->|"delegates<br/>(brief)"| W1
S --> W3
S --> W2
W1 -.-> S
W2 -.-> S
W3 -.->|"reports<br/>(summarised)"| S
S -->|"integration"| G
G -.->|"reject"| S
T -.->|"original task"| G
G -->|"ACCEPT"| A
W2 ~~~ G
classDef gate fill:#F7E6B5,stroke:#8A5A00,color:#16171B
classDef good fill:#DCEFE2,stroke:#1B6B5A,color:#16171B
classDef world fill:#EFE9DC,stroke:#766F65,color:#16171B
class G gate
class A good
class T,NOTE world
21 Multi-Agent Architectural Patterns
Multi-agent architecture is currently taught by diagram: boxes for agents, arrows for messages, and an animation in which the boxes light up in sequence and something impressive appears at the end. The diagrams are genuinely attractive, and the preface has already registered the book’s suspicion of them, because a diagram answers none of the questions an engineer will need answered at three in the morning. Who saw what, and who should have? Who had the authority to stop this, and why didn’t they? What broke, how quietly, and how far did it spread? This chapter is a catalogue of the field’s recurring architectural shapes — ten of them, from the router to the hierarchical team — examined under exactly those three lenses: information flow, control, and failure modes, with the running cost never far from view, because every arrow in a diagram is also a bill.
The catalogue borrows its discipline from an older tradition that got this right. Architectural patterns — Alexander’s original insight, transplanted into software by the Gang of Four — are not blueprints but named problem–solution pairs, and the form’s whole value lies in the parts enthusiasm omits: the forces that make the problem hard and the consequences section that states, in writing, what the solution costs you. A pattern without its consequences is an advertisement. The agent-systems literature is presently rich in advertisements — every framework showcases the same ten shapes with the failure modes left as an exercise for production — and this chapter’s contribution is to write the consequences sections, using the machinery the book has spent twenty chapters installing.
For it turns out — and this is the chapter’s quiet thesis — that none of these patterns is new. The supervisor dispatching subagents is the Contract Net wearing a lanyard. The blackboard was a named architecture when speech recognition ran on minicomputers. The debate is Chapter 14 with a deployment budget; the reflection loop is Chapter 5’s self-critique given a colleague; the peer network is Chapter 11’s coordination problem accepted in full rather than centralised away. Each pattern, examined honestly, is a piece of this book’s theory wearing overalls — which is excellent news for the reader, because it means every pattern arrives with decades of known behaviour, and the catalogue can be a map from engineering shapes back to the results that explain them, rather than a tour of novelties.
The reader also arrives equipped in a way most pattern catalogues cannot assume: Chapter 20’s runtime is the substrate on which every one of these shapes can be built as a visible increment — several of them in about a page — and the exercises do exactly that. The chapter proceeds from the reading frame itself, the three lenses and the pattern discipline (Section 21.1); through the three families: delegation — routers, supervisors and their subagents, hand-offs, and hierarchical teams (Section 21.2); process — planner–executors and reflection loops (Section 21.3); and the collective shapes — debates, blackboards, and peer networks (Section 21.4); to the section the families exist for: choosing among them, composing them, and recognising the anti-patterns — including the ever-popular architecture of more agents than the task can justify (Section 21.5). Patterns organise agents within one system; what happens between systems, under different owners, is the next chapter’s business.
21.1 How to Read a Pattern: The Three Lenses
The pattern idea entered engineering from an unlikely direction: town planning. Alexander and his colleagues catalogued two hundred and fifty-three recurring problems in the built environment — from the scale of a region down to the placement of a window seat — and for each recorded the pressures bearing on it and the core of a solution reusable, in Alexander’s phrase, “a million times over”, never twice the same way (1977). The Gang of Four transplanted the form into software and demonstrated its social power: a community that shares a pattern vocabulary can discuss architecture in named moves rather than re-derived arguments (Gamma et al., 1994). But both catalogues earn their keep in the same unglamorous place. Alexander’s patterns tell you what a courtyard does to the rooms around it; the Gang of Four’s tell you what indirection does to your stack traces. It is that honesty about costs, more than the naming, that this catalogue takes from its ancestors — and it is what the reading frame below is built to extract.
Three disclaimers, then, before the catalogue opens, about what a pattern is not. It is not a blueprint: patterns are solutions-in-context, and the forces that justify a supervisor for one task dissolve it for another — copying the shape without the context is how cargo cults start. It is not a guarantee: every consequence runs both ways, and the isolation that protects a subagent’s context also starves it. And it is not an architecture: real systems compose several patterns, and the composition must be examined afresh — a matter Section 21.5 takes up. The diagram deserves its own disclaimer, because the diagram is where patterns are usually met: a topology diagram shows structure at one instant and hides all three things that matter — the arrows do not say what is in the messages, the boxes do not say who may interrupt whom, and diagrams, as a genre, depict success. The diagram is the pattern’s advertisement. The lenses are its accounts.
The first lens is information flow, and its questions are: who sees what, when, and at what fidelity? For each agent in the pattern, what context does it receive (Chapter 7’s question), what must it assume about what others know (Chapter 9’s), and what does its role deliberately withhold (Chapter 16’s first clause)? The lens earns first place because the plurality of real coordination failures are information-flow failures — the fact that never reached the agent that needed it, the assumption two agents held in incompatible versions — and because a pattern is, at bottom, a policy about who is told what. The operational test, applicable to every entry in this catalogue: pick one fact the task depends on, and trace it from its origin to the agent that acts on it — counting the hops, the transformations, and the opportunities to be summarised into inaccuracy along the way. Patterns differ more in the length and lossiness of that path than in anything their diagrams show.
The second lens is control, and it asks three questions the boxes-and-arrows never answer. Initiative: who starts work — does activity flow from a coordinator’s dispatch, from the task’s own structure, or from agents volunteering? Arbitration: when two agents disagree — about a fact, an approach, a boundary — where does the disagreement go, and is there anywhere for it to go? Termination: who is empowered to say done, and who to say stop — Section 20.2’s stop conditions writ social, and Chapter 16’s diagnosis made structural, since the MAST verification-and-termination failures are precisely what systems without a termination authority produce. One clarification keeps the lenses honest: control and information can centralise independently. A blackboard centralises information while distributing control; a router centralises control of dispatch while seeing almost nothing. Treating “centralised” as a single axis is the most common way to misread a pattern.
The third lens is failure modes, and its two dimensions are visibility and blast radius. Visibility: does the pattern fail loudly — an exception, a timeout, an empty mailbox — or silently, producing a plausible artefact by a broken route? Silence is the expensive kind: the misrouted task completed confidently by the wrong specialist looks exactly like success until an expert reads the output. Blast radius: when the pattern’s characteristic failure occurs, is one subtask lost, one agent’s work, or the run — and does the failure propagate through the very channels the pattern is proudest of, as the supervisor’s bad decomposition propagates to every subagent with perfect efficiency? Every entry in this catalogue therefore names its characteristic failure — the one this pattern commits by being itself, not by being misconfigured — and says what it looks like in the journal, because Chapter 20 built the instrument and this chapter intends to use it.
A fourth consideration stands permanent guard beside the three lenses: cost. The opening’s aphorism — every arrow is a bill — itemises as follows: an arrow is a model call or a message; a hop is tokens and latency; a sequential dependency is wall-clock time that parallel shapes would not spend — and patterns differ in cost by integer multiples, not percentages, so the pricing belongs in the selection, not the post-mortem. The reading protocol for the catalogue, then, in the order each entry follows: the shape, in a sentence; the pedigree — which of this book’s results the pattern is wearing; the three lenses; the characteristic failure and its signature in the journal; and when to reach for it. Ten patterns, three families. The first family is the one nearly every production system starts with, because it is the shape of asking for help: delegation.
21.2 Delegation: Routers, Supervisors, and Hierarchies
The four patterns in this family share one asymmetric act — an agent with work gives some of it to another — and differ in what the giver keeps. The router keeps nothing: it dispatches and is done. The supervisor keeps the task itself: it parcels out the parts and remains answerable for the whole. The hand-off keeps nothing and gives everything: the task, its state, and the responsibility all cross to the receiver. And the hierarchical team applies the supervisor’s move recursively, keeping a tree. Chapter 10 built the machinery all four run on — decomposition, delegation as the manufacture of commitments, the Contract Net — so the entries below take the machinery as read and do what a catalogue owes: the lenses, the characteristic failure, and the bill.
One inheritance binds the family before any pattern is chosen. To give work away, the giver must understand the work well enough to describe it — and the MAST evidence says this is where delegation systems actually die: under-specified subtasks, overlapping briefs, orphaned corners of the decomposition (Cemri et al., 2025). Every pattern below transfers context in a written brief, which makes the brief the family’s load-bearing artefact; the four shapes are, among other things, four different answers to how many briefs there are, who writes them, and how far a fact must travel through them. The order of presentation is the order of dependence: the supervisor is defined by what the router declines to do, the hand-off by what the supervisor declines to let go, and the hierarchy by applying the supervisor to itself.
21.2.1 The Router
The shape, in a sentence: classify the incoming task and dispatch it, whole, to one of a fixed set of specialists. The router does not decompose, does not integrate, and does not wait; it makes one decision and gets out of the way, which is why it is frequently not an agent at all but a single model call with a menu — the cheapest pattern in the catalogue, adding one classification’s worth of tokens and latency to every request. Its pedigree is division of labour at its most minimal — Chapter 16’s menu files it as a federation, a broker in front of specialist pools — and its human counterpart staffs every hospital: the triage desk, whose job is not to treat anyone but to be quick, cheap, and right about where.
Under the first two lenses the router is almost transparent. Information flow: it reads the envelope, not the letter — a summary, a first message, whatever suffices to classify — and the specialist then receives the full task but almost never the routing rationale, so nobody downstream knows the dispatch was a judgement call that might have gone otherwise. Control: one decision, made once, never revisited. After dispatch the router holds no further authority — no arbitration, no termination, no recourse — and this is both its economy and its defect: the pattern has no mechanism for noticing that its single decision was wrong.
Its characteristic failure, the misroute, is the specimen of silent failure Section 21.1 already put under glass, and the journal shows why it is the detection problem in its purest form: a clean dispatch, a diligent specialist, a confident DONE — a perfectly healthy run of the wrong kind. Nothing in the trace is anomalous, because every component behaved; only the output, judged by someone who knows what the task needed, reveals the miscarriage. The mitigations are correspondingly output-side: an explicit none-of-the-above route that escalates to a human or a generalist (the cheapest insurance in this chapter), confidence thresholds under which the router declines to choose, and a routing evaluation set maintained the way Chapter 24 will insist all evaluations are maintained — because the mix of incoming tasks drifts, and last quarter’s routing accuracy is a fact about last quarter.
Reach for the router when the task stream genuinely partitions: discrete kinds, stable over time, each with a specialist that handles it whole. Watch for the outgrowing signals — categories that blur, tasks that straddle two specialists, a misroute rate that climbs as the world drifts — and when they arrive, resist the temptation to build a cleverer router. A task that no longer fits one specialist does not need better classification; it needs decomposition, and that is the next pattern’s business.
21.2.2 The Supervisor and Its Subagents
The shape: decompose, delegate, integrate. A supervisor owns the task end to end; it splits the work into subtasks, dispatches each to a subagent running in its own fresh context, collects the results, and assembles the whole — the orchestrator-worker arrangement that Chapter 1 introduced as the workhorse of contemporary practice (Anthropic, 2025), that Chapter 10 unmasked as the Contract Net (Smith, 1980), and that Section 20.4 built in an afternoon. The pedigree section of this entry is therefore the shortest in the chapter: no pattern in the catalogue has been vouched for more thoroughly, which is one reason it is reached for first and, on occasion, when it should not be.
Information flow is hub-and-spoke, and the hub is a filter in both directions. Each subagent sees only its brief — isolation that is genuinely a feature: a clean context per subtask (Chapter 7’s scarcest resource, budgeted), parallel work without cross-contamination, no thousand-message transcript to wade through. The same isolation is the bug: a subagent cannot know what its brief omitted, and — Chapter 9’s point in its sharpest form — usually cannot tell that there is anything it does not know. Run the trace-one-fact test and the shape is explicit: origin, supervisor’s reading, brief, subagent, result, supervisor’s integration — two summarisation hops out and two back, with the supervisor’s own context window as the narrow waist through which every fact in the run must pass twice.
Control is total, and totally concentrated: initiative, arbitration, and termination all sit in one seat. This is the pattern’s real virtue under the second lens — the MAST verification-and-termination gap simply does not arise, because there is never any doubt about who may say done — and its structural weakness, because the run is now only as good as one agent’s decomposition and one agent’s integration, and integration is serial: subagents may work in parallel, but their results queue for a single judge. The supervisor is the single point of failure, of judgement, and of throughput, all at once.
The characteristic failure follows from where the judgement lives: the confident decomposition of the wrong shape. Overlapping briefs, and two subagents do the same work in different vocabularies; a gap in the partition, and a corner of the task is orphaned with no thread responsible for it; a plausible split along the wrong seam, and every subagent succeeds at a subtask that should never have existed. The journal signature is the family’s most deceptive: every thread green, every ACCEPT in place, and the integrated artefact wrong — health is a property of threads, failure a property of the run, so the journal must be read at run level, through the reducer’s TeamState, not thread by thread. The structural mitigation is Chapter 20’s: make integration conditional on a verifier that saw the whole, not the parts.
Reach for the supervisor when the task decomposes into subtasks that are independent enough to parallelise and concrete enough to brief — and price it before reaching: Chapter 1 measured the appetite at many times a single agent’s tokens, and Chapter 11’s rule stands — the parallelism must earn the coordination overhead, or the supervisor is an expensive way to do sequentially what one agent would have done in a single context without the summarisation losses. When the work wants to move sideways instead — one specialist finishing its phase and passing the whole task to the next — the delegation is lateral, and it has its own pattern and its own way of going wrong.
21.2.3 The Hand-off
Chapter 10 filed the hand-off as delegation under a friendlier name; the catalogue needs the distinction that filing blurred. A delegator keeps the task and awaits the report; a hand-off relinquishes it — agent A, mid-task, transfers the work, its state, and the responsibility to agent B and exits. It is succession, not subcontracting: the shape of the shift change, the escalation to a senior engineer, the triaged case forwarded to the specialist who will now own it. Under the control lens the distinctive fact is stark — for the duration of one message, nobody holds the task but the message itself, and no third party supervises the seam. There is no supervisor to notice that the transfer went badly, because the whole point of the pattern is that there is no supervisor.
Everything therefore turns on what travels, which is the information-flow lens applied to a single event. The written summary travels. The working context does not: the discarded hypotheses, the caller’s rising irritation, the odd detail A noticed but never wrote down because it had not yet become relevant — Chapter 7 established that context is not a transferable asset by default, and the hand-off is where that lesson collects its fee. Medicine, which runs on hand-offs, learned this in the most expensive way available: clinical handover is a well-documented site of harm, and the response was not exhortation to communicate better but structure — fixed schemas naming the situation, the background, the assessment, the open questions. The engineering translation is direct: a hand-off payload should be a typed artefact — what is done, what is pending, what is odd — never free text and a hopeful tone.
The characteristic failure is the baton-drop: the load-bearing fact that stayed behind. Its journal signature comes in two grades — the benign one, where B, missing something, re-derives it, visible as duplicated tool calls and a re-interviewed user; and the expensive one, where B proceeds without it, invisible until the artefact is wrong for reasons no one downstream can reconstruct. Reach for the hand-off at genuine phase boundaries, where the incoming phase needs different expertise or different tools and the outgoing one has nothing left to contribute; and keep the chains short, because each transfer is a lossy hop, and a long chain of hand-offs is the whisper game played horizontally. The vertical version is next.
21.2.4 The Hierarchical Team
The hierarchical team is the supervisor pattern applied to itself: supervisors of supervisors, a tree in which each internal node decomposes, delegates, and integrates for the subtree below it. The reason to build one is the reason organisations invented middle management — span of control: one supervisor’s context and judgement stretch over only so many subagents and so much task, and past that span the choice is a supervisor overwhelmed or supervision itself delegated. Chapter 16 supplied the pedigree — the hierarchy heads Horling and Lesser’s menu of organisational paradigms, cheap decisions and clear routing traded against fragility at the top (2004) — and the pattern inherits the whole of the supervisor entry above at every internal node, which is an economy for the catalogue and a warning for the builder.
The information-flow lens finds the tree’s defining motion: every level summarises upward and specifies downward. A fact born at one leaf, needed at another, crosses to the common ancestor and back down — summarised at each level on the way up, re-expanded at each level on the way down — and the fidelity loss compounds per hop: Chapter 8’s lossy messages and Chapter 9’s beliefs-about-beliefs, stacked as many levels deep as the tree. The root, which holds the greatest authority, governs by summary of summaries, and knows the run the way a chief executive knows the shop floor.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}}}%%
flowchart TB
Root(["Root supervisor<br/>summary of summaries"])
M1(["Mid supervisor A"])
M2(["Mid supervisor B"])
L1(["Leaf agent"])
L2(["Leaf agent"])
L3(["Leaf agent"])
L4(["Leaf agent"])
Root -->|"specify down"| M1
Root --> M2
M1 --> L1
M1 --> L2
M2 --> L3
M2 --> L4
L1 -.->|"summarise up (lossy)"| M1
L2 -.-> M1
L3 -.-> M2
L4 -.-> M2
M1 -.-> Root
M2 -.-> Root
M2 -.->|"escalate dispute"| Root
Control is where the hierarchy earns something the flat shapes cannot offer: an address for disagreement. When two subagents conflict, the dispute has somewhere to go — up one level, to a node with authority over both — and termination is likewise unambiguous at every scale, each node saying done for its subtree. The lens’s ledger has a debit column, of course: decisions cross levels, so latency stacks with depth, and every internal node is a single point of judgement, so the supervisor’s characteristic failure — the confident wrong decomposition — can now be committed at any level, with a subtree’s blast radius.
The failure the hierarchy adds of its own is the whisper game: the intermediate summary that is confidently, cumulatively wrong. No single hop lies; each middle node compresses in good faith; and the root’s picture drifts from the leaves’ reality by degrees that no one node can see, because each sees only its own hop. The journal signature is divergence with depth: compare the leaves’ raw ToolReturned payloads against the claims in the root’s integration, and the gap widens as the tree grows — which is also the diagnostic, since the journal (unlike the org chart) records both ends of the whisper.
Reach for the hierarchy when the scale is real: a task whose decomposition is itself too large for one supervisor, with subtask families stable enough to justify standing structure. The costs multiply rather than add — depth taxes both tokens and latency at every level — and the dry lesson of organisation theory applies in full: human organisations pay for hierarchy with bureaucracy, and agent hierarchies reproduce the pathology with impressive fidelity, coordination overhead swallowing the gains somewhere around the third level of vice-presidents. The family’s ledger, then: four shapes for dividing labour among agents, priced from a single classification call to a standing tree. What none of them addresses is how work is divided across time — when to think, when to act, when to check — and that is the second family’s subject.
21.3 Process: Planners and Reflection Loops
The two patterns in this family are the smallest multi-agent systems in the catalogue — frequently two agents, sometimes two prompts sharing one model — and their plurality has nothing to do with scale. Each takes a cognitive function that a single agent nominally performs for itself — planning ahead, checking its work — and gives that function a body of its own, with its own context and its own seat at the table. The planner–executor separates deliberation from action; the reflection loop separates production from judgement. In both cases the separation exists because the functions interfere when housed together: an agent in the thick of execution makes a poor strategist, and Chapter 5 established at length that an agent makes a poor judge of its own work.
The family also shares a temperament under the lenses. Where the delegation family’s troubles were chiefly information-flow troubles — briefs, batons, whispers — the process family’s are troubles of timing, and the control lens does most of the work: the plan that outlives the world it was drawn for, the loop that does not know when to stop. Both entries below turn on a single control-lens dial, and in both cases the dial’s setting is the design.
21.3.1 The Planner–Executor
The shape, in a sentence: one agent drafts the complete course of action, and one or more executors then carry it out, step by step, with the plan as the artefact between them. The pedigree runs deep: this is Chapter 5’s plan-and-execute made social, and, in Chapter 4’s terms, the open-loop corner of the architecture spectrum — sense–plan–act, with the sensing and planning in one body and the acting in another. The reasons to make the split are separation of concerns and the plan’s value as an artefact: the planner can be the expensive model with the whole task in context while the executors run cheap and narrow; and a complete, written plan can be inspected, cached, dispatched in parallel where its branches are independent — and, uniquely in this catalogue, approved by a human before anything touches the world. No other pattern produces a full statement of intent in advance of acting on it.
Information flow is the plan, and the plan is one-way in both senses. Downward, the executors know the intent only as written: run the trace-one-fact test on the rationale for a step and it usually dies at the planner’s desk, because plans say what — “step 3: migrate the schema” — and not why, which leaves an executor meeting an obstacle with no basis for safe improvisation. Upward is worse: what execution discovers reaches the planner only if a feedback channel was deliberately built, and in the naive form of the pattern there is none — the freshest information in the system, the news from the world, is the information with nowhere to go.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}, "flowchart": {"rankSpacing": 26, "nodeSpacing": 42}}}%%
flowchart TB
P(["Planner<br/>whole task in context"])
PLAN["Plan artefact: what, not why<br/>inspectable, cacheable, approvable"]
GATE(["Human gate: approved?"])
E(["Executors<br/>cheap, narrow, no authority to deviate"])
WORLD["The world"]
NOX["news from the world:<br/>✗ no channel back to the planner"]
P -->|"complete plan"| PLAN
PLAN --> GATE
GATE -->|"yes"| E
GATE -.->|"no: revise"| P
E -->|"acts on"| WORLD
WORLD -.-> NOX
classDef gate fill:#F7E6B5,stroke:#8A5A00,color:#16171B
classDef risk fill:#F4D7D5,stroke:#A4161A,color:#16171B
classDef world fill:#EFE9DC,stroke:#766F65,color:#16171B
class GATE gate
class NOX risk
class PLAN,WORLD world
Under the control lens the pattern has the strangest property in the chapter: control is exercised by the past. All initiative is spent at the moment of planning; thereafter the system is governed by decisions taken before any of the evidence existed. Termination is admirably clear — the plan has a last step — but arbitration mid-flight is absent by construction: an executor facing a surprise has neither the authority to deviate nor a planner awake to consult. In the two-knob language of Chapter 4, the pattern turns the commitment horizon to its maximum — and that chapter’s warning about the corner, do not trust a stale plan, names the characteristic failure before the entry does.
The stale plan fails exactly as advertised: the world moves — or, more often, the early steps’ own results contradict a later step’s premise — and the later steps execute faithfully anyway. The journal signature is a contradiction with a timestamp: ToolReturned payloads that falsify the plan’s stated assumptions, followed by dispatches that proceed on schedule as though they had not; the accumulation of workaround-shaped behaviour — retries, contortions — around a step that should never have run. The design variable is the replanning cadence, and it is the commitment knob under a new name. At one pole, plan once and execute blind. At the other, replan after every step — which is no longer this pattern at all, but the ordinary closed-loop agent loop, rediscovered. The engineering settles between: event-driven replanning, triggered when a step fails or a precondition breaks, with Chapter 10’s repair menu — retry, reassign, re-plan, abandon coherently — supplying the moves.
Reach for the planner–executor when the world is stable over the plan’s horizon and the steps are expensive, dangerous, or numerous enough to be worth ordering in advance — above all when the plan must be approved: audit, sign-off, and the human gate are this pattern’s unique offer, and for irreversible actions that offer is frequently decisive. It is also the second-cheapest pattern in the catalogue — one substantial planning call amortised over thin execution — provided the replanning stays rare; a plan revised every other step pays the closed-loop price after all, without the closed-loop’s reflexes. Its blind spot is checking: the planner–executor consults the world too late or not at all, and the family’s other pattern exists to make consulting the point.
21.3.2 The Reflection Loop
The shape: an actor produces, a critic judges, the actor revises, and the loop runs until the critic is satisfied or the budget is not. This is the most heavily vouched-for pattern in the family — Chapter 5 supplied the mechanism and its sobering evidence, that a model revising against its own judgement amplifies whatever error signal it holds and cannot conjure one from confidence (Huang et al., 2023); Chapter 14 supplied the multi-agent move, the critic–actor loop, and the arming requirement: a critic with a different brief, different context, and ideally different tools. The catalogue entry’s job is to read that machinery as architecture, because the loop’s behaviour is decided almost entirely by two design choices the diagram does not show.
The first is the critic’s information diet, which is the information-flow lens applied to one agent. A critic shown only the draft judges what a draft displays — fluency, structure, confidence — which are the very qualities that misled the actor, and the loop converges on polish. A critic given the brief can at least judge compliance. A critic armed with tools — the test suite, the execution sandbox, retrieval against the sources — holds an error signal that exists outside both agents’ weights, and the amplification lesson becomes an engineering rule: the loop amplifies what the critic holds, so what the critic holds is the design decision. Feed it grammar and it will amplify grammar, very thoroughly, at a model call per round.
The second is termination, which the control lens has been waiting for. Let the critic decide and the loop risks never ending, because an objection can always be manufactured — perfectionism is cheap to generate; let the actor decide and the loop is decorative. The workable designs bound the loop twice over: a hard cap on rounds, and a convergence test on the traffic — are the diffs shrinking, are the objections new or repeats — with Chapter 14’s argumentation machinery governing the middle: the actor may rebut rather than comply, which keeps a wrong critic from steering, at the price of adjudicating the dispute.
Set those two dials badly and the pattern fails at one of its two poles. Placation is convergence by politeness: the objections grow vaguer each round, approval arrives because agreeableness is well represented in the weights, and the loop reports success having changed nothing that mattered. The polish loop is the opposite failure: no convergence at all, each revision opening a new front, revision five resembling revision three. Both signatures are legible in the journal without reading a word of the artefact — critique length and specificity decaying against near-empty diffs in the first case; the round cap struck, diffs refusing to shrink, and revisions cycling in the second — which makes the reflection loop the easiest pattern in the catalogue to instrument, and the least excusable to run unwatched.
Reach for the reflection loop when the artefact has checkable properties and the critic can be armed with the checks; price it in rounds, since each round is roughly a full actor pass plus a full critic pass, and the stop condition doubles as the budget policy. When no external signal exists to arm the critic with, decline the pattern: the loop will buy fluency and confidence, not correctness — Chapter 5’s verdict, restated at production rates. Both process patterns, note, keep the conversation to a fixed pair of seats: one planner and its executors, one actor and its critic. The third family unfixes the seating — many voices, shared floors, no centre at all — and the bills grow accordingly.
21.4 Collective Shapes: Debates, Blackboards, and Peer Networks
The three shapes in this family share a refusal: no agent owns the task. Authority is either dissolved outright or vested in something other than a worker — and what it is vested in is the axis that separates the entries. The debate vests it in a judge, who hears everything and does none of the work. The blackboard vests it in an artefact, a shared workspace through which specialists collaborate without addressing one another. The peer network vests it in nothing at all, and lives with the consequences. These are the catalogue’s closest descendants of the book’s classical heart — argumentation, shared state, conventions, emergence — and each entry below leans on a chapter of theory rather than restating it.
They are also, collectively, the expensive end of the catalogue, and the reason is worth stating up front: many voices means many model calls, and shapes without an owner make attribution — who decided this? — a genuine question rather than a lookup. The pay-off, where there is one, is the thing no delegation shape can manufacture: judgement pooled across genuinely different vantage points, work composed from contributions nobody planned. The family’s discipline is to be sure the task needs that before paying for it.
21.4.1 The Debate
The shape: several agents answer the same question, see one another’s answers, argue in rounds, and a verdict is extracted — by convergence, by vote, or by a judge. This is the best-audited pattern in the book, and the audit is the pedigree: Chapter 13 priced the bargain at its core — jurors’ independence spent to buy a pooling of their information — and Chapter 14 did the rest, from the consensus form and its measured gains through the sharpest reason it works: a rival obliged to attack surfaces the considerations a confident model will not volunteer against itself. One distinction from that audit bears repeating as catalogue architecture, because practice blurs it constantly: the consensus debate among peers who revise toward agreement (2024) and the adversarial debate staged for a weaker judge, where the debaters’ job is to disagree as informatively as possible (Irving et al., 2018) are two designs answering to one name, and they fail differently — the first by agreeing too easily, the second by rewarding persuasion wherever persuasion and truth come apart.
Under the information-flow lens the debate sits at the opposite pole from the supervisor’s subagents: total transparency, every debater seeing every position each round — pooling as the whole point. The lens’s sharp question is instead about the judge, whose diet is arguments and nothing else: a judge that cannot check claims against the world can only weigh the exchange on its internal merits, which is the scalable-oversight wager restated as a design fact — refereeing must be genuinely easier than originating, for this pattern, or the verdict is fluency measured by fluency. Control is the tidiest in the family: a fixed round count, then the verdict; termination never in doubt.
The characteristic failure is the chorus: convergence by conformity rather than evidence. The confident voice pulls the field; positions collapse in the first round; and where the debaters share training, prompts, or sources, the majority amplifies the shared error — Chapter 13‘s correlated jurors, billed at debate prices. The journal signature is measurable without judging a single claim: the positions’ diffs collapsing after round one, later rounds introducing no argument not already on the table, agreement arriving faster than scrutiny plausibly could. A debate whose transcript shows no mind changed for a stated reason was a poll with overheads.
Reach for the debate at verdicts, not production: verification gates, contested judgements, answers where being wrong is expensive, the claims are checkable, and the debaters plausibly hold different pieces of the picture. Insist on genuine diversity in the seats — different models, prompts, or evidence — because N copies of one distribution deliberating is a single opinion sampled N times, at N debaters times R rounds the steepest per-question multiplier in the catalogue. Where the claims are matters of taste rather than checkable fact, the debate audit has already returned the verdict: spend the tokens elsewhere. The debate shares everything by broadcast, every round; the family’s second shape shares through a persistent artefact instead, and buys a different economy.
21.4.2 The Blackboard
The shape: a shared workspace on which specialists post, read, and extend partial solutions, with the answer assembling on the board rather than in any head. The pedigree is the oldest in the catalogue and already in the book: Chapter 9 traced the shared store to Hearsay-II and noted that the running example’s blackboard is a stack of real ones — the repository, the issue tracker, the shared plan — and Chapter 11 drew out Nii’s deeper point, that the board is a coordination mechanism: decoupled specialists, opportunistic contribution, nobody invoking anybody (1986). The catalogue entry’s contribution is the component that description manages to omit.
Section 21.1 used the blackboard as its specimen of centralised information with distributed control, and the claim survives on one refinement: what is distributed is the initiative — any specialist may volunteer whenever the board offers it work. But the control lens asks two further questions, and both point at a centre. When three specialists volunteer at once, who gets the floor? And who decides the board now holds a solution — or never will? Classical blackboard systems answered plainly: a scheduler rated the pending contributions and chose, every cycle, what ran next — and the control problem proved so central that Hayes-Roth’s BB1 architecture gave the scheduling deliberations a blackboard of their own (1985). The modern translations — trigger rules, watch conditions, an event loop — inherit the same truth. The blackboard is not a leaderless pattern; it is a pattern whose leader has been renamed infrastructure, and every question you decline to answer in the scheduler you have answered by accident.
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "edgeLabelBackground": "#FAF7F0", "clusterBkg": "#EFE9DC", "clusterBorder": "#766F65"}}}%%
flowchart TB
BB[("Blackboard<br/>the answer assembles here")]
SCHED(["Scheduler<br/>rates, grants the floor,<br/>declares done"])
S1(["Specialist A"])
S2(["Specialist B"])
S3(["Specialist C"])
STALE["stale read hazard"]
STAMP["stampede hazard"]
BB <-->|"post, read, extend"| S1
BB <--> S2
BB <--> S3
BB -->|"pending contributions"| SCHED
SCHED -.->|"activates"| S1
SCHED -.-> S2
SCHED -.-> S3
STALE -.- BB
BB ~~~ STAMP
STAMP -.- SCHED
classDef gate fill:#F7E6B5,stroke:#8A5A00,color:#16171B
classDef world fill:#EFE9DC,stroke:#766F65,color:#16171B
class SCHED gate
class BB,STALE,STAMP world
The characteristic failures follow from the two ways the board mediates badly. The stampede: one juicy posting wakes every specialist at once, and the team pays for the same follow-up several times over — the journal shows a burst of near-simultaneous dispatches hanging off a single event, doing interchangeable work. And the stale read: a specialist works from board state that changed beneath it — the lost update in its architectural dress — and the journal shows an artefact contradicting postings that predate its delivery. Both mitigations are Chapter 11 verbatim: claims and locks on regions of the board, triggers specific enough not to summon the whole company, versions on postings so that staleness is at least detectable.
Reach for the blackboard when the specialists are heterogeneous, the solution assembles from partial contributions, and the composition order cannot be scripted in advance — the conditions under which opportunism beats any pipeline you could draw. Its economics are the family’s gentlest: agents idle until the board gives them cause, there are no rounds to multiply, and the board itself is a free audit trail — the pattern’s information flow and its journal are nearly the same object. What it retains is a centre: the board, and the scheduler behind it. The family’s last shape gives up even that.
21.4.3 The Peer Network
The shape: agents addressing one another directly, no coordinator, no shared board, no judge — coordination, where it happens, arising from local interactions under shared conventions. The pedigree spans the book’s widest arc: Chapter 11’s conventions and social laws hold the whole arrangement up, since with no centre to consult, agreement must be pre-installed as rules of the road; and Chapter 18 supplied both the promise — flocks, markets, societies, global order from local rules — and the standing obligations that come with running emergence on purpose.
The lenses return readings unlike anything earlier in the catalogue. Information flow is local: each agent sees its neighbourhood, and no agent — none — sees the run. There is no narrow waist to throttle a fact and no root to garble it, which is the pattern’s genuine strength; there is also no place where the whole is known, which is everything else. Control is distributed in all three of the control lens’s senses at once: initiative everywhere, arbitration nowhere — a dispute between peers settles by convention or persists — and termination is a global predicate that no local agent can evaluate, a difficulty venerable enough to have its own classical literature. Asking a peer network “are you finished?” is not a message; it is a research question.
The virtues are the ones hierarchy cannot buy: no bottleneck, no single point of failure, degradation by degrees rather than collapse, scale without redesign. The bill is the rest of the book: the consistency machinery in full, because nothing keeps the peers’ pictures coherent for free, and the emergence obligations in full, because the system’s aggregate behaviour is now an emergent property to be monitored rather than a design to be verified. The characteristic failure is incoherence: the network partitions into camps, each internally consistent and jointly contradictory, work duplicated across them — or a local coupling amplifies into a cascade, the flash crash being the canonical production example. The journal signature is its own diagnosis: every hop recorded, and nowhere a decision — messages circulating without convergence, the same subtask alive in three places, no thread anywhere that could be pointed to as where the run went wrong, because no thread was in charge of the run.
Within a single system, under a single owner, the honest advice is blunt: a centre is nearly always affordable and nearly always worth it, and the peer network is rarely the right choice. Its real domain is where it is not a choice at all — agents under different owners, no party entitled to coordinate the others, any centre a liability or a fiction — which is to say the world between systems rather than within them, and Chapter 22’s subject. With the peer network the catalogue is complete: ten shapes, three families, each priced under the same lenses. What no family answers alone is the question that sent an engineer to a catalogue in the first place — which of these, for this task, in what combination — and that is the business of the section the families exist for.
21.5 Choosing, Combining, and the Anti-Patterns
Chapter 19’s decision procedure opened with a question it could only forward — what topology does the task actually need? — and this section is where the question is answered properly. The rubric is short enough to state in one sentence: match the pattern’s information and control shape to the task’s dependency structure. Everything the catalogue established points this way. A pattern is a policy about who is told what and who decides; dependencies are what make one agent’s work bear on another’s; so the pattern fits the task when its policies serve the dependencies the task actually has — and chafes, expensively, when they serve dependencies the task does not have, which is what an architecture chosen from a showcase usually does.
Chapter 11’s taxonomy now earns its keep as a diagnostic. A task dominated by task–subtask dependencies — a whole that splits into parts needing integration — is asking for a supervisor, and, when the parts split again, a shallow hierarchy. Dominated by producer–consumer dependencies — stages, each feeding the next — it is asking for a pipeline of hand-offs, or a planner–executor when the stage structure is knowable in advance. Shared-resource dependencies point at the blackboard’s claims and locks — or, when the contested resource is the budget itself, at Chapter 15’s market machinery. Simultaneity dependencies are the hard case that no topology dissolves: they demand the full coordination machinery wherever they appear, under any pattern. And a task whose verdicts matter more than its throughput — where the question is not how to produce the artefact but whether to believe it — is the debate’s and the reflection loop’s territory. Run the diagnosis before shopping, because the diagnosis is about the task and stays true; the shop rearranges its window weekly.
| What the task is dominated by | Pattern to reach for | What the pattern serves |
|---|---|---|
| Task–subtask dependencies — a whole that splits into parts needing integration | The supervisor; a shallow hierarchy when the parts split again | Decomposition with one seat answerable for the whole |
| Producer–consumer dependencies — stages, each feeding the next | A pipeline of hand-offs; a planner–executor when the stage structure is knowable in advance | Ordered succession through phases |
| Shared-resource dependencies — contention for one limited thing | The blackboard’s claims and locks; Chapter 15’s market machinery when the contested resource is the budget itself | Arbitrated access to the shared resource |
| Simultaneity dependencies — actions that must co-occur | — | The hard case no topology dissolves: the full coordination machinery, wherever it appears, under any pattern |
| Verdicts that matter more than throughput — whether to believe the artefact, not how to produce it | The debate; the reflection loop | Judgement pooled or externalised, not production |
There is one move upstream of even this, and the coordination chapter named it: decomposition manufactures the dependencies that topology must then serve. Split the task one way and the parts are independent, needing hardly any pattern at all; split it another and everything touches everything, and no topology can save the run — the cheapest dependency to coordinate is still the one designed out. So the right order of operations is: choose the decomposition first, read the dependency structure off it, and let the pattern follow. An engineer who starts from the pattern — who has decided on a hierarchy and goes looking for a way to cut the task into a tree — has the procedure backwards, and will make the task fit the org chart with the results that method produces wherever it is tried.
Real systems, meanwhile, seldom deploy a pattern; they deploy several, nested. A supervisor whose workers are reflection loops; a router in front of planner–executor pipelines; a debate wired in as the verification gate before a supervisor integrates — composition is the norm, not the exception, and the book’s own runtime is already an instance: Chapter 20’s team is a supervisor composed with an armed critic, and the five lines that gate integration on the critic’s ACCEPT are the join. The catalogue’s entries are not rival architectures to pick among but a vocabulary of parts — which is what the Gang of Four’s catalogue was for, too.
Composition, however, voids the entries’ warranties. Each pattern’s consequences section described the pattern alone; couple two and the failure modes do not add — they interact, and the composition is a new entry in the catalogue, owed its own reading under the lenses regardless of how clean its components’ records are. The supervisor of reflection loops multiplies the loop’s round budget by the number of workers, and its green-thread blindness now conceals placation: a worker whose critic has gone agreeable reports ACCEPT like every honest thread, and the supervisor cannot tell politeness from verification. The router in front of pipelines converts its misroute from a wrong answer into a wrong process — the whole pipeline executing faithfully on the wrong premise, polish applied at every stage to an artefact that should not exist. None of these hybrids’ failures belongs to any component; they live in the joins, which is Chapter 18’s lesson at architectural scale: composition is emergence, in miniature, on your payroll.
The catalogue closes with three shapes that recur in practice and fail the lenses on contact — anti-patterns, named so they can be declined by name. The first is the group chat: every agent in one shared transcript, coordination by free text, the shape every framework demo reaches for because it is the shape of a chat window. The lenses make short work of it. Information flow is total but unstructured — every agent pays context for every utterance, relevance decaying as the transcript grows; control is nobody’s — no termination authority, no arbitration beyond whoever speaks last (Chapter 16’s diagnosis, verbatim); and its failures are Chapter 8’s ambiguities restored to office: was that a report, a request, or a promise? Chapter 20 delivered the verdict in code — a mailbox and a schema beat a group chat — and the margin, recall, is widest when things go wrong.
The second is the everything-agent: one agent, forty tools, every duty — the refusal to decompose, dressed as simplicity. It is not strictly a multi-agent anti-pattern, being the decision not to build a multi-agent system at all, and up to a point that decision is sound — Chapter 1’s framework spends most of its questions trying to return it. The anti-pattern begins where the point ends: the brief too large to hold, the context a jumble of unrelated concerns (Chapter 7’s budget spent on standing instructions rather than the task), evaluation impossible because everything is one agent’s fault. The tell is an instruction list that reads like an organisation’s staff handbook addressed to a single employee. The remedy is not more agents; it is the diagnosis above — find the dependency structure, and split where the dependencies are thinnest.
The third is the gratuitous agent, and it is the everything-agent’s opposite and the more expensive vice: agents added because the org chart looked bare — a Strategist to accompany the Planner, a Quality Lead alongside the Reviewer, roles Chapter 16 would recognise as costumes with salaries. The lens test is subtraction: remove the agent and see what changes. If the answer is nothing but the bill — its messages summarised and forwarded, its approvals never once withheld, its subtasks doable by their recipients — the agent was decoration, and every arrow it anchored in the diagram was overhead purchased for theatre. Chapter 1 had a name for the genre — several prompts in a trench coat — and the catalogue’s closing maxim is the same sentence with an invoice attached: the best multi-agent architecture is frequently fewer agents than you currently have.
Ten patterns, three families, three refusals: the chapter’s work is done, and its method is worth stating once in retrospect, because the method is the durable part. Every entry was read the same way — shape, pedigree, information flow, control, failure, cost — and every pedigree landed somewhere earlier in this book, because the patterns are not inventions but consequences: the supervisor is what delegation looks like when Chapter 10’s machinery is bought whole; the debate is Chapter 14 with a deployment budget; the blackboard is Chapter 11 given a user interface. An engineer who has the lenses does not need this catalogue to stay current, because next year’s pattern — whatever the diagram looks like — will answer the same six questions, and its diagram will still omit the same three.
| Pattern | Characteristic failure | Journal signature | Structural mitigation |
|---|---|---|---|
| Router | The misroute — a task confidently completed by the wrong specialist | A healthy run of the wrong kind: clean dispatch, diligent specialist, confident DONE, anomalous nowhere |
A none-of-the-above route; confidence thresholds; a routing evaluation set kept current |
| Supervisor and subagents | Confident decomposition of the wrong shape — overlapping briefs, an orphaned corner | Every thread green, every ACCEPT in place, the integrated artefact wrong — read at run level, via TeamState |
Gate integration on a verifier that saw the whole, not the parts |
| Hand-off | The baton-drop — the load-bearing fact that stayed behind | Duplicated tool calls, a re-interviewed user (benign); an artefact wrong for unreconstructable reasons (expensive) | A typed payload — done, pending, odd; keep the chain short |
| Hierarchical team | The whisper game — an intermediate summary confidently, cumulatively wrong | Divergence with depth: the leaves’ raw ToolReturned payloads against the root’s integration |
Keep the tree shallow; the journal records both ends of the whisper |
| Pattern | Characteristic failure | Journal signature | Structural mitigation |
|---|---|---|---|
| Planner–executor | The stale plan — later steps executed faithfully after the world, or an earlier result, moved | ToolReturned payloads falsifying the plan’s assumptions, then dispatches proceeding on schedule; workaround-shaped retries |
Event-driven replanning, with Chapter 10’s repair menu — retry, reassign, re-plan, abandon |
| Reflection loop | Placation (convergence by politeness) or the polish loop (no convergence at all) | Critique specificity decaying against near-empty diffs; or the round cap struck, diffs refusing to shrink | Arm the critic with external checks; a hard round cap plus a convergence test on the diffs |
| Pattern | Characteristic failure | Journal signature | Structural mitigation |
|---|---|---|---|
| Debate | The chorus — convergence by conformity rather than evidence | Positions collapsing after round one, later rounds adding nothing, agreement faster than scrutiny plausibly allows | Genuine diversity in the seats — models, prompts, evidence; restrict to checkable claims |
| Blackboard | The stampede (one posting wakes every specialist) and the stale read (board state moved beneath the work) | A burst of near-simultaneous dispatches off one event; an artefact contradicting postings that predate it | Claims and locks on board regions; triggers specific enough not to summon the whole company; versions on postings |
| Peer network | Incoherence — jointly contradictory camps, or a local coupling amplifying into a cascade | Every hop recorded and nowhere a decision: circulation without convergence, one subtask alive in three places | The full Chapter 11 consistency machinery; Chapter 18’s emergence monitoring; within one owner, prefer a centre |
What every pattern here has quietly assumed is a single proprietor: one party that owns the agents, writes the briefs, reads the journal, and may rewire the topology at will. Relax that — let the boxes in the diagram belong to different companies, with different interests and no shared harness — and the vocabulary changes register: a message format becomes a treaty, a role becomes a counterparty, and a pattern becomes a protocol, which nobody controls and everybody must speak. That is the world between systems rather than within them, and it is where the book goes next.
21.6 Summary
- A pattern without its consequences section is an advertisement. The catalogue’s discipline comes from Alexander and the Gang of Four: named problem–solution pairs with forces and costs stated in writing — and the three lenses that organise every entry here are information flow (who sees what), control (who decides and who can stop it), and failure modes (what breaks, how visibly, with what blast radius).
- The delegation family trades simplicity against bottleneck. The router is the cheapest pattern and fails silently downstream; the supervisor buys decomposition and context isolation at the price of a single point of failure and judgement; hand-offs drop batons; hierarchies add reach and play the whisper game — information degrades at every level.
- The process family shapes work in time. The planner–executor separates deliberation from action and fails when the world outruns the plan — replanning cadence is the design variable; the reflection loop externalises self-critique and degrades into mutual politeness unless the critic is armed with tools and the stop condition is designed rather than hoped for.
- The collective family spends the most and needs the most justification. Debate pays where claims are checkable and information asymmetric, per Chapter 14’s audit; the blackboard’s hidden component is its scheduler, and it fails by stampede; the peer network buys robustness with the full Chapter 11 consistency bill and Chapter 18’s emergence obligations attached.
- None of the ten is new, and that is their strongest feature. Supervisor is the Contract Net, blackboard is 1980s speech recognition, debate is computational argumentation, reflection is metacognition with a colleague — each pattern arrives with decades of known behaviour, and the catalogue maps engineering shapes back to the theory that predicts their failures.
- Patterns compose, and compositions have emergent failure modes. A supervisor of reflection loops, a router in front of pipelines — nesting is the norm; but each composition creates failure interactions neither component had alone, and the composed system must be examined under the lenses afresh, not certified by its parts.
- Topology follows task. Match the pattern’s information and control shape to the task’s dependency structure — Chapter 11’s dependency kinds are the diagnostic — and remember the anti-patterns: the group chat, the everything-agent, and the gratuitous agent. The best multi-agent architecture is frequently fewer agents than you currently have.
- Within one system, patterns; between systems, protocols. The moment the boxes in the diagram belong to different owners, vocabulary stops being a style choice and becomes an interoperability contract — which is Chapter 22.
21.7 Exercises
Exercise 1. Six systems, each described by its vendor. (i) “Dispatch reads each ticket’s subject line and forwards the ticket, whole, to one of five expert bots; Dispatch never sees the ticket again.” (ii) “TeamLead splits your feature request into subtasks, hands each to a fresh worker, and assembles the final pull request; workers never see one another’s work.” (iii) “Specialists post partial results to a shared Canvas; any specialist whose trigger matches may extend what it finds there; each cycle, our Engine chooses which pending contribution runs.” (iv) “Architect writes the complete migration script; Runners execute it step by step overnight; your team signs the script off at five o’clock.” (v) “All agents share one channel and speak freely; the task is complete when the channel has been quiet for five minutes.” (vi) “Author drafts; Editor reviews against our built-in style checker and may demand revisions until it is satisfied.” (a) Name the pattern or anti-pattern each vendor is selling. (b) For each, give the two-axis reading Section 21.1 insists on — is information centralised, is control centralised — and where the two answers differ, say what the difference consists of, identifying the system whose leader has been renamed infrastructure. (c) Answer the control lens’s three questions — initiative, arbitration, termination — for each system, and single out the system in which nobody holds the authority to stop the work, the system whose termination rule mistakes silence for completion, and the system whose done-sayer can manufacture objections for ever. (d) Name each system’s characteristic failure, classify it loud or silent in Section 21.1’s sense, and identify the one system whose characteristic failure no reading of the journal can catch, however well instrumented.
Exercise 2. The running team places an intake router in front of three specialist coder pools; a routed specialist run costs W = 8{,}000 tokens. The router’s self-reported confidence is calibrated: on a fraction h = 0.2 of incoming tasks it is uncertain and its dispatch accuracy is 0.6; on the remaining tasks it is confident and its accuracy is 0.98. A misrouted task completes confidently — Section 21.2’s healthy run of the wrong kind — and the wrongness surfaces downstream at a cost of D = 30{,}000 tokens of expert reading and redo. Two policies: always dispatch, which routes every task to the chosen specialist; and none-of-the-above, which sends the uncertain fraction to a generalist instead, at 14{,}000 tokens a run, the generalist’s own misroutes rare enough to ignore. (a) Compute the always-dispatch misroute rate and the expected token cost per task under each policy. (b) Find the break-even downstream cost D^* at which the escalation route pays for itself, and express it as a multiple of W. (c) The task mix drifts: the uncertain fraction climbs to h = 0.5 over a quarter while both accuracies hold. Recompute both policies and the gap between them, and say what the movement demonstrates about Section 21.2’s warning that last quarter’s routing accuracy is a fact about last quarter. (d) The companion repository’s frontier/patterns/signatures.py gives its misroute detector the signature is_misroute(r, correct_specialist) — alone among the module’s detectors it takes an argument the journal does not carry. Say why no journal-only detector could replace it, and name the one line the router could nonetheless write into the journal that would make the dispatch auditable after the fact.
Exercise 3. Model the whisper game. In a uniform hierarchy of depth d — the root at depth 0, leaves at depth d — a fact born at one leaf and needed at a leaf in another subtree of the root crosses d summarisation hops up and d specification hops down, and each hop independently preserves a given load-bearing detail with probability f = 0.9. (a) Write the end-to-end survival probability as a function of d and evaluate it for the flat supervisor (d = 1) and for trees of depth 2 and 3. (b) Find the greatest depth at which a load-bearing detail still has an even chance of arriving intact, and set the answer beside Section 21.2’s remark about the third level of vice-presidents. (c) A run carries 20 such cross-tree facts: compute the expected number garbled at depth 3, and say which two populations of journal entries Section 21.2’s diagnostic compares to observe the damage — and why the org chart cannot. (d) Find the per-hop fidelity g a depth-3 tree would need for its cross-tree facts to survive as well as the flat supervisor’s, and state the engineering consequence: what happens to the required quality of briefs and summaries as a tree deepens, and why that cost is multiplicative rather than additive.
Exercise 4. Chapter 20’s wish list promised the router and the reflection loop as visible, testable increments on the runtime, and this chapter’s opening priced several such shapes at about a page apiece; make both good, working in your own copy of the companion repository’s foundations/ layer. (a) The router: write route(task, menu, classify, journal) — one classification call against a menu of specialists plus the none-of-the-above escape of Section 21.2, escalating to a generalist, and journalling the dispatch with its rationale, the entry Section 21.2 notes almost never survives into the trace. (b) The reflection loop: write reflect(brief, draft, actor, check, cap, journal) — the actor revises against objections held by an external check (the armed critic of Section 21.3), the loop bounded twice, by a clean check and by a hard cap, and every round writing a Reviewed journal entry carrying the round number, the diff size, and the count of open objections. (c) Demonstrate both on scripted stubs in the runtime’s FakeClient manner: a correct dispatch, a none-of-the-above escalation, and a loop that converges in two rounds; then show that the journal your loop writes is legible to is_placation in the companion repository’s frontier/patterns/signatures.py, and state which single field makes it so. (d) Say where each increment plugs into foundations/team.py’s run_team — the router in front of which dispatch, the loop between which two seats — and price each addition in extra model calls per task, in Section 21.1’s every-arrow-is-a-bill terms.
Exercise 5. The supervisor gates integration on a verdict, and the verdict has a price. A candidate patch carries a latent defect with probability q = 0.2; a defect that ships costs D tokens downstream. Three gates are on offer: a single armed reviewer pass at 2{,}000 tokens, catching a present defect with probability 0.5; a debate of three genuinely diverse seats — different models or prompts — over two rounds at 1{,}500 tokens per debater-turn plus a 1{,}000-token judge, catching with probability 0.9; and the same debate staffed by three copies of one model and one prompt, at the same price, catching with probability 0.55. (a) Write the expected total cost per patch — gate plus expected shipped-defect cost — for each gate, evaluate all three at D = 40{,}000 and at D = 250{,}000, and rank the gates at each price. (b) Derive the break-even D^* at which the diverse debate overtakes the single reviewer. (c) Show that the correlated debate is beaten by the single reviewer until D exceeds 800{,}000 tokens, and state what the comparison proves about what the debate’s premium actually purchases — Section 21.4’s warning that N copies of one distribution deliberating is a single opinion sampled N times, priced. (d) Refine the diverse gate with Chapter 13’s machinery: let each diverse seat surface the defect independently with probability \tfrac{1}{2}, so a debate of N seats catches with probability 1 - 2^{-N}. Compute the catch rates and gate costs at N = 3 and N = 5, find the D above which the two extra seats pay, check the verdict at D = 250{,}000, and state the assumption on which the whole refinement stands or falls.
Exercise 6. The journal census in the companion repository’s frontier/patterns/signatures.py covers seven failure signatures, but the hand-off’s baton-drop is not among them; supply it. (a) Design the journal vocabulary: a handoff: detail marking the seam — sender, receiver, timestamp — read against the module’s existing dispatch: entries and an ask-user: entry for questions put to the user. (b) Implement is_baton_drop(journal) for the benign grade Section 21.2 describes — after the seam, the receiver re-derives what the sender already held: a tool step repeated across the seam, or the user re-asked an answered question — and exhibit it firing on a dropped-baton trace and staying silent on a typed-payload hand-off, in the injections module’s broken-and-healthy manner. (c) Now write the expensive-grade trace: the receiver proceeds without the load-bearing fact, and the artefact is wrong for reasons no one downstream can reconstruct. Show it is journal-indistinguishable from your healthy trace, and name the shipped detector that already lives with this exact predicament, together with the module’s standing reminder it encodes. (d) The chapter’s structural mitigation is the typed payload — what is done, what is pending, what is odd. Say what typing the payload changes about detectability, not just prevention: which absence a detector could flag at the seam itself, before any duplicated work has had time to appear.
Exercise 7. A detector is the operational definition of its signature, so probe three of the shipped definitions in frontier/patterns/signatures.py at their boundaries, verifying every claim by running the detectors. Construct: (a) the cosmetic replan — a planner–executor journal in which a tool return falsifies step s2, a replan: entry follows that names no step, and s2 is then dispatched anyway; show is_stale_plan stays silent, and say which behaviour of the detector launders the contradiction. (b) The interleaved stampede — four dispatches off one trigger onto one board region, each separated from the next by its own ToolReturned; show is_stampede stays silent, and explain which property of the book’s stampede definition the detector’s reset is enforcing. (c) The unlogged placation — a review sequence ending in an accept whose entry carries no open= count; show is_placation stays silent however agreeable the critique was. (d) Adjudicate the three misses under Section 21.1’s definitions: which is a detector bug, which a defensible tolerance — argue from what the chapter says a stampede is — and which an instrumentation gap whose fix belongs in the logging discipline rather than the detector; then patch exactly the one you called a bug, and show the patch catches the offending trace while the module’s shipped healthy runs stay quiet.
Exercise 8. Composition voids the warranties; produce the receipts. (a) The running team’s supervisor is given w = 4 workers, each upgraded to a reflection loop with round cap R = 3, a round costing one actor pass and one critic pass; the supervisor itself spends one decomposition call and one integration call, and every call averages 1{,}800 tokens. Compute the composed system’s worst-case model calls and token bill against the flat supervisor whose workers make one pass each, and state the multiplier the composition applies to the workers’ share of the bill — Section 21.5’s integer multiples, exhibited. (b) Read the two specimens in the companion repository’s frontier/patterns/compose.py and reconcile an apparent contradiction: Section 21.5 says the supervisor of reflection loops cannot tell politeness from verification, yet the repository’s is_placation catches the laundered placation in supervisor_of_reflection’s journal. Who reads what, and when — and which rule of Section 21.2 about run-level reading does the reconciliation instantiate? (c) Build the third specimen: a supervisor whose verification gate is a debate, wired exactly as Section 21.2’s mitigation prescribes — and let the debate chorus. Write the composed journal, show is_chorus still fires on it, and state the new failure precisely: what the supervisor’s certification is worth when the gate that saw the whole returned a verdict that pooled nothing. (d) Generalise from the three specimens: which component failures remain detectable after composition, which class of failure is new and detector-less, and what one-line journal discipline at the join — what must the certifier log — would make the new class legible.
Exercise 9. Five briefs arrive at the running team’s door; run Section 21.5‘s procedure on each — decomposition first, dependency structure read off it, pattern last. (i) “Migrate our forty test modules from one test framework to another; the modules are independent, and the result must land as a single pull request.” (ii) “Production incidents flow through triage, reproduction, patching, and post-mortem; each phase needs different tools; one incident is in flight at a time.” (iii) “Three specialists — schema, query plans, caching — must jointly improve one slow endpoint; the improvements feed on one another in an order nobody can script in advance.” (iv) “Leadership wants a Strategy Agent, an Innovation Agent, and a Quality Culture Agent added alongside the existing four seats, to raise ambition.” (v) “Refactor the authorisation module while three feature teams keep landing changes to it daily.” For (i)–(iii): (a) name the dominant dependency kind and the pattern Table 21.1 prescribes, with a sentence on why the nearest runner-up pattern chafes; and (b) name the characteristic failure the choice signs you up for, its journal signature, and the day-one mitigation, per its family’s failure card (Table 21.2, Table 21.3, or Table 21.4). For (iv): (c) run the subtraction test in writing — state what would have to be true of the three agents’ traffic for them to survive it, and what Section 21.5 predicts the traffic will actually show. For (v): (d) show that as posed the brief is dominated by dependencies no topology dissolves, then re-decompose it, in Section 21.5’s upstream sense, so that the dependency structure thins — naming the pattern, if any is still needed, that fits what remains.
Exercise 10 (lab). The pattern-swap, first hermetically and then against a live model. Hermetic: from the companion repository, run python -m frontier.patterns.run and the suite tests/test_frontier_patterns.py; confirm the census flags all eight injected failures with every healthy counterpart silent, and state why the pattern-swap table this run prints demonstrates the instruments rather than measuring any pattern. Live: pick one small task from the running team’s world with a planted, checkable defect — a function whose failing test is given — and hold one model, one temperature, and one budget fixed across a single-agent baseline and three topologies: a supervisor that decomposes into two briefs and integrates behind a verifier; a debate of three seats over two rounds with a judge; and a peer network of three peers messaging directly under two conventions — address one peer at a time, and post “AGREED” with the patch hash when satisfied — the run ending when all three have agreed or a hard cap of fifteen messages strikes. Run at least five trials per condition; journal every run in the detail grammar of frontier/patterns/signatures.py, so that the shipped detectors can read your traces; score the four columns — quality as the fraction of trials whose patch passes the planted test, tokens, latency, and failures as detector flags plus cap strikes. Then report: each topology’s token multiplier over the baseline; whether the debate chorused, by is_chorus on your own journals; and whether the peer network’s runs ended by convention or by cap — Section 21.4’s observation that asking a peer network whether it is finished is a research question, here given an empirical answer. Record the model identifier and the date beside the table; the durable finding is the ordering of the multipliers and the failure signatures, not any cell.