Multi-Agent Systems: When One Agent Is Not Enough

The initial wave of enterprise AI deployments was dominated by single-model applications: a model that summarises documents, one that classifies support tickets, another that drafts email responses. These are valuable. They are also architecturally simple.

As AI ambition in enterprise organisations has grown, so has the complexity of what those systems are asked to do. Research and synthesis tasks, complex workflow automation, multi-step operational processes — these cannot be accomplished by a single model call. They require multi-agent architectures: systems where multiple specialised agents coordinate to complete a task that none could complete alone.

When Single Agents Are Not Enough

Single-agent architectures have well-defined limits. They are insufficient when:

Context length constraints apply. Large language models have finite context windows. Tasks requiring large volumes of information — a full contract library, a quarter's worth of communications, a complex technical specification — exceed what a single call can handle.

Specialisation conflicts arise. A single agent designed to both retrieve information and evaluate its strategic implications will underperform an architecture where a specialised retrieval agent and a specialised analysis agent divide the work cleanly.

Parallel execution is valuable. Tasks decomposable into independent subtasks benefit from concurrent processing — which sequential single-agent architectures cannot provide.

Quality control matters. Some tasks benefit from a dedicated critique agent reviewing another agent's output. Self-review by a single agent produces weaker quality control than an independent evaluator.

The Three Core Orchestration Patterns

Sequential (Pipeline) — Agents are chained in a defined order. Each agent's output becomes the next agent's input. Appropriate for tasks with a clear, linear progression. Easy to design and debug. Cannot parallelise work.

Parallel (Fan-out / Fan-in) — A coordinator distributes subtasks to multiple specialist agents simultaneously, then aggregates their outputs. Appropriate when the task decomposes into genuinely independent parts. Faster than sequential for parallelisable work, but the fan-in aggregation step is where complexity concentrates — it must be specified explicitly.

Hierarchical (Supervisor / Sub-agent) — A supervisor agent dynamically manages task allocation and sequencing across sub-agents based on current task state. Unlike sequential pipelines, the full sequence of steps is determined at runtime rather than specified in advance. Appropriate for open-ended, complex tasks where the processing path cannot be predetermined. The most capable pattern and the most difficult to govern.

Error Propagation in Multi-Agent Systems

The failure modes of multi-agent systems are qualitatively different from single-agent failure. In a sequential pipeline, an error in Agent 1's output propagates into Agent 2's input. Agent 2 has no way of knowing what Agent 1 should have produced — so it processes the error as if it were correct. By Agent 4, the system may be producing confident-sounding but fundamentally wrong outputs.

This is why multi-agent architectures require explicit between-agent validation — not just error handling within each agent. Every agent-to-agent handoff in a pipeline handling consequential outputs should include a check that the output meets the minimum quality threshold for the next stage. This validation design is part of the architecture, not an implementation detail.

When Not to Use Multi-Agent

Multi-agent architectures carry significant design complexity, higher operational cost, and more complex failure modes. They are appropriate for tasks that genuinely require multiple specialised capabilities operating in coordination.

For tasks that can be completed reliably by a single well-prompted model, multi-agent architecture adds cost and complexity without benefit. The rule is simple: use the simplest architecture that accomplishes the task reliably.