Designing Agent Systems

Ten chapters ago, this volume opened with a fact its own best evidence would go on to partly undercut: the organization most associated with a successful production multi-agent system is the same one that warns most coding tasks parallelize poorly. That is not a contradiction to smooth over. It is the thesis. Chapters 1 and 2 spent their pages on honest scoping before anything else — where the fleet pattern actually earns its keep today, and where a single, carefully iterated agent still wins most coding work, because the work is tightly coupled and agents remain bad at coordinating with each other in real time. Chapters 3 through 8 then did the harder, more useful work of taking the pattern seriously for the cases where it does fit: the token economics of buying parallel performance, the orchestrator–worker shape behind the best-documented gain in the literature, role specialization and model-tier routing, worktree isolation as the mechanical substrate, shared context and coordination primitives, and the conflict-resolution discipline a fleet needs once more than one agent can touch the same file. Chapters 9 and 10 closed on the parts that keep a fleet honest and visible — how a team judges a fleet’s output, and how it stays aware of what several agents are doing at once, rather than finding out three days later.

The single claim underneath all ten chapters

Say it plainly, because the rubric below depends on it: multi-agent architecture is a genuine, well-evidenced engineering pattern with real wins attached — not vaporware, not a fad — but those wins are narrower and far more dependent on the shape of the task than the surrounding industry conversation tends to admit. The orchestrator–worker pattern that outperformed a single agent by 90.2% on an internal research evaluation is a real number from a real production system, and the task behind it was a research task — identifying board members across S&P 500 companies — not a coding task. The same team that produced that number was explicit that coding involves fewer truly parallelizable pieces than research does. Both facts are true simultaneously, and treating either one as the whole story — multi-agent is simply the future, or multi-agent simply does not work for code — is where this volume’s contrarian opening chapters and its dense, practical middle chapters would otherwise look like they disagree with themselves. They do not. They are answering different questions.

Using the pattern well, then, is not a yes-or-no adoption question. It is a diagnostic performed before a single extra agent gets spun up. Does the task actually decompose into pieces an agent can work on without constantly needing a decision another agent just made? Is the coordination overhead — the tokens spent delegating, explaining, and reconciling, on top of the roughly 4× and 15× multipliers this volume’s economics chapter documents — smaller than the wall-clock time it buys back? Chapters 3 through 8 are not an argument that the answer is usually yes. They are the toolkit for answering the question honestly, and for building the isolation, coordination, and conflict-resolution machinery correctly on the occasions when the answer genuinely is yes. A team that skips the diagnosis and reaches for a fleet by default is paying a real token tax for a coordination structure the task was never shaped to convert back into value.

Most teams that reach for a fleet of agents have not asked whether their task is shaped for one. They have asked only whether more agents sounds faster.

A framework for diagnosing fit

What follows is not a new named framework — this volume spent its restraint describing the isolation spectrum and the five orchestration shapes plainly rather than branding them further. It is the set of diagnostic questions the preceding ten chapters actually equip a reader to ask, roughly in the order a real evaluation should ask them, one keyed to each chapter.

• Trajectory honesty (Ch. 1): Is the task research-shaped — broad, exploratory, parallel search over a large space — or coding-shaped: tightly coupled, sequential, dependent on a decision made two steps ago? The best-evidenced multi-agent gains sit firmly on the research side of that line.
• The gate before the pattern (Ch. 2): Would a single agent, iterated carefully across a few passes, plausibly finish this in comparable time? If the honest answer is yes, a multi-agent version is not solving a speed problem — it is spending tokens to feel parallel.
• Economics (Ch. 3): Is parallelism a deliberate spend decision — buying a ~4×–15× token multiplier for a specific, named return — or is nobody on the team able to say afterward what that multiplier actually bought?
• Orchestrator–worker fit (Ch. 4): If the shape is a lead agent decomposing work to parallel subagents, does the task resemble the research-style breadth the pattern was measured on, or is a research-tuned architecture being applied to coding work it was never validated against?
• Roles and routing (Ch. 5): Are agents specialized and routed to the model tier and task type they are actually good at, or is the fleet just N copies of the same generalist agent running side by side?
• Isolation (Ch. 6): Is every agent mechanically isolated — separate git worktrees, not a shared working directory — and does the concurrent-agent count sit inside the practiced single-digit sweet spot, or has the team scaled past the point where a human can still track what is running?
• Coordination (Ch. 7): Is there an actual shared task list, message bus, or decision gate wiring the fleet together, or are agents coordinating implicitly through git and hoping nobody collides?
• Conflict resolution (Ch. 8): When two agents’ work overlaps — a merge conflict, a duplicated fix, a contradicted decision — is there a designated single-writer claim or an explicit resolution rule, or does the team discover the collision only at merge time?
• Verification (Ch. 9): Is the fleet’s output actually judged — a structured scorer, an adversarial pass, a human — before it is trusted, or does “the agents finished” get treated as equivalent to “the agents were right”? A hundreds-of-agents browser build is real evidence the pattern can scale; the same project’s early flat-coordination failures are equally real evidence of how badly it degrades without a judging layer on top.
• Observability (Ch. 10): Can a human see, at a glance, which running agent needs attention right now — the way a single session’s status is obvious at a glance — or does a stuck or blocked agent stay invisible until someone happens to go looking?

None of these ten questions has a universal right answer, and several of them will earn the same team a deliberate yes on one project and a correct no on the next. A team building an internal research or knowledge-synthesis tool has good reason to reach for the orchestrator–worker pattern early — the evidence for that shape, on that kind of task, is the strongest evidence this volume cites. A team shipping tightly coupled feature work has equally good reason to stay with one well-iterated agent per session and put its engineering effort into the harness and the workflow instead — the subjects of two earlier volumes in this Library. The rubric’s job is not to push a team toward more agents. It is to make the choice a diagnosis instead of a reflex.

Where the Library goes next

This volume covered coordination: how work gets split, isolated, shared, reconciled, and judged across more than one agent. It said comparatively little about a harder question that applies whether a change came from one agent or ten — how does a team actually know the resulting code deserves the trust it is about to receive? This Library turns to that question next. Volume VII, Verification & Trust, takes it up directly: testing strategies built for AI-authored code, code review adapted to AI output at volume, and the trust calibration that decides when a result gets accepted, spot-checked, or re-derived from scratch. A fleet of coordinated, judged agents is still only as trustworthy as the verification layer sitting on top of it — and that layer, not the fleet itself, is where this Library goes to build it.