You start with one coding assistant and it’s great. So you add a second agent to review the first. Then a planner. Then a tester. Each addition feels reasonable, and somewhere around the fourth one the system starts to wobble: the logs balloon, the agents make contradictory decisions, costs spike, and you’re back babysitting it at 2 a.m. wondering whether all this orchestration actually bought you anything.

That tension — more power versus more pain — produced one of 2025’s sharpest engineering disagreements. On June 12, Cognition (the team behind Devin) published “Don’t Build Multi-Agents,” arguing that parallel subagents make independent decisions on shared problems and produce conflicting, fragile output. Less than 24 hours later, Anthropic published “How we built our multi-agent research system,” reporting a multi-agent architecture that outperformed a single agent by 90.2% on their research evaluation. Two of the most respected teams in the field, opposite conclusions, same week.

Here’s the thing: they’re both right. Resolving that apparent contradiction is the key to using multi-agent systems well — and it starts by recognising what these systems actually are.

Multi-agent orchestration is distributed systems

The most useful reframe in this whole topic: you are not inventing something new. A team of agents passing messages, delegating work, and sharing state is a distributed system, and the patterns have names that predate LLMs by decades — orchestrator-worker, pipeline, message bus, blackboard, the actor model. The failure modes are the classic distributed-systems failure modes too: race conditions, cascading failures, coordination overhead, partial failure.

Separation of concerns, single responsibility, clear interfaces, idempotency, error handling, observability, bounded resources — everything you already know about building reliable systems still applies, and applies harder, because you’ve added a new source of nondeterminism on top. The teams that fail with multi-agent treat it as a vibe. The teams that succeed treat it as an engineering problem with known patterns and known failure modes. As one widely-shared 2026 benchmark put it bluntly: the gap between a good agent system and a bad one is almost never the framework — it’s the eval pipeline, the observability, and the failure-recovery logic.

When multi-agent actually helps

Anthropic and Cognition don’t actually disagree on the principle; they were describing different workloads. Anthropic’s own write-up is explicit about the boundary. Multi-agent systems earn their keep when a task has:

• Heavy parallelism — it splits into independent strands that don’t need to talk to each other.
• Information that exceeds a single context window — more material than one agent can hold, so you spread it across several windows.
• Many complex tools to coordinate.
• High enough value to justify the cost — and the cost is real: their multi-agent system used roughly 15× the tokens of a single chat.

And they’re equally explicit about when it doesn’t fit — which, notably, includes most coding:

“Most coding tasks involve fewer truly parallelisable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.”

That’s the resolution of the debate. Research parallelises beautifully — five subagents investigate five subtopics in isolation and report back. Coding often doesn’t, because changes are tightly interdependent: the function you’re writing depends on the type the other agent just changed. Cognition’s point is that splitting tightly-coupled work across agents fragments the context each one needs, and they make conflicting decisions. Anthropic’s point is that splitting loosely-coupled work across agents is a superpower. Both true.

The default is still one agent

Before any pattern, internalise the most important rule: start with a single, well-prompted agent with good tools. It handles something like 80% of what people reach for frameworks to solve. Multi-agent is the exception you reach for when a single agent hits a hard wall — a context-window limit, a genuinely parallel workload, a tool-coordination problem — not the default architecture. This is the same instinct as “start with the monolith”: don’t pay distributed-systems complexity until a real constraint forces you to.

The pattern ladder

When you do go multi-agent, you’re choosing a topology, and there’s a clear ladder from simplest to most complex. Each rung adds capability and cost, and each has a characteristic failure mode worth knowing before you climb.

• Single agent — one agent, one context window, a good toolset. The baseline and the right answer most of the time.
• Router — a lightweight classifier inspects each request and sends it to the right specialist agent. Still single-agent execution; you’ve just picked which one. Cheap and reliable. Failure mode: misrouting.
• Pipeline (sequential) — agents in a fixed chain, each transforming the previous one’s output: writer → editor → fact-checker. Deterministic and easy to reason about. Failure mode: errors compound down the chain.
• Orchestrator-worker (supervisor) — a lead agent decomposes a task and delegates sub-tasks to specialised workers, then synthesises their results. This is what production looks like in 2026, with the widest framework support (Claude Agent SDK, LangGraph, OpenAI Agents SDK, CrewAI’s hierarchical process). Failure mode: over-delegation — the orchestrator spawning workers endlessly — which you bound with iteration ceilings.
• Swarm — a dynamic, open-ended population of peer agents that coordinate through shared memory or a message bus rather than a fixed coordinator. The frontier, powerful for massively parallel work. Failure modes: runaway spawning and shared-state race conditions, which you bound with population caps and concurrency safeguards.

Start at the bottom and climb only when forced. Most teams that succeed land on orchestrator-worker; most teams that fail jumped to a swarm because it sounded impressive.

A preview of the failure surface

One sobering data point to carry forward: a Berkeley research team catalogued 14 distinct failure modes specific to multi-agent LLM systems — things like agents losing track of who’s responsible for what, conversations derailing, and one agent’s error propagating through the whole team. These sit on top of every normal software failure mode, not instead of them. Multi-agent doesn’t replace your reliability engineering; it demands more of it. That’s the subject we keep returning to.

Building a Team of Coding Agents

We’ve just hit an uncomfortable truth: most coding isn’t parallelisable, so a team of coding agents is the exception, not the rule. This part is about finding the exceptions — the coding work that genuinely benefits from multiple agents — and building it correctly with the orchestrator-worker pattern.

First, find the parallel work

Before writing any orchestration code, do the analysis that most teams skip: figure out which parts of your task are actually independent. Coding work falls into two buckets, and only one belongs in a multi-agent system.

Tightly coupled (keep single-threaded): A refactor where every change depends on the last. Implementing a feature whose pieces share evolving types and assumptions. Anything where worker B needs to know what worker A just decided. Splitting this across agents fragments the context each needs and produces the conflicting decisions Cognition warned about. Use one agent.

Loosely coupled (parallelise): Work that decomposes into independent strands sharing little context:

• Broad, read-only exploration. “Find every call site of this deprecated API across the monorepo.” “How do these eight modules each handle caching?” Each strand is independent and mostly read-only — the ideal multi-agent workload, exactly like Anthropic’s research case.
• Independent implementation units. Three unrelated bug fixes in three unrelated modules. A set of similar-but-separate endpoints. Each can be a worker on its own branch.
• The role split. Author, tester, reviewer, and security as separate agents with separate contexts — not parallel on the same code, but a pipeline of specialised perspectives.

The discipline here is just good old task decomposition. If you can’t write down sub-tasks that are genuinely independent, you don’t have a multi-agent problem — you have a single-agent task you’re overcomplicating.

The decision that makes or breaks it: the isolation boundary

Once you have independent sub-tasks, the single most important design decision is the isolation boundary: what does each worker need to know about what the others are doing? Anthropic’s answer for research was radical and worth copying: almost nothing. Each subagent gets a self-contained task description, an expected output format, and a fresh context window. It doesn’t know the other workers exist and can’t coordinate with them mid-task.

That isolation is not a limitation — it’s the whole point. It’s what lets workers run in true parallel, and it’s what keeps the orchestrator’s context window from drowning in cross-talk. In software terms, you’re enforcing single responsibility (each worker owns one job) and a clean interface (the task description is the worker’s API contract; its structured result is the return value). The workers are pure functions with respect to each other.

For coding, isolation has a concrete, beautiful implementation: one git worktree per worker. Each agent gets its own checked-out branch in its own directory, so parallel workers physically cannot collide on the filesystem, and merging back is an ordinary pull request. Isolation boundary and execution isolation become the same mechanism.

Building the orchestrator

Here’s the shape of an orchestrator-worker system for coding. It’s deliberately framework-agnostic — the pattern matters more than the library, and you can map it onto LangGraph, CrewAI, or the Claude/OpenAI SDKs (more on that below).

from dataclasses import dataclass

@dataclass
class SubTask:
    id: str
    description: str          # the worker's entire contract — self-contained
    output_schema: dict       # the expected structured result

# ---- ORCHESTRATOR ---------------------------------------------------------
def orchestrate(task: str, max_workers: int = 6) -> str:
    plan = decompose(task)                      # lead agent: split into sub-tasks
    if len(plan) <= 1:
        return single_agent(task)               # not parallel — don't multi-agent it
    plan = plan[:max_workers]                   # bound fan-out (over-delegation guard)

    results = run_parallel(spawn_worker, plan)  # workers run isolated, in parallel
    return synthesize(task, results)            # lead agent merges the findings

def decompose(task: str) -> list[SubTask]:
    """Lead agent returns ONLY independent sub-tasks. If it can't, return one."""
    system = ("Split this task into INDEPENDENT sub-tasks that share no state and "
              "can run in parallel. Each must be self-contained. If the work is "
              "tightly coupled, return a single task. Output JSON only.")
    return [SubTask(**t) for t in call_model(system, task)["subtasks"]]

# ---- WORKER ---------------------------------------------------------------
def spawn_worker(sub: SubTask) -> dict:
    """A worker: fresh context, isolated worktree, self-contained brief."""
    wt = make_worktree()                        # its own branch + directory
    agent = Agent(                              # fresh context window
        system=f"You are a focused coding agent. Task:\n{sub.description}\n"
               f"Return a result matching this schema: {sub.output_schema}",
        tools=scoped_tools(wt),                 # least privilege, confined to worktree
    )
    return bounded(agent.run, max_iterations=25)  # cap iterations — no runaway loops

Read what’s not in there: no worker-to-worker channel, no shared mutable state, no unbounded loops. Every choice is a software fundamental:

• decompose returns one task when the work is coupled — the system refuses to multi-agent a single-agent problem. This one guard prevents most multi-agent disasters.
• max_workers and max_iterations bound resources — the direct fix for the over-delegation failure mode.
• output_schema makes each worker’s result a typed contract the orchestrator can rely on, not free text it has to re-parse.
• scoped_tools(wt) gives each worker least-privilege access confined to its worktree — containment, exactly as a single agentic worker needs.

Synthesis is where quality is won or lost

The orchestrator’s hardest job isn’t delegating — it’s synthesising. Workers return partial, independently-derived results; the lead agent has to reconcile them into one coherent answer, catch contradictions, and decide what to keep. This is the step Cognition was worried about: independent workers can reach incompatible conclusions. The mitigation is to keep synthesis single-threaded and authoritative — one orchestrator with the full picture decides, rather than letting workers negotiate. For coding specifically, synthesis often ends not in merged code but in N pull requests the orchestrator opens for human review — keeping a person at the merge boundary.

Mapping to frameworks

You can hand-roll the above, but in production most teams use a framework. The pattern maps cleanly onto all of them; pick by your needs, not hype:

• LangGraph — models the orchestrator as a graph with conditional edges and durable execution, so a long-running team survives a server restart, with checkpointing and the most mature tracing (LangSmith). The production default for complex flows; steeper learning curve.
• CrewAI — role-based “crews” with a hierarchical process; fastest to prototype (a team in ~20 lines), lighter on production observability.
• OpenAI Agents SDK — explicit handoffs that pass context between agents; clean and opinionated, but model-locked and light on checkpointing.
• Claude Agent SDK — subagents with tool-use chains, wired to data and tools via MCP.

But heed the consensus from every serious 2026 comparison: the framework is the least consequential choice. What determines whether your team survives its first production incident is the eval pipeline, the observability, and the failure-recovery logic.

Keeping the fundamentals intact

Notice that nothing in this build is novel computer science. It’s classic engineering applied to a new substrate:

• Single responsibility → one job per worker.
• Interface/contract → the self-contained task description and output schema.
• Statelessness / isolation → fresh context window + dedicated worktree per worker.
• Bounded resources → caps on workers and iterations.
• Least privilege → tools scoped to each worker’s worktree.
• A single authoritative integrator → the orchestrator owns synthesis; workers don’t negotiate.

Get those right and orchestrator-worker is robust. Skip them and you get the wobble.

Swarms, Coordination & Keeping It Production-Safe

Orchestrator-worker has a fixed coordinator and a bounded set of workers. The top rung of the ladder removes both constraints — and that’s exactly why it’s powerful and dangerous in equal measure.

Swarms: the frontier, and its sharp edges

A swarm dynamically spawns an open-ended population of peer agents based on workload, and they coordinate through shared memory or a message bus rather than through a central orchestrator. There’s no single agent holding the whole plan; coordination is emergent. This is the frontier of multi-agent design, and it shines for massively parallel, open-ended work where you can’t predict up front how many workers you’ll need or how they should divide labour.

It’s also where the distributed-systems bill comes due in full. Remove the fixed coordinator and you inherit every hard problem in concurrent computing:

• Runaway spawning. A peer agent decides it needs help and spawns more agents, which spawn more — an unbounded fork bomb made of LLM calls, each one expensive. The fix is a hard population cap enforced outside the agents’ control.
• Shared-state race conditions. Multiple agents reading and writing the same memory concurrently produce exactly the corruption you’d expect from any unsynchronised concurrent system. You need the classic safeguards: locks, atomic operations, or append-only logs with conflict resolution.
• Nondeterminism and emergence. With no central plan, behaviour emerges from interactions and is hard to reproduce or debug. Two identical runs can diverge.

The honest guidance: most teams should not build a swarm. If orchestrator-worker can express your problem — and it usually can — use it. Reach for a swarm only when the workload is genuinely open-ended and massively parallel, and only with the safeguards above wired in from the start. A swarm without a population cap is not an architecture; it’s an outage waiting for a trigger.

Coordination and shared state

Whether you’re running a careful swarm or a more dynamic orchestrator-worker variant, the moment agents share state you’ve re-entered concurrent-systems territory. Two classic patterns cover most needs:

• The blackboard. Agents read from and write to a shared “blackboard” of state. Simple, but every write is a potential race; guard it like any shared resource.
• The message bus / actor model. Agents are actors that communicate only by passing messages — no shared mutable state at all. This is what AutoGen’s v0.4 rewrite adopted (an event-driven actor core), and it’s the more robust choice precisely because it sidesteps shared-memory races by design. If you’re building coordination from scratch, prefer message-passing over shared memory for the same reason you would in any concurrent system.

And recall Cognition’s core warning, which applies most sharply here: agents making independent decisions on a shared problem produce conflicting outputs, and the fragility compounds. The mitigation is to keep the parts that need shared context single-threaded, and only parallelise the parts that are genuinely independent. Coordination you can avoid is coordination you can’t get wrong.

The failure surface you’re signing up for

A Berkeley research team catalogued 14 distinct failure modes unique to multi-agent LLM systems — among them agents losing track of responsibilities, derailing into unproductive loops, one agent’s hallucination propagating through the team, and premature termination where the system stops believing it’s done before it is. The critical point for production: these are additional to every failure mode your software already has. Multi-agent doesn’t simplify your reliability engineering — it multiplies what you must account for. Which is why the rest of this part is about scaffolding, not agents.

Keeping the software fundamentals intact

Whatever pattern you land on — pipeline, supervisor, or swarm — the disciplines that keep it production-safe are the same disciplines that keep any distributed system reliable. The framework debate is a distraction; this scaffolding is the actual work, and it’s where the gap between a system that survives its first incident and one that doesn’t really lives.

• Observability and tracing. You cannot debug what you cannot see, and a multi-agent run is a distributed trace across many context windows. Capture every agent, every delegation, every tool call, every hand-off — this is what mature tooling (LangSmith and peers) exists to provide. Without it, a misbehaving fleet is a black box.
• Durable execution and checkpointing. Agent runs are long; servers restart. Checkpoint state so a team can resume rather than restart from zero — a headline reason LangGraph leads in production. This is just write-ahead logging and crash recovery, applied to agents.
• Evals — the real differentiator. Every serious practitioner converges on the same point: the eval pipeline matters more than the framework. You need a suite that measures whether the whole system produces good outcomes, because in multi-agent systems “minor changes cascade into large behavioural changes” — a one-line prompt tweak can reshape the whole team’s behaviour. Without evals you’re flying blind through a non-linear system.
• Bounded resources. Iteration ceilings (against over-delegation), population caps (against runaway spawning), and token budgets (against the 15× cost blowing up silently). Every loop and every spawn needs a bound enforced outside the agent’s judgement.
• Structured contracts between agents. Typed task descriptions in, structured results out — so a hand-off is a checked interface, not a hopeful paragraph. The same reason you type your function signatures.
• Least privilege. Each agent gets only the tools, data, and credentials its job requires. One compromised or confused agent in a fleet shouldn’t be able to touch production — and at fleet scale, this is non-negotiable.
• Human checkpoints. For anything consequential — merging code, spending money, touching customers — a human sits at the boundary. Autonomy scales the work; human checkpoints scale the trust.

None of these is AI-specific. They’re the reliability practices distributed systems have always needed. Multi-agent orchestration doesn’t let you skip them — it raises the price of skipping them.

The whole picture

The shape is clear. Start with one good agent. Climb to multiple agents only when a real constraint — parallelism, context limits, tool coordination, justified by value — forces you up the ladder. Prefer the simplest pattern that works: router, then pipeline, then orchestrator-worker, and only rarely a swarm. Isolate workers aggressively so they don’t have to coordinate. Keep the parts that need shared context single-threaded. And wrap the whole thing in the ordinary scaffolding of reliable software — observability, durable execution, evals, bounded resources, contracts, least privilege, human checkpoints.

The promise of agent swarms is real: for the right workload, a team of agents does things no single agent can. But the teams that realise that promise aren’t the ones with the most agents or the trendiest framework. They’re the ones who remembered that an agent fleet is a distributed system, and that we already know how to build those well. The intelligence is new. The engineering is not — and the engineering is what keeps it standing.