Multi-agent does not mean more reliable The initial intuition behind multi-agent systems — that specialized agents produce better results than a single generalist model — is sometimes correct and often overstated. In practice, multi-agent architectures introduce coordination complexity, new failure modes, and latency overhead that single-agent approaches avoid. The question is not whether to use multi-agent systems but when the tradeoff is worthwhile. We see this pattern regularly when teams reach for multi-agent orchestration because the surrounding discourse treats it as the next step beyond single-agent prompting. That framing skips the harder question: does the problem genuinely decompose, or are we adding coordination overhead in exchange for the appearance of sophistication? How do multi-agent systems coordinate? Three coordination patterns cover most production systems today. Each has a structural shape, a class of problem it fits, and a characteristic way of breaking. Orchestrator + subagents An orchestrator agent plans and delegates to specialized subagents. The orchestrator decides which subagent to call, with what inputs, and how to integrate the results. The shape is hierarchical: one planner, several executors. Works well when subagents have genuinely specialized capabilities — code execution through a sandbox, web browsing via a headless tool, database queries through a parameterized interface. Breaks when the orchestrator misunderstands subagent capabilities or issues ambiguous instructions. The orchestrator becomes a single point of failure whose context window grows with every delegation. Peer-to-peer (debate and review) Multiple agents produce outputs independently, then critique or vote on each other’s outputs. This is common in reflection architectures and in setups inspired by LLM-as-a-judge research. Works well for quality assurance of generated content — code review, factual checking, structural critique of long-form output. Expensive in tokens and latency. In our experience, peer-to-peer setups often produce consensus on the wrong answer rather than surfacing the correct one, because models trained on overlapping data agree on the same plausible mistakes. Pipeline (sequential handoff) Agent A completes a step and passes output to Agent B, which adds to it, then to Agent C. Each agent sees the accumulated work and contributes one transformation. Works well for document processing pipelines where each stage transforms the output — extract, normalise, summarise, classify. Error propagation is the dominant failure: a mistake in an early stage is amplified by later agents that treat upstream output as authoritative input. When does a problem genuinely require multi-agent? The honest answer is: less often than current discourse suggests. Multi-agent adds value under specific conditions that should be demonstrated rather than assumed. Multi-agent earns its complexity when: Tasks genuinely decompose into independent parallel subtasks — research plus writing, data collection plus analysis, image generation plus caption generation. Tasks require capabilities that cannot coexist in one context — a long document held in one agent’s window plus code execution managed by another. A second-pass critic measurably improves output quality, verified by an evaluation harness rather than asserted. Multi-agent adds complexity without value when: Tasks are sequential with tight dependencies between steps. Each step needs the previous step’s full state, so the handoff is mostly overhead. The “specialization” is cosmetic — two general-purpose models with different system prompts rather than two genuinely different capability surfaces. Latency is a hard constraint. Multi-agent is inherently slower because each handoff adds at least one model call’s worth of round-trip time. This is the same boundary AI orchestration and multi-agent coordination treats from the orchestration-layer angle: orchestration is worth its weight only when the underlying problem actually has parts to orchestrate. How do multi-agent systems break in production? Failures in multi-agent systems emerge from interactions, not from individual agent errors. An agent that produces correct outputs in isolation can still contribute to system failure through poorly timed actions, conflicting objectives, or information loss at handoff boundaries. Failure mode Description Mitigation Instruction drift Subagent interprets task differently from the orchestrator’s intent Structured output schemas (JSON Schema, Pydantic), explicit success criteria in the delegation prompt Cascading errors An error in an early agent corrupts all downstream agents Validation checkpoints between agents, schema-level contract enforcement Infinite delegation Agents forward tasks to each other without resolving them Maximum delegation depth, explicit task-completion criteria Silent failures Subagent returns plausible-looking but wrong output Output validation against value ranges and known constraints, not just receipt Token overhead Multi-agent context costs 3–10× single-agent (observed pattern across our engagements; not a benchmarked rate — varies with prompt design and handoff verbosity) Profile total tokens per task before optimizing for quality The most common multi-agent failure we encounter is opinion collapse — agents converge on a shared incorrect conclusion through a feedback loop. Agent A produces an incorrect intermediate result. Agent B uses it as authoritative input. Agent A then treats Agent B’s confirmation as validation. Breaking this requires explicit disagreement mechanisms: agents designed to challenge conclusions rather than accept them, and voting protocols that require independent reasoning rather than sequential confirmation. How do you debug multi-agent systems in production? Our debugging approach uses three layers of observability. First, structured logging of every agent action, observation, and decision, tagged with a shared conversation or task ID that traces the full interaction sequence. Tools like LangSmith, OpenTelemetry traces, or a custom logging schema all work — what matters is that the trace is reconstructable. Second, state snapshots at handoff points. When one agent passes control or information to another, both the sending agent’s state and the receiving agent’s input are logged. This is where most production bugs hide: the handoff format quietly drifts, and downstream agents start receiving slightly different inputs than they were designed for. Third, replay capability. Given the logged inputs, we can replay any agent’s execution deterministically using fixed random seeds and cached LLM responses (vLLM and TGI both support deterministic decoding when temperature is fixed). Without replay, debugging is guesswork on a non-deterministic system. For production multi-agent systems we implement circuit breakers at each agent boundary. If an agent’s output fails validation checks — format, value ranges, consistency with known constraints — the system falls back to a single-agent path rather than propagating errors through the chain. This reduces the blast radius of an agent failure and provides degraded-but-functional service while the failure is investigated. Cost control requires per-agent token budgets. Without them, a planning agent that enters a reasoning loop can generate thousands of tokens of internal deliberation before producing its output. We set per-step token limits and maximum step counts for each agent, with alerts when agents approach their budgets. How does multi-agent reinforcement learning differ from LLM orchestration? The phrase “multi-agent system” covers two largely separate research lineages, and conflating them produces confused architectures. Multi-agent reinforcement learning (MARL) studies agents that learn policies in shared environments — think traffic simulation, market-making bots, or robotic swarms. The agents have explicit reward signals, the environment provides feedback through state transitions, and coordination emerges (or fails to emerge) from training. Frameworks like PettingZoo and RLlib are the relevant tooling. LLM-based multi-agent orchestration is different. The “agents” are language model invocations with different system prompts and tool access. There is no shared environment with a reward signal in the RL sense; coordination is mediated by message passing and prompt engineering. Frameworks like LangGraph, AutoGen, and CrewAI sit in this space. The two share vocabulary — agent, coordination, policy — but the engineering problems are different. MARL failure modes are about non-stationarity (every other agent’s learning changes your environment) and credit assignment. LLM-orchestration failure modes are about prompt context, handoff schemas, and token cost. A team building an LLM-orchestrated system that reaches for MARL frameworks usually ends up with the wrong abstractions. FAQ What is a multi-agent system, and how do its agents coordinate? A multi-agent system is an architecture in which multiple autonomous components — typically LLM invocations with distinct system prompts and tools — work together on a shared task. Coordination happens through one of three patterns: an orchestrator delegating to subagents, peers reviewing each other’s outputs, or a pipeline of sequential handoffs. The coordination mechanism is the design choice that matters most. When does a problem genuinely require multi-agent architecture versus single-agent or plain automation? When the task decomposes into genuinely parallel subtasks, requires capabilities that cannot share one context, or benefits from a measurable second-pass critic. If the task is sequential with tight dependencies, latency-constrained, or the “specialization” is just two prompts on the same base model, single-agent or plain automation is the better fit. How do multi-agent systems break in production — failure cascades, deadlocks, behavioural drift? The dominant failure modes are instruction drift (subagents misinterpret the task), cascading errors (early mistakes amplified downstream), infinite delegation (agents forwarding without resolving), silent failures (plausible but wrong outputs), and opinion collapse (agents converging on a shared mistake through feedback loops). What design patterns govern inter-agent communication and responsibility decomposition? Use structured output schemas at every handoff so downstream agents receive validated input. Decompose responsibilities by capability boundary, not by surface task — an agent owns code execution because that capability cannot live in another context, not because “code agent” sounds tidy. Bound delegation depth and token budgets explicitly. How do I monitor a multi-agent system in production and detect coordination failure early? Three observability layers: structured logging of every action and decision under a shared task ID, state snapshots at every handoff boundary, and deterministic replay capability for any agent’s execution. Add circuit breakers at agent boundaries that fall back to a single-agent path when validation fails, and per-agent token budgets with approach-threshold alerts. How does multi-agent reinforcement learning differ from LLM-based multi-agent orchestration? MARL involves agents learning policies in shared environments with explicit reward signals — the failure modes are non-stationarity and credit assignment. LLM-based orchestration uses prompt-configured language model invocations coordinated by message passing — the failure modes are prompt context, handoff schemas, and token cost. The frameworks (PettingZoo and RLlib versus LangGraph and AutoGen) reflect that the engineering problems are different even when the vocabulary overlaps. Practical starting point Start with a single agent. When it reliably fails at a specific point — context limits, specialization needs, or capability gaps, not just quality variability — introduce a second agent for that specific function. Build multi-agent complexity in response to demonstrated limitations, not anticipated ones. The architectures that survive production are the ones whose every added agent earned its place by closing a specific failure mode the previous version had.
