The pattern that everyone tried first, and mostly got wrong
By late 2024, every AI architecture deck had the same slide: a supervisor agent at the top, a handful of specialised sub-agents below, arrows crisscrossing everywhere. By mid-2025, the same teams were quietly rewriting those systems as single-agent pipelines with well-defined tools. Not because multi-agent is wrong – but because most teams shipped the pattern before they needed the complexity, and paid for it in latency, cost, and debugging time they did not plan for.
In 2026 the picture is clearer. Multi-agent orchestration is a genuinely useful pattern for specific problem shapes. It is also the wrong answer for the majority of enterprise use cases, where a single well-tooled agent with a strong evaluation harness beats a supervisor-and-workers setup on every axis that matters. Deciding which camp a given problem is in is the architectural decision most teams still get wrong.
When a single agent is enough
The default for enterprise deployments in 2026 should be a single agent with a carefully curated tool catalogue, a strong system prompt, and a well-maintained evaluation suite. That architecture handles a surprisingly large share of real work – customer support, sales assistance, internal knowledge search, document review, data extraction – with less complexity and lower cost than a multi-agent equivalent.
The reason is straightforward: modern models are good at tool use. Claude, GPT, and Gemini can reliably orchestrate 10-30 tools inside a single context, handle multi-step plans, and recover from errors. The overhead of splitting those capabilities across multiple agents – prompt boilerplate for each, inter-agent communication, duplicated context, added latency – is a real tax, and for most workloads the tax exceeds the benefit.
When multi-agent earns its complexity
There are four problem shapes where multi-agent is genuinely the right architecture, not just a fashionable one.
- True parallel work. If a task decomposes into independent subtasks that can run concurrently – research across five different sources, generate four variants of a design, validate against three separate rule sets – parallel agents deliver wall-clock speedups that a sequential single agent cannot.
- Heterogeneous skill profiles. When different subtasks genuinely benefit from different models – a cheap fast model for routing, a frontier model for complex reasoning, a specialised code model for generation – a multi-agent architecture lets each step run on the right cost/quality point.
- Isolation of privileged capability. If one subtask requires elevated permissions (write to production, send external email, move money) and others do not, separating them into distinct agents with distinct permission scopes is a security win, not a complexity cost.
- Organisational or cross-team workflows. When "agent A" is owned by one team and "agent B" by another, each with their own lifecycle, eval suite, and release cadence, protocol-level separation (e.g. via A2A) lets them evolve independently without coordinating rewrites.
The three topologies that work
Across the multi-agent deployments we have worked on, three topologies have survived contact with production. Others exist in research papers and rarely land cleanly in enterprise environments.
- Supervisor / workers. A single orchestrator decides which specialised worker to invoke, aggregates results, and presents the final response. Best for heterogeneous-skill workloads with predictable routing.
- Pipeline / hand-off. Agents pass control sequentially, each transforming the state and handing off to the next. Best for workflows with clear stages (triage → resolve → close) and stable stage definitions.
- Parallel / voter. Multiple agents tackle the same task independently; a judge or voter picks the winner. Best for high-stakes decisions where diversity of approach improves robustness (legal review, adversarial classification, safety evals).
The failure modes to design against
Multi-agent systems fail in ways single-agent systems do not. Four of these are common enough that designing against them from day one saves most of the pain.
- Context sprawl. Each agent needs relevant context, and handoffs either duplicate it (expensive) or compress it (lossy). Design the handoff schema up-front, treat it as a versioned contract, and test it with adversarial payloads.
- Cascading errors. An early agent's small mistake becomes a later agent's confident premise. Build per-step confidence scoring and a supervisor-level "am I still on track" check.
- Loop detection. Two agents deferring to each other, or a supervisor re-dispatching the same task, will burn tokens fast. Hard step-count caps and diversity checks on successive tool calls are baseline.
- Cost opacity. A multi-agent request can make 30-50 LLM calls behind a single user action. Per-request cost tracking (token count rolled up across agents) belongs in observability from day one, not as a later addition.
Evaluation is harder, and mandatory
A single-agent system has one thing to evaluate: the final response. A multi-agent system has many: the plan, the routing, each worker's output, the aggregation, and the final response. Teams that treat multi-agent evaluation as "same as single-agent" ship brittle systems and then cannot diagnose regressions.
The practical framework: evaluate the final output as the headline metric; evaluate planning quality (did the orchestrator pick a sensible decomposition?) as a separate axis; evaluate per-worker quality with narrower rubrics; and track trajectory metrics (steps taken, tools used, retries) as health indicators. Any serious multi-agent deployment in 2026 also tracks cost-per-task and p95/p99 latency per workflow, because multi-agent systems widen the latency distribution substantially compared with single-agent baselines.
The upgrade path from single to multi
A useful piece of architectural discipline: start single, measure pressure, then split. If a single-agent implementation is hitting a real wall – latency on sequential calls that could be parallel, a tool or capability that needs permission isolation, a workload that a smaller model can cheaply handle for half the steps – those are the pressures that justify splitting. If the push toward multi-agent is coming from "it feels more sophisticated," the upgrade is usually premature.
The architectures that age well are the ones that can collapse back. Write each agent's tool catalogue as a coherent MCP server, and the same tools can be consumed either by a single orchestrator or by distinct specialised agents. That single discipline – tools as the durable asset, agent topology as the replaceable scaffolding – is what makes the difference between architectures that evolve gracefully and ones that calcify around last year's fashion.
