Why one agent is not enough A single AI agent with tool access can handle straightforward multi-step tasks: research a topic, query a database, generate a report. But complex tasks — tasks that require different types of expertise, that span multiple systems, or that benefit from quality checking by a second perspective — push the limits of what a single agent can do within its context window and reasoning capability. Multi-agent systems address this by decomposing a complex task across multiple specialised agents: a planner that breaks the task into subtasks, specialists that execute each subtask, a reviewer that evaluates the quality of intermediate outputs, and an orchestrator that coordinates the workflow. Each agent has a defined role, a specific set of tools, and a focused prompt that keeps it within its area of responsibility. As reported in published benchmarks, multi-agent systems consume significantly more tokens — often 3–10× more (a directional industry-scale figure from the published evaluations, not a benchmarked rate for any specific workload) — than single-agent approaches for equivalent tasks, due to the inter-agent communication overhead. Multi-agent code-generation workflows (such as coder-reviewer pairs) can achieve meaningfully higher correctness rates than single-agent generation, but at the cost of substantially higher token usage. The appeal is compelling: instead of one model trying to be good at everything, each model focuses on what it does best. The reality is more complex — coordination between agents introduces failure modes that single-agent systems do not have, and these failure modes are the primary risk in production multi-agent deployments. Gartner (2024) projects that multi-agent architectures will see significant enterprise adoption growth by 2028, though adoption remains below 1% as of 2024. Early benchmarks on complex software engineering tasks suggest that multi-agent systems can achieve meaningfully higher task completion rates compared to single-agent approaches — though the magnitude of improvement varies substantially by task type and orchestration design. Coordination patterns Multi-agent systems use one of several coordination patterns, each with different reliability and flexibility characteristics: Sequential pipeline. Agent A completes its task and passes the output to Agent B, which completes its task and passes to Agent C. The pipeline is simple, predictable, and easy to debug: each agent’s input and output are visible, and failures are localised to the agent that produced the bad output. The limitation: sequential processing cannot handle tasks that require iteration or feedback between agents. Hierarchical delegation. A manager agent receives the task, decomposes it into subtasks, delegates each subtask to a specialist agent, collects the results, and assembles the final output. The manager agent handles planning and quality assessment; the specialist agents handle execution. This pattern mirrors human project management and works well for tasks with clear decomposition — but the manager agent’s planning capability is the ceiling for the system’s performance. Collaborative discussion. Multiple agents communicate in a shared conversation, building on each other’s contributions. A “coder” agent writes code, a “reviewer” agent critiques it, the coder revises, and the process iterates until the reviewer approves. AutoGen and CrewAI implement variants of this pattern. The pattern is flexible and produces high-quality output through iteration — but it is also the hardest to control, because the agents may enter unproductive loops, disagree without resolution, or generate excessive conversation that consumes context without advancing the task. Event-driven orchestration. A workflow engine dispatches tasks to agents based on events and conditions, without a single manager agent. Each agent registers capabilities and responds to task requests that match its specialisation. This pattern scales well and decouples agents from each other — but requires a robust orchestration layer that handles task routing, failure recovery, and resource management. Where multi-agent systems break The coordination patterns above work in demos and controlled experiments. In production, they break in specific, predictable ways: Do agents lose context between handoffs? Yes. When Agent A passes output to Agent B, the information about why Agent A made its decisions — the reasoning, the alternatives considered, the confidence level — is typically lost. Agent B receives the output but not the context. If Agent B needs to make a judgment call about Agent A’s output (should it trust this data? should it verify it? should it request clarification?), it lacks the information to make that judgment well. The fix: structured handoff protocols that include not just the output but the reasoning, the confidence assessment, and explicit flags for cases where the agent was uncertain. These protocols add overhead but prevent downstream agents from making decisions based on incomplete information. We have found that handoff quality is the single largest determinant of multi-agent system reliability. Do agents hallucinate coordination? Yes. An agent asked to “verify the output of the previous step” may generate a verification response that looks plausible but does not actually check anything — it hallucinates the verification. An agent asked to “delegate this subtask to the database specialist” may generate a response that describes what the database specialist would do, rather than actually invoking the specialist. These hallucinated coordination actions are dangerous because they appear to work in the conversation transcript but do not produce real results. The fix: tool-enforced coordination rather than prompt-based coordination. Delegation should trigger an actual agent invocation (a function call), not a text description of delegation. Verification should check actual outputs (compare against ground truth, run automated tests), not generate a narrative about verification. Do agents enter unbounded loops? Yes. A coder-reviewer loop can iterate indefinitely: the coder makes a change, the reviewer finds a different issue, the coder addresses it, the reviewer finds another issue. Without explicit termination conditions, the loop consumes tokens and compute without converging. We have observed multi-agent systems consume hundreds of thousands of tokens on a single task without producing a final output, because the agents were in a refinement loop with no convergence criterion. The fix: explicit loop bounds (maximum iterations), convergence detection (terminate when the changes between iterations fall below a threshold), and escalation protocols (after N iterations, escalate to a human for resolution rather than continuing indefinitely). Do agents conflict on shared state? Yes. When multiple agents can modify shared resources — a document, a database, a code file — concurrent modifications can produce conflicts. Agent A modifies section 3 of a document while Agent B is modifying section 5, and the modifications are based on different versions of the document. The final document may contain inconsistencies that neither agent would have produced individually. The fix: serialised access to shared resources (only one agent modifies a resource at a time), versioned state (each modification is applied to a specific version, and conflicts are detected and resolved), or resource partitioning (each agent owns specific resources and no other agent modifies them). Production multi-agent architecture Deploying a multi-agent system in production requires engineering beyond the agent logic itself: Observability. Every agent action, tool invocation, and inter-agent communication must be logged with sufficient detail to reconstruct the complete execution trace. When the system produces an incorrect output, the trace reveals which agent produced the error, what input it received, and what reasoning it followed. Without observability, debugging a multi-agent failure is significantly harder than debugging a single-agent failure. Cost management. Multi-agent systems consume tokens multiplicatively: each agent processes its own context, and inter-agent communication adds to the total token volume. As an illustrative example from our agentic-AI engagements (an observed pattern, not a benchmarked industry rate): a 5-agent system that processes an average task in 10 rounds of communication may consume 50–100× the tokens of a single-agent approach. The cost must be managed through efficient prompt design, context window management, and explicit bounds on communication rounds. Graceful degradation. When one agent fails (produces an error, times out, or returns low-quality output), the system must handle the failure without cascading. In practice, multi-agent system failures cascade faster than single-agent failures when coordination protocols do not include explicit failure handling. The agentic AI system design principles include failure handling as a core requirement. Multi-agent control-policy template The failure modes above — unbounded loops, hallucinated handoffs, cascading failures — are preventable when each agent operates under explicit control policies. The template below defines the parameters we configure for every production multi-agent deployment. Values are defaults; adjust per workload. Policy category Parameter Default Notes Retry policy max_retries_per_agent 2 Retries on transient errors (timeouts, rate limits). Not on logic failures. retry_backoff Exponential, base 2 s Prevents thundering-herd on shared resources. retry_scope Per tool call Retry the failed tool invocation, not the entire agent turn. Escalation policy escalate_after_retries true After max_retries_per_agent exhausted, escalate rather than fail silently. escalation_target Human-in-the-loop Options: parent agent, fallback agent, human queue. escalation_context Full trace Include agent reasoning, inputs received, and failure details in escalation payload. Loop bounds max_iterations 5 Hard cap on coder-reviewer or refinement loops. convergence_threshold Δ < 5 % between iterations Terminate early when changes between iterations fall below threshold. loop_cooldown 0 s Optional delay between iterations to allow state propagation. Timeout policy agent_turn_timeout 120 s Maximum wall-clock time for a single agent turn including tool calls. pipeline_timeout 600 s Maximum wall-clock time for the full multi-agent pipeline. idle_timeout 30 s Kill agent if no progress (no tool call, no output token) within window. Cost circuit-breaker max_tokens_per_task 100 000 Hard token budget for the entire task across all agents. max_cost_per_task Configurable per tier Dollar-denominated cap; prevents runaway spend on refinement loops. alert_threshold 70 % of budget Emit warning when token or cost consumption crosses threshold. These defaults prevent the most common production failures: unbounded refinement loops that consume hundreds of thousands of tokens, silent failures that cascade downstream, and hallucinated coordination that bypasses actual tool invocations. Every parameter should be logged to the observability layer so that post-incident analysis can trace which bound was hit and why. Multi-agent coordination failures are expensive to debug in production and straightforward to prevent in design — a GenAI Feasibility Assessment includes multi-agent system design and failure mode analysis.
