The Agentic Swarm

Everything in this book is in service of the agentic swarm is a group of autonomous agents that collaborate toward a shared goal, rather than a set of isolated assistants each answering a prompt. It is less a component than a whole: a coordinated system that spans the agents themselves, the pools that create them, the cohorts that give them structure, the orchestrator that dispatches their work, and the delivery processes, from ticket enrichment through end-to-end orchestration, that carry an issue all the way to a merged change.

The word swarm is aspirational. It evokes many agents, a great deal of work in flight, and a system that stays busy without a human standing over it. That picture is the goal. But the word carries a trap, and the rest of this chapter is about not falling into it.

Swarm does not mean unstructured parallelism

The intuition that more agents running in parallel must mean more work done is wrong often enough to be dangerous. For software delivery it is usually backwards. Two agents editing the same code at the same time each make small implicit decisions (a name, an interface, an assumption about who owns what) and those decisions conflict in ways that quietly corrupt the result. Coordinating agents to avoid that is not free either; the coordination itself becomes one of the largest sources of failure in multi-agent systems.

So the hard question is not how many agents but how they collaborate: what runs at the same time, what must run in order, and where agent-to-agent negotiation earns its cost instead of adding to it. This is the most contested question in the field, and it deserves its own chapter.

The short version of the answer, which shapes the whole system, is a single rule: reads parallelise, writes do not. Searching, researching, and reviewing are read-only; many agents can do them at once with no risk of collision. Writing code changes shared state, so it is serialised, or partitioned so that no two writers touch the same surface. The Coordination Model lays out the evidence behind that rule: the single-threaded position argued by Cognition, the multi-agent position argued by Anthropic, and the failure data (the MAST taxonomy) that explains why unstructured collaboration breaks.

The swarm is a pipeline with bounded parallelism

Read the swarm through that rule and its real shape appears. It is a sequential delivery pipeline (enrich, plan, implement, review, merge) with bounded parallelism inside it. Read-only work fans out freely: a dozen agents can search a codebase or review a diff concurrently. Writes are held to one lane at a time, unless the work can be cleanly partitioned into independent surfaces.

Its coherence does not come from agents talking freely among themselves. It comes from two structures the pipeline is built around. The orchestrator is the coordination spine: it tracks what work exists, owns dispatch, and correlates what each agent did. The execution ledger is the shared, durable memory: the record of context and outcomes that lets a later agent build on an earlier one’s work instead of rediscovering it.

What makes a swarm coherent

Four properties separate a system from a crowd. Take any of them away and the agents act independently rather than as one thing.

• A coordination spine. The orchestrator tracks work, owns dispatch, and correlates execution. Without it there is no system, only agents.
• Shared durable memory. The execution ledger and the knowledge base carry context and results across invocations, so effort compounds instead of repeating.
• Role structure. Cohorts define hierarchy and communication paths: delegation across hard role boundaries, not peers negotiating as equals.
• A self-sustaining loop. Orchestration triggers and the conditions of the minimal bootstrap are what let the swarm keep running, and keep improving, without a human starting every cycle.

Those four properties are the throughline of the book. The chapters that follow are, in effect, each one worked out in full: the runtime that produces the agents, the knowledge and verification disciplines that make their output trustworthy, and the process that turns all of it into delivered software. The natural next step is the question this chapter kept deferring, how the agents actually coordinate, in The Coordination Model.