Multi-Agent Systems in Production: What Actually Works (and What Burns £40k)

AI’s runaway agent production story is a familiar tale in the industry: an experiment involving a team of engineers and four AI agents tasked with running a market research exercise. In the first week, they spend around £100. In the fourth, costs are over £14,000. The root of the matter? Two agents get stuck in an infinite loop that went undiscovered until day 11 of the experiment, and by the end the costs come to some £40,000. There was no stop condition, nothing. No budget guardrails, no meaningful observability. It wasn’t a problem with the agents. It was a problem with the agent environment.

If you’ve played with multi-agent systems, you have likely heard this story. Multi-agent demos are cool, they really, really are. It’s fun to watch a swarm of agents work out what’s the best way to accomplish a task, split work between the agents and synthesise a report. It kind of feels like you’re building JARVIS.

Then you go into production and realise that there is a world of difference between what you showed a stakeholder in a demo and what you can actually deploy to production overnight. This article covers the reliability maths behind multi-agent systems, all the different failure modes that underpin reliability, and some real talk about whether there is a case for building with multiple agents at all.

What multi-agent actually means

Let me establish a working definition of multi-agent since the term gets thrown around carelessly. A multi-agent system is a set of agents (each agent is itself an LLM), each having access to a collection of tools, all running on their own loop autonomously and in collaboration to finish a task. The typical multi-agent system has an orchestrator that delegates the work to other agents (the “workers”). The orchestrator is one LLM responsible for planning and distributing the overall task. The workers are other LLMs, typically different from the orchestrator, that do some portion of the work. The orchestrator then combines the work.

There is a difference between this and a single agent that has a lot of tools, and also a difference from a multi-step pipeline that sometimes uses an LLM. The key insight for multi-agent systems is not any particular agent, but how well multiple agents are coordinated.

So it is important to be explicit about the reasons and scenarios in which a multi-agent architecture is chosen. There are cases when it is useful: when a task can be parallelised, when the task exceeds the context window of one agent, or when some agents can perform unique tasks that a single agent cannot do. However, most of the time this isn’t the case. Teams use multi-agent systems because the diagram looks nice, or because the tool makes it easier to build.

The reliability maths nobody puts in the demo

Before you start building complex agentic workflows with multiple agents, there’s one fundamental thing you need to understand. It’s nothing more than grade-school maths.

Let’s say an agent is accurate 95% of the time, which is considered reliable, and you then chain five agents that build on one another. The system-wide accuracy is not 95%. It is 0.95 to the fifth power, which is about 77%. With ten steps it is already in the 60% range. That is not production-ready reliability. It’s liability dressed in a tailored suit.

So don’t think about that one-shot prompt you’ve been testing for eight months as something you’re about to replace with a six-agent research pipeline that you trash once the hallucinations compound after four agents. The swarm doesn’t care about those numbers.

The four ways multi-agent breaks in production

They aren’t random. There are four main classes of failure.

Failure 1: Context loss

Every time an agent seeks an assist, it is losing some context. One engineer describes the process as a game of Telephone.

“By the time you hit the fourth agent, it is literally just making things up.”
// PRODUCTION ENGINEER, LLM-NATIVE STARTUP

Even though the lead agent knows the objective, that fourth subagent is three steps removed from it. All it has to work with is a version of the goal that has been heavily compressed and that loses information along the way. This information vacuum gets filled with confident hallucinations.

Failure 2: Cost explosion

This does not scale nicely, because coordination is costly. You can turn a 10p bill into a £1.50 bill by accounting for all the handoffs, retries, and context reconstruction. But leave an unprotected loop in that chain, and that multiple stops being a multiple and starts being an exponential. That’s how you end up with a £40,000 bill from four agents.

Failure 3: State collision

This is the most painful, and least noticeable, error. Two agents read off the same shared context, process it independently, and then one of them overwrites the state of the other. It does not produce an error in the system. It looks plausible enough, and then there is the wrong result.

“Zero errors, plausible output, wrong result.”
// LEAD ENGINEER ON A 5-AGENT PIPELINE

If you have ever debugged a race condition in a distributed system, you know what that feels like. You also know it is not an AI problem specifically.

Failure 4: Debugging hell

Once a five-agent chain gives you a wrong result, how do you know which of the five steps in the chain was the culprit? More often than not, the issue at play cannot be reproduced, because the chain will go along a completely different path in the second run. A debugger can tell you which steps the system took, but it can never tell you why. So debugging becomes a game of blame-the-agent, and oftentimes the root cause is several steps upstream.

What actually holds up in production

Those same points are confirmed by the experts who’ve actually built functional multi-agent systems. Almost none of those recommendations involve having agents run the show.

1. Centralised orchestration

There is a lead agent that controls global state, reasons at the level of high-level strategy, distributes subtasks to narrow-domain specialists, and synthesises all results together along with relevant confidence scores. The specialists stay extremely focused. They are strictly not allowed to go off-roading. This is the orchestrator-worker pattern, and it is by far the most common pattern in production-grade systems. It has been used for drug compliance checks and risk modelling at banks.

I cannot overstate the importance of this: when systems run with no centralised orchestration, error rates go up by a factor of 17. With centralised coordination, error rates only go up by a factor of 4.

2. State ownership

Do not design your agent architecture such that you share mutable state across agents. Instead, let each agent own its own state, and broadcast that state as an immutable event summary through a centralised log. This log can be anything: Redis Streams, or just a Postgres table. By changing the state management in this way, you automatically eliminate a class of bug involving two agents trying to read and overwrite the same piece of shared state, because with this design that situation is not even possible.

3. Guardrails, every kind

This means setting a budget for tokens, or cost, or both, and enforcing it from the system’s entry point. It means:

• A circuit breaker, so that when the system begins to output a high error rate it is turned off
• A step or iteration limit, with an alert when the threshold is reached
• A human confirmation step for any action with significant financial cost or potential for irreversible damage
• Anything that leaves the sandbox and impacts the real world must follow a workflow that resembles suggestion followed by human confirmation

None of this is novel. But it is exactly the stuff that distinguishes the systems we are allowed to leave unattended (the ones that do not lose their budget by the end of Sunday evening) from those that will.

4. Treat code as more competent for flow control

I’m a little surprised I have to say this, but: the orchestration system’s control flow needs to live in deterministic code. The agent (the LLM) should only be solving for the bits of the problem that are actually ambiguous.

The most reliable systems I’ve seen view LLM agents not as agents responsible for every part of a complicated workflow, then given the authority to do what’s best in the whole world, but rather as fallible workers who operate in a highly controlled orchestration layer and receive very precise instructions about when and how they’ll work.

The frameworks, honestly

The tool you choose depends on what you’re building, but the choice makes a real difference.

LangGraph

What most people use, particularly if you aren’t deeply entrenched in one cloud ecosystem. Useful features: control flow, checkpoints, state persistence, human-in-the-loop, and tracing and observability via LangSmith. The most common criticism is unnecessary overhead for the simplest use cases. Runtime graphs are not a bad thing, they’re just heavy for trivial tasks. Many teams have stuck with it and adopted it as a standard.

CrewAI

Great if you need a fast role-based demo or proof of concept. The concept of an agent team is straightforward and easy to implement. However, maintaining an agent delegation hierarchy over long-running applications is more challenging, with limited control over state, and if not carefully managed it can easily loop. A frequent pattern is prototyping with CrewAI then recreating the runtime orchestrator with LangGraph for production.

AutoGen

Suited to more exploratory, conversational multi-agent tasks, especially on heavy Azure stacks. Without caps it is full of unpredictable loops, and state management isn’t a strong suit.

OpenAI Swarm and the Agents SDK

Very intentionally minimal on both abstractions and ergonomics around agent handoff. Explicitly experimental, with no persistence, state, or error handling out of the box. Teams that want to move to production are ripping and replacing them, or otherwise substantially extending them.

The honest answer from seasoned teams

A significant portion of seasoned teams would answer this with: build your own custom code and API-call orchestration directly, no frameworks at all, and use n8n or similar for scheduling. Yes, it’s more work upfront. But it’s the only way to truly control costs, state, and guardrail logic. And to avoid hiding critical failure modes inside a framework when your 3am incident report comes in.

The 80% nobody shows you

That’s the part the demos really don’t say anything about. Many production deployers share a similar ratio: 70% to 90% reliability scaffolding, 10% to 30% agent logic.

“The agent logic is the fun 20. The other 80 is the stuff that keeps the whole thing from blowing up.”
// PRODUCTION DEPLOYER

Reliability scaffolding always includes:

• Observability: one trace per request, with a root orchestrator span and a child span per agent and tool call, typically using LangSmith, Langfuse, or Arize Phoenix.
• Error handling: circuit breakers, hard timeouts, propagated budgets, loop detection, and retries with backoff to a simpler model or to a human.
• Guardrails: per-agent permission scoping, a tool allow-list, and schema checks before every action, plus a kill switch and sandboxed tool execution.

This is a non-trivial amount of work. Doing the reliability scaffolding right often takes 2x to 5x more engineering than the agent logic itself. Teams that don’t do a great job of it don’t save that effort. They incur the cost later, often as a half-abandoned project and another memorable budget line item.

When you should not build multi-agent at all

The most valuable guidance an experienced team can offer is about when not to. The appropriate recommendation on multi-agent is often “maybe not now,” and “maybe not as the default.”

A single, accurately prompted and properly tooled agent can often get the precision you need for your goal. Multi-agent doesn’t give you a free lunch on latency. It introduces additional coordination expense with no apparent positive return, and sometimes a damaging one. If you are operating with work that is primarily sequential, where agents simply need to talk at a key handoff point, you cannot reasonably afford the cost of exchanging context between them. The added complication will not be worth it.

Numerous groups have spent weeks developing a multi-agent swarm only to finish up with just a prompt and a script. Cognition, the team behind Devin the AI programmer, has written about this in depth in a post titled Don’t Build Multi-Agents. They explain how multi-agent systems tend to be fragile, partly as a result of separated context between agents and conflicting, implicit choices. Shopify’s engineers caution against creating multi-agent architectures at an early stage.

You really only need multi-agent when one of these statements holds true:

• The work is genuinely parallel and you are exchanging latency for token expenditure
• The contexts truly need to remain divided
• The task is too much for the context window or the capabilities of a single agent

If not, then why add complication you don’t have to?

The cases where it genuinely earns its keep

Multi-agent doesn’t mean the solution is dead. Where there’s a good match between the use case and the technology, and the engineering is done right, it can get the job done.

The best public example I know of is Anthropic’s own multi-agent research system. In their system, a lead agent generates three to five subagents, which then run independent parallel searches, each with its own context window. They reported 90% less research time on complex questions, and around 90% better performance in internal tests over a single agent. Each run costs roughly 15x the tokens of one turn, which they admit up front. In Anthropic’s case this is an acceptable tradeoff given the purpose of deep-dive research, as opposed to verifying something like a simple factual question. That’s the crux: the right tool for the job.

There are other cases as well. Developers have built numerous pipeline-based multi-agent systems with agents that act as explorers, analysts, authors, and critics, claiming 2x task completion and fewer calls to tools. One company built a multi-agent pipeline to process insurance claims sequentially with a human agent to authorise them. A team of twelve was reduced to four full-time staff, running thousands of claims per month, with the system being reliable and accurate, costing just a few euros in LLM spend per claim, and paying for itself after six months.

The common thread in all these cases is hierarchy, specialised agents, tight guardrails and milestones, and human review where it matters.

Where this leaves you

Basically, there are two parts. One is “get the agent to do its job.” The other is “make the whole system observable, consistent in state, and robust enough that one rogue agent doesn’t break everything.” The second part is by far the most complicated. That’s the part you won’t see in most demos, because it isn’t particularly interesting in a demo, and it’s probably something you’re going to have to build out before you can have a production environment at all.

Start small. Get one agent that can reliably do one thing, build out the tooling, and then add as many of those things as you actually need. Once you get to the point where you’ve got more than one agent interacting, you need to build a controlled environment where you can deal with the chaos of autonomous agents, so that one agent can’t go rogue and do whatever it wants. You’ll end up spending the majority of your time building the scaffolding of your system rather than writing your prompts.

That’s how we approach all of these projects at Pixelfield: go quickly and deploy to production quickly, but never ship something fragile. It’s easy to make a demo and a lot of work to make a production system. That’s usually where we start conversations with clients around agentic architecture. Our AI agents development and AI workflow automation work are both good places to start if you’re unsure whether you even need one agent, two agents, or maybe none at all.

For the broader business case behind agentic systems, see our Complete Beginner’s Guide to AI Agents for SMEs. For the knowledge side of the same stack (when your agents need to “know your business”), see Practical RAG for UK SMEs.