Skip to content
Kiberon LabsAgentic Engineering Ebook

The Coordination Model

The Agentic Swarm names the target system as many agents collaborating toward a shared goal. This chapter addresses the harder question the name leaves open: how they collaborate. What runs in parallel, what runs in sequence, and where coordination between agents helps versus where it actively destroys output quality.

This is the most contested design question in the field, and this book does not pick a winner by fiat. It documents the tension, the evidence on both sides, and the synthesising principle that lets the architecture stay on the safe side of it.

The central tension: single-thread vs multi-agent

Section titled “The central tension: single-thread vs multi-agent”

Two credible camps have formed, and both are partly right.

The single-thread camp (Cognition / Devin). Cognition’s position, argued in Don’t Build Multi-Agents, is that reliable agents are single-threaded with continuous context. Their two principles:

  1. Share context, and share full agent traces, not just individual messages. Passing only a subagent’s final answer to a parent loses the implicit reasoning behind it.
  2. Actions carry implicit decisions, and conflicting decisions carry bad results. Two agents working in parallel each make hidden assumptions; their outputs cannot be reconciled afterwards.

Their canonical example: split “build Flappy Bird” across two subagents and one returns a Super-Mario-style background while the other builds an off-style bird. Neither saw the other’s decisions, so the coordinator inherits irreconcilable work. The failure is not weak models; it is dispersed decision-making.

Source: Cognition: Don’t Build Multi-Agents

The multi-agent camp (Anthropic). Anthropic ships a production multi-agent research system built on an orchestrator-worker pattern: a lead agent spawns subagents, each with a self-contained task, its own clean context window, and no awareness of its peers; a single agent then synthesises. It outperformed single-agent baselines on breadth-first research by a wide margin.

But Anthropic’s own caveats are the important part: the system burned roughly 15 times the tokens of a normal chat; it required explicit effort-scaling rules in the prompt or the lead over-spawned; vague task descriptions caused duplicated work; and they state plainly that coding has fewer parallelisable parts than research and multi-agent is wrong for “domains needing shared context or tight real-time coordination.”

Source: Anthropic: Building a Multi-Agent Research System

The empirical referee (MAST). The UC Berkeley Multi-Agent System Failure Taxonomy studied 200+ traces across 7 frameworks (AutoGen, CrewAI, and others) and found failure rates of 41 to 87 percent. The failures cluster as roughly 44 percent system-design issues, 32 percent inter-agent misalignment, and the rest task verification. In other words, around 43 percent of failures are coordination and miscommunication, not individual model error, and errors compound down agent chains. Their conclusion: “improving robustness requires better orchestration, not larger models.”

Source: Why Do Multi-Agent LLM Systems Fail? (MAST, arXiv:2503.13657)

The synthesising principle: reads parallelise, writes do not

Section titled “The synthesising principle: reads parallelise, writes do not”

The two camps are arguing about different task shapes, and the reconciliation is a single rule (articulated cleanly by LangChain):

  • Read and exploration tasks parallelise cleanly. Research, code search, triage, log analysis, gathering prior art: multiple agents can work simultaneously because their outputs are additive. Conflicting reads are cheap; you keep the better answer. This is where the orchestrator-worker pattern earns its 15x cost.
  • Write tasks do not parallelise. Two agents writing interdependent code make conflicting implicit decisions that cannot be merged. Conflicting writes are expensive; they corrupt the artifact. Coding is the hard case precisely because it is write-heavy and tightly coupled.

This rule maps directly onto Ikidna’s delivery shape. The system is not a free-for-all swarm; it is a sequential pipeline (enrich, plan, implement, review, merge) in which each stage hands a verified artifact to the next, with read-only fan-out used freely inside stages.

This book’s Execution chapter reached the same conclusion independently: parallel work generates conflicts that are expensive to resolve and burn tokens through fresh agents that have lost the implementation context.

Topologies, and what they cost

Section titled “Topologies, and what they cost”

Coordination shapes recur often enough to name. The working catalogue, condensed from the multi-agent pattern literature: hub-and-spoke (an orchestrator dispatching workers; the default), sequential pipeline (artifact-dependent phases), parallel fan-out and gather (independent subtasks, then synthesis), hierarchical tree (coordinators of coordinators, for genuine scale), generator-critic (one agent produces, an independent one judges; the shape of adversarial verification), flat peer-to-peer, and dynamic swarm (agents spawning agents). The selection heuristic is unglamorous: linear work wants a pipeline, shared state wants hub-and-spoke, independent subtasks want fan-out, refinement wants generator-critic, and the exotic topologies want a justification in writing.

Two findings from that literature are worth keeping beside the catalogue. Cost climbs a ladder with structure: a single agent is the baseline, generator-critic runs two to three times the tokens, an orchestrator with a handful of workers five to eight times, and a large swarm ten to fifteen times, which is Anthropic’s 15x measured from the other side. And peer topologies benchmark marginally better than supervised ones while being far harder to observe and debug; the observability gap is wider than the performance gap, which is why Ikidna’s shape is supervised.

One implementation detail decides whether fan-out works at all in practice: parallel dispatches must actually be issued in parallel (in harnesses like Claude Code, multiple task calls in a single message). Dispatched one message at a time, the “parallel” workers serialise, and the topology silently degrades to an expensive pipeline.

Practical patterns for Ikidna

Section titled “Practical patterns for Ikidna”

Parallelise without writing. Fan out read-only subagents for the parts of a task that are genuinely independent: searching the codebase, gathering external research during Ticket Enrichment, reviewing a diff along independent dimensions, exploring alternative designs during planning. Each returns a condensed summary, not a mutation.

Partition write surfaces. When parallel implementation is unavoidable, give each agent a disjoint write surface (separate files, modules, or services) so implicit decisions cannot collide. Filesystem isolation via git worktree-per-task is the standard mechanism. The coordinator merges only after each branch’s verification passes; at fleet scale the merge queue in Swarm Operations is this pattern made permanent.

Delegation, not collaboration. Where roles are specialised (implement, review, test, document), dispatch them sequentially with hard role boundaries (Factory.ai’s “delegation, not collaboration” model) rather than letting peer agents negotiate. A reviewer agent that is deliberately not the implementer is more valuable than two implementers (see Model Usage on avoiding model self-bias). Explicit role structure is not just tidiness; role-based designs measurably reduce coordination failures in the published pattern studies.

Share traces, not just messages. When a stage does hand off to another agent, pass the relevant execution trace and the decisions made, not only the final artifact. The Execution Ledger is the durable substrate for this.

Scope small. Long-horizon work is many short, well-scoped sessions, not one long-running collaboration. See Runtime Context Management.

When to reach for true multi-agent

Section titled “When to reach for true multi-agent”

Fan out to multiple concurrent agents only when the task is provably breadth-first and the value justifies the roughly 15x token cost: large independent research sweeps, exploring many candidate solutions in parallel, or burning down a backlog of independent tickets (different PRs, different repos, the way Cognition runs hundreds of Devin instances at once). Independent-task parallelism is safe; collaborative-write parallelism on one artifact is not.

For everything else, prefer a workflow (deterministic code path) with agentic steps inside it over an open-ended agent society. The reliability gains of orchestrator-worker patterns can usually be captured inside a single agent’s loop without the coordination cost.

Section titled “Related chapters”