A single agent with tools is a technical component. Once you have several agents that must coordinate, hand off work and share context, you no longer have an application. You have an organisation, with all the coordination problems that implies.
This framing matters because most multi-agent failures are not model failures. They are organisational design failures wearing a technical costume: unclear ownership, ambiguous handoffs, no escalation path, no single source of truth about what has already been done.
The patterns that actually get deployed
Supervisor and workers
One agent holds the goal and decides which specialist handles each step. Workers are narrow, each with a small tool set and a clear remit. The supervisor never does the work itself; it routes, collects results and decides what happens next.
This is the most common production pattern for good reason: it is debuggable. When something goes wrong there is one place to look for the decision that caused it. The trade-off is that the supervisor becomes a bottleneck and a single point of failure, and its prompt tends to accumulate special cases until it is the most fragile part of the system.
Sequential pipeline
Agents arranged in a fixed order, each transforming the output of the last. Extract, then classify, then draft, then check. This is barely multi-agent in spirit, and that is its strength. It is predictable, easy to test stage by stage, and easy to explain to an auditor.
Use it whenever the process genuinely has a fixed shape. Many teams reach for dynamic orchestration when a pipeline would have done, and pay for that flexibility in debugging time they never recover.
Hierarchical teams
Supervisors managing supervisors. A top-level agent delegates to domain leads, each of which manages its own workers. This mirrors a real org chart and scales to genuinely complex processes.
It also inherits the pathologies of a real org chart. Context degrades as it passes down levels, exactly as it does in a company. By the third layer the worker often has a distorted version of the original goal. If you deploy this, invest heavily in how context is preserved through delegation.
Blackboard and shared state
Rather than passing messages, agents read from and write to a shared workspace. Each watches for conditions relevant to it and contributes when it can. This handles genuinely non-linear problems well.
It is also the hardest to reason about, and the one most likely to produce emergent behaviour nobody designed. Use it where the problem truly demands it, and instrument it more heavily than you think necessary.
Rule of thumb from production experience: start with the simplest pattern the problem tolerates, and only add coordination complexity when a specific failure forces you to. Multi-agent systems rarely fail because they were not sophisticated enough. They fail because nobody could work out what happened.
The problems nobody demos
Context window economics
Each agent needs enough context to do its job. In a multi-agent system that context is duplicated across agents, often several times over within a single task. Costs scale worse than linearly with the number of agents, and latency accumulates at every hop.
Teams routinely discover this after the architecture is settled. Model the token cost of a full task run early, at realistic volume, before committing to a design with eight agents in it.
Error propagation
When a worker returns a subtly wrong result, the supervisor generally has no way to know. It passes the error downstream, where it is elaborated on rather than caught. Small inaccuracies compound into confidently wrong final output.
The mitigation is validation at boundaries rather than only at the end: structured output schemas, cross-checks against source data, and a verification step that has access to ground truth rather than only to the previous agent's claims.
Nondeterminism at scale
The same input can produce different routing decisions on different runs. For most business processes this is unacceptable. Two identical customer enquiries should not receive materially different handling because a supervisor chose differently on a Tuesday.
Constrain this deliberately. Deterministic routing wherever rules can express the decision, model-based routing only where genuine judgement is required. The instinct to let the model decide everything is usually wrong in production.
Observability debt
Debugging a single agent means reading a trace. Debugging twelve agents means reconstructing a distributed conversation across systems with no shared clock. Without proper tracing from day one, this becomes practically impossible, and it is the point at which promising projects get quietly shelved.
Enterprise deployment realities
Beyond the architecture itself, several things reliably surface during enterprise deployment.
Permission modelling gets complicated fast. Each agent needs scoped access, and the union of permissions across a team of agents can quietly amount to far more authority than any single human in the organisation holds. This is worth auditing explicitly rather than discovering during a security review.
Rate limits become an architectural constraint. A multi-agent system can generate a surprising volume of calls to internal systems that were sized for human usage patterns. Legacy systems in particular tend to fall over.
Failure handling needs to be designed, not added. What happens when a worker times out mid-task? Is the work resumable, or does the whole run restart? For long-running processes, restart-from-scratch is often commercially unacceptable, and retrofitting checkpointing is painful.
How to decide whether you need multi-agent at all
A useful test: could this be one agent with more tools? Frequently the answer is yes, and the single-agent version will be cheaper, faster and far easier to operate.
Multi-agent architecture earns its complexity in three situations. When different steps need genuinely different models, and running the expensive one throughout would be wasteful. When steps need different permission boundaries, and combining them would grant one component too much authority. And when parts of the work can run in parallel, and the latency saving is material.
Outside those cases, the extra agents usually represent an intuition that complex problems require complex architectures. In practice they mostly require clear ones.