What is a multi-agent system, and how do its agents coordinate?

A multi-agent architecture assigns different roles or capabilities to separate LLM-powered agents that coordinate to complete a task. Instead of one model handling everything, specialised agents handle subtasks: a planner agent breaks down the goal, a researcher agent gathers information, a coder agent writes code, a reviewer agent checks quality. Coordination happens through shared state, message passing, or a central orchestrator.

The appeal is intuitive. Specialisation improves quality, parallelisation improves speed, and the architecture mirrors how human teams already split work. The reality is more nuanced — coordination overhead, state management complexity, and failure cascade risks can outweigh the benefits for many workloads. In our experience, the divergence point is rarely “should we use agents?” but “have we shown that a single agent is insufficient before adding a second?”

Concretely, coordination shows up in three places: how agents exchange information (LangGraph state graphs, AutoGen message buses, or plain Python queues), how decisions get arbitrated when two agents disagree, and how the system terminates when a goal has been reached. Each of these is its own design choice, not a framework default to inherit blindly.

When does multi-agent coordination genuinely add value?

Scenario	Value add	Why
Tasks requiring diverse tools	High	Different agents specialise in different tool APIs
Parallel subtasks	High	Independent subtasks execute concurrently
Tasks requiring self-review	Medium	A separate reviewer agent avoids self-assessment bias
Simple sequential tasks	Low	A single agent handles these with less overhead
Tight latency budgets	Low	Coordination adds 2–4× latency (observed pattern across our agent engagements; not a benchmarked rate)

In our deployments, multi-agent architectures provide clear value in two scenarios. The first is complex research tasks where one agent searches, another synthesises, and a third verifies — each agent’s output quality benefits from role specialisation. The second is code generation tasks where a planner, coder, and tester agent operate in a loop. The separation between generation and evaluation produces higher-quality code than a single-agent loop, because the tester is not invested in defending the code it just wrote.

What design patterns govern inter-agent communication?

Hierarchical. A manager agent delegates subtasks to worker agents and synthesises their results. The manager maintains the overall plan; workers execute without awareness of the full context. This is the most common pattern because it maps naturally to management structures and is straightforward to implement in LangGraph or AutoGen. The weakness is structural: the manager becomes a bottleneck and a single point of failure. If the manager misjudges a subtask, every downstream worker inherits the mistake.

Peer-to-peer. Agents communicate directly, passing messages or shared state. Each agent decides when to act and what to communicate. This pattern enables emergent behaviour but is difficult to debug. The interaction between agents can produce outcomes that no single agent’s behaviour predicts, which is exciting in a research demo and dangerous in production.

Pipeline. Agents are arranged in a fixed sequence, each processing the output of the previous agent. This is the simplest pattern and the easiest to debug, but it does not support iterative refinement or parallel execution. For workflows that are genuinely linear — extract, classify, summarise, store — a pipeline is usually the right answer, and adding orchestration on top is over-engineering.

For the design patterns that govern individual agent behaviour within a multi-agent system, our guide to agent design patterns covers ReAct, Plan-and-Execute, and Reflection loops. The patterns above are how those individual agents are wired together.

How do multi-agent systems break in production?

The failure modes specific to multi-agent systems sit on top of the failure modes of individual agents.

State divergence. Agents operating on stale or inconsistent state make conflicting decisions. If a researcher agent finds information that invalidates the planner’s original plan, but the planner has already dispatched tasks based on the old plan, the system produces inconsistent results. This is the multi-agent equivalent of a cache coherency bug — and equally hard to reproduce.

Cost explosion. Each agent interaction involves an LLM API call. A multi-agent system with four agents making five calls each per task uses 20× the API cost of a single-agent approach (observed pattern in our agent deployments; varies by model and prompt size). Without per-agent and per-task cost budgets, multi-agent systems generate unexpectedly large bills. We treat token budgets as first-class infrastructure, not an afterthought.

Accountability gaps. When the system produces an incorrect result, identifying which agent caused the error requires tracing through the full interaction log. We implement per-agent output validation — checking each agent’s output against format and content constraints before passing it to the next agent — which catches errors at their source rather than propagating them through the system.

Deadlocks and loops. Two agents waiting on each other, or a reviewer agent that keeps rejecting a coder agent’s output without converging, are characteristic multi-agent failures. The mitigation is a hard iteration cap combined with a “give up and escalate” path, not a more clever prompt.

How do you decide between single-agent and multi-agent?

The framework we use evaluates four factors.

Task decomposability. Can the task be split into subtasks that benefit from independent processing? If the task is inherently sequential — each step depends on the full output of the previous step — multi-agent architecture adds coordination overhead without enabling parallelism. If subtasks are independent (research one topic while generating code for another), multi-agent enables concurrent execution.

Role specialisation value. Does assigning different system prompts, tools, or models to different subtasks improve quality? If the task benefits from a single consistent context (writing a document with a unified voice), a single agent is preferable. If the task benefits from specialised perspectives — a researcher who prioritises comprehensiveness and a writer who prioritises clarity — multi-agent adds value.

Error isolation need. Does the application require that errors in one component do not cascade to others? Multi-agent architectures with validation gates between agents provide natural error boundaries. A reviewer agent that checks the coder agent’s output catches errors before they propagate to the deployment agent.

Budget constraints. Multi-agent architectures consume 3–20× more tokens than single-agent approaches for the same task (observed range across our engagements; not a benchmarked rate). For cost-sensitive applications or high-volume workloads, this multiplier may be prohibitive.

Our default recommendation: start with a single agent with a well-structured prompt. If quality issues emerge that are attributable to role confusion — the agent tries to research, plan, and execute simultaneously and does all three poorly — consider splitting into a planner and executor. Add additional agents only when measurement demonstrates that the added complexity improves output quality by more than the coordination overhead degrades it.

How do you monitor a multi-agent system in production?

For production systems, we implement comprehensive logging at every agent boundary — recording inputs, outputs, token usage, latency, and any validation results. This observability infrastructure is not optional. Without it, debugging a multi-agent failure requires reproducing the full agent interaction, which is non-deterministic due to LLM sampling and may not reproduce on retry.

The signals we watch in practice: per-agent error rate, per-agent token spend, iteration counts on review loops, and time-to-first-result. A reviewer agent whose rejection rate climbs from 10% to 40% over a week is usually the first sign that an upstream model update has shifted output quality, even when end-to-end success rates look stable. Tools like LangSmith, Weights & Biases Traces, or a custom OpenTelemetry setup all work; what matters is that every agent call is traced with a stable correlation ID.

A brief note on multi-agent reinforcement learning. MARL — the classical control-theoretic variant with agents learning policies in a shared environment — is a different discipline from LLM-based agent orchestration, and the failure modes only partially overlap. MARL systems break on reward shaping and non-stationarity; LLM agent systems break on prompt drift and tool-call shape. Most production “multi-agent AI” today is the latter. Confusing the two leads to selecting techniques from the wrong literature.

FAQ

What is a multi-agent system, and how do its agents coordinate? A multi-agent system is an architecture in which separate LLM-powered agents take on distinct roles — planner, researcher, coder, reviewer — and coordinate through shared state, message passing, or a central orchestrator to complete a task that no single agent handles end-to-end.

When does a problem genuinely require multi-agent architecture versus single-agent or plain automation? When the task decomposes into subtasks that benefit from independent processing or specialised roles, when error isolation between stages is valuable, and when the quality improvement from specialisation outweighs the 3–20× token cost multiplier. Otherwise a single well-prompted agent — or plain deterministic automation — is the better starting point.

How do multi-agent systems break in production — failure cascades, deadlocks, behavioural drift? The characteristic failures are state divergence between agents operating on stale information, cost explosion from uncontrolled inter-agent calls, accountability gaps when errors are hard to attribute, and review-loop deadlocks where two agents fail to converge.

What design patterns govern inter-agent communication and responsibility decomposition? Three dominate: hierarchical (a manager delegates to workers), peer-to-peer (agents message each other directly), and pipeline (agents arranged in a fixed sequence). Hierarchical is the most common and the easiest to operate; peer-to-peer is the hardest to debug.

How do I monitor a multi-agent system in production and detect coordination failure early? Log every agent boundary with inputs, outputs, token usage, latency, and validation results under a stable correlation ID. Watch per-agent error and rejection rates, iteration counts on review loops, and per-task token spend — these surface coordination drift before end-to-end metrics do.

How does multi-agent reinforcement learning differ from LLM-based multi-agent orchestration? MARL is a control-theoretic discipline where agents learn policies in a shared environment; its failures are about reward shaping and non-stationarity. LLM-based orchestration is a software architecture problem; its failures are about prompt drift, tool-call shape, and coordination overhead. The techniques do not transfer cleanly between them.