"Multi-agent" is having a moment, and like most moments in AI it is arriving with more hype than engineering. The pitch is seductive: instead of one overloaded agent, deploy a team of specialists that collaborate like a well-run department. The reality is that every agent you add multiplies the ways your system can fail, and coordination between language models is a genuinely hard distributed-systems problem wearing a friendly chat interface. We build multi-agent systems in production — and the first thing we tell clients is that most problems do not need one.
This article is about the orchestration patterns that survive contact with production, when each earns its complexity, and the failure modes that will bite you.
First, decide whether you need multiple agents at all
A single agent with good tools and a clear prompt handles more than people expect. You should reach for multiple agents only when at least one of these is true:
- Context isolation — subtasks need genuinely different instructions, tools or knowledge, and cramming them into one context window degrades all of them.
- Parallelism — independent subtasks can run at the same time, and latency matters enough to pay for the coordination overhead.
- Separation of concerns — you want a component you can evaluate, version and swap independently, such as a dedicated safety reviewer.
Every agent boundary is a place where information gets lost in translation. Add a boundary only when the isolation it buys you is worth more than the coherence it costs.
If none of those apply, a single well-instrumented agent will be cheaper, faster to debug, and easier to trust. Complexity is a cost you pay forever; pay it deliberately.
Pattern 1: Supervisor (orchestrator–worker)
The pattern we reach for most is a supervisor agent that decomposes a task, delegates subtasks to specialised workers, and synthesises their results. The supervisor owns the plan and the user relationship; the workers own narrow, well-defined jobs and never talk to the user directly.
This works because it keeps control centralised and legible. There is one place where the plan lives, one place to add a guardrail, and one clear answer to "why did the system do that?" The workers can be tuned, evaluated and cached independently.
def supervisor(task):
plan = planner.decompose(task) # ordered list of subtasks
results = {}
for step in plan:
worker = registry[step.agent] # pick the specialist
results[step.id] = worker.run(
step.instruction,
deps={d: results[d] for d in step.depends_on}
)
return synthesizer.combine(task, results)The trap: supervisors love to over-delegate. If every trivial step spawns a worker, you pay a full model round-trip for work a single call could have finished. We cap delegation depth and require the planner to justify why a subtask deserves its own agent.
Pattern 2: Pipeline (sequential specialists)
When a task has a natural order — retrieve, then draft, then critique, then format — a pipeline of agents each transforming the previous stage's output is simpler and more reliable than a dynamic planner. Each stage has a fixed contract: known input shape, known output shape. Because the flow is deterministic, it is trivial to test, cache and observe, and a failure localises to exactly one stage.
We use pipelines wherever the sequence of steps is stable and known in advance. You lose flexibility, but for well-understood workflows that predictability is the entire point. Do not use a reasoning-heavy dynamic orchestrator to solve a problem a straight pipeline handles.
Pattern 3: Debate and review
For high-stakes outputs, a generator–critic pair meaningfully improves quality. One agent produces a candidate; a second, prompted adversarially, tries to find flaws; the generator revises. This maps neatly onto real work — a drafter and a reviewer — and it catches errors a single pass misses, because the critic is not anchored to the generator's reasoning.
The cost is latency and tokens, so we reserve it for outputs where being wrong is expensive: a compliance summary, a customer-facing commitment, a code change. And we cap the rounds. Two agents can happily argue in circles forever; a hard limit of one or two revision rounds keeps cost bounded and, in our testing, captures nearly all the quality gain.
Pattern 4: Blackboard (shared state)
Occasionally agents genuinely need to collaborate on a shared, evolving artifact rather than pass messages linearly — several agents contributing to a plan, a document, or an investigation. A shared "blackboard" (a structured state object) lets each agent read the current state and contribute, coordinated by a controller that decides who acts next. It is powerful and it is dangerous: shared mutable state between non-deterministic actors is exactly as hard as it sounds. We use it rarely, and only with strict schemas and a controller that enforces turn-taking.
The failure modes that will actually bite you
Whatever pattern you choose, the same problems recur across multi-agent systems, and designing for them up front is the difference between a demo and a product:
- Error propagation. A confident mistake early in the chain gets treated as ground truth by everything downstream. Validate at boundaries; never let one agent's output enter another's context unchecked.
- Cost and latency explosion. Five agents is five times the tokens and, if sequential, five times the latency. Parallelise independent work and budget a token ceiling per request.
- Context loss. Each hand-off is a lossy summary. Critical constraints ("the customer is in the EU") quietly evaporate three agents deep. Pass structured state, not prose, for anything load-bearing.
- Debuggability collapse. When something goes wrong across six agents and forty tool calls, "read the logs" is not a plan. You need distributed tracing from day one.
The hardest part of multi-agent systems is not making agents cooperate — it is being able to explain, after the fact, why they did what they did.
Observability is not optional
We instrument every agent system with end-to-end tracing: a single request ID threads through every agent invocation, tool call, prompt version and token count. Without it, a multi-agent system is a black box that occasionally misbehaves and never tells you why. With it, you can replay any production interaction, see exactly which agent went off the rails, and turn that trace into a regression test. This is the unglamorous infrastructure that separates teams who operate agents from teams who merely launch them.
Our default advice
Start with one agent. Add a second only when you can name the specific isolation, parallelism or evaluability it buys. Prefer supervisor and pipeline patterns — centralised, legible, testable — over free-form agent swarms that look impressive and debug like a nightmare. Cap delegation depth, cap revision rounds, cap token budgets. And instrument everything, because in a system of collaborating language models, the ability to answer "why?" is the whole game.
Multi-agent architectures are a genuinely powerful tool. They are also the easiest way we know to turn a working prototype into an unmaintainable one. Reach for them deliberately, wire them for observability, and they will earn their keep.