Multi-Agent
Orchestration
Most teams asking for a multi-agent system need one well-built agent instead. We'll tell you which you are before you spend anything — and if you genuinely need orchestration, we'll build it so it doesn't join the failure statistics.
Architecture reviews, rescue work, and full builds. Fees from [FILL: entry price]. Full price table below.
30 minutes. Bring your use case or your existing system. You'll leave with a recommendation — including “you don't need this,” which is the answer more often than not.
The research on multi-agent systems is not what the marketing says
The most rigorous work on this is MAST — the Multi-Agent System Failure Taxonomy (Cemri et al., NeurIPS 2025 Datasets & Benchmarks spotlight). The researchers annotated over 1,600 execution traces across seven popular multi-agent frameworks and built a taxonomy of 14 distinct failure modes in three categories: system design issues, inter-agent misalignment, and task verification failures.
Their opening finding is the one worth sitting with: despite the enthusiasm for multi-agent systems, their performance gains on popular benchmarks are often minimal.
Two things follow that most vendors won't tell you.
First, better models won't fix it.
The paper concludes that improvements in base model capability will be insufficient to address the full taxonomy. These are architectural and coordination failures, not intelligence failures. They're the same problems classical distributed systems spent decades on — and waiting for GPT-6 won't resolve them.
Second, the failures cluster in the specification and coordination layers.
Analyses of the MAST data attribute roughly 42% of failures to specification problems, 37% to coordination breakdowns, and 21% to weak verification — meaning around four in five failures come from how the system was specified and how agents hand off to each other, not from the agents themselves.
Agents can't ask a clarifying question mid-task, can't read between the lines, and can't tell when a handoff has gone wrong. Every ambiguity in the spec becomes a fork in behaviour. Every handoff is a place where context is lost.
The cost nobody models upfront
Multi-agent doesn't cost proportionally more. It costs non-linearly more, and the compounding is invisible until the bill arrives.
Anthropic's engineering team measured this in production: agents typically use around 4× the tokens of a chat interaction, and their multi-agent research system used around 15×. A UIUC study found multi-agent systems consuming anywhere from 4× to 220× the tokens of single-agent equivalents. A 2026 production benchmark measured 4.3–4.6× from inter-agent communication alone. Without deliberate context isolation, an unoptimised system can run around 8.5×.
Then there's the overhead that isn't tokens at all:
- Tool schema tax. In multi-server MCP deployments, practitioners report roughly 10,000–60,000 tokens of schema per turn, rebilled on every iteration before any reasoning happens. Benchmarking suggests schemas can account for 60–80% of token usage in static toolsets.
- Model API costs are only 8–15% of total build cost for most enterprise agentic systems. Integration and development regularly exceed initial estimates by 30–50%.
- Maintenance runs 15–30% of development cost annually — before anyone is paid to operate it.
- Operational multiplication. Three agents means three deployment pipelines, three sets of version management, three surfaces to monitor, and debugging complexity that grows with every interaction path.
And the crossover point moves against you. One documented deployment ran a multi-agent architecture successfully at 100,000 queries a month, then found the coordination overhead crushing at 2.9 million — the same design, the same code, a different economic reality.
The number that should decide most of this: a 2026 analysis of 47 production deployments found 68% could have achieved the same result with a single well-built agent, at roughly a third of the cost.
When multi-agent genuinely wins
It isn't never. The pattern earns its place under specific conditions, and when it does the gains are real — Anthropic's multi-agent research system, with a lead agent directing sub-agents, outperformed the equivalent single-agent setup by 90.2% on their internal research evaluation, because information gathering genuinely parallelises.
The conditions that justify it:
Genuinely parallel work
Independent branches that can run simultaneously — broad research, multi-source gathering, batch processing across unrelated items. If your task graph is strictly sequential, multiple agents add coordination cost for no throughput gain.
Hard permission boundaries
One agent may read customer PII, another may not. Separate scopes enforced architecturally rather than by prompt is a legitimate reason to split.
Context that genuinely won't fit
The honest original reason for splitting: context windows are finite and some tasks aren't. Splitting is the tax you pay for that, not a design virtue.
Multi-team ownership
Different teams owning different agents with defined contracts between them, for organisational rather than technical reasons.
Compliance separation
Regulated steps that must be independently auditable.
If none of these describe your situation, one agent with well-described tools will be cheaper, faster, more reliable and easier to debug. We'll say so.
Worth knowing: Microsoft's own Azure SRE team built toward multi-agent specialisation and then reversed course, having found that handoffs hurt reliability. Microsoft's Cloud Adoption Framework now advises validating cost benefits by prototyping single-agent first, before adding orchestration overhead. That's the vendor whose platform sells orchestration.
What we do
Architecture review
Before you build. We take your use case, model the cost of both architectures, identify whether your workload actually parallelises, and give you a recommendation with the reasoning written down. Frequently the recommendation is one agent, and that answer saves more money than any build we could sell you. [FILL: whether this is standalone-priced or free — see the pricing note.]
Rescue and audit of existing systems
The largest category of work in this space right now. You have a multi-agent system that demoed well and doesn't hold up. We trace it against the MAST failure categories — specification, coordination, verification — identify which of the 14 modes are actually occurring in your traces, and fix or consolidate. Often the fix is fewer agents, not better prompts.
Orchestration builds
For the cases that warrant it. Designed with explicit contracts, structured handoffs, and verification layers to avoid the failure modes that take down most deployments.
Consolidation
Taking a sprawling multi-agent system back to one or two agents without losing capability. Unglamorous, and frequently the highest-ROI engagement available.
How we build orchestration that holds up
Given that ~79% of failures trace to specification and coordination, that's where the work goes.
Specification first
Each agent gets an explicit, unambiguous contract: what it owns, what it must never do, what it receives, what it returns, and in what format. Vague prose specs are the single largest failure category. Agents can't infer.
Structured handoffs
Typed, validated messages between agents rather than free-text passing. Context is scoped explicitly at each transfer — what flows downstream is a decision, not a default, which is how context explosion is prevented.
Independent verification
A verification layer that doesn't share the assumptions of the agent it's checking. The third MAST category exists because agents routinely fail to catch each other's errors when they've inherited the same framing.
Distributed tracing from day one
Every agent interaction traced, with token usage, latency, success rate and error rate per agent, plus cost per completed workflow. Debugging a multi-agent system without traces is guesswork, and it's how the 2am incidents become week-long ones.
Cost modelling before build
Token amplification, schema overhead, retries, verification passes and the maintenance line — modelled against your actual volume, with the crossover point identified. You should know before you build at what scale the architecture stops making sense.
Failure isolation
One agent failing shouldn't cascade. Timeouts, circuit breakers, defined degradation paths, and a route back to a human.
Evaluation at the workflow level
Measured on completed outcomes, not per-agent metrics. Per-agent numbers can all look healthy while the workflow delivers nothing — that gap is where most orchestration monitoring programmes fail.
Start with the smallest version that works
One agent, proven, then split only where the evidence demands it.
What it costs
What moves the price: number of agents and handoffs, whether the specification exists, integration count, verification requirements, and whether you need it operated or handed over.
What's not included: model usage and infrastructure, billed to your accounts. Expect meaningfully higher token spend than a single-agent equivalent — we model it before you commit, so it isn't a surprise.
Ongoing cost: budget 15–30% of build cost annually for maintenance. Anyone who tells you a multi-agent system is fire-and-forget hasn't operated one.
What you can expect
The published evidence says most multi-agent deployments underperform their single-agent equivalents on cost, and a majority could have been built as one agent. We start from that assumption and require evidence to move off it.
Not because specialisation feels intuitively right. The human-team analogy is what sells multi-agent architectures and it's also what misleads people: human specialists ask each other questions, notice when a handoff went wrong, and self-correct. Agents do none of that.
[FILL: one real deployment or rescue with client-verifiable numbers. A rescue case study — “they had six agents, we shipped two, cost fell X%” — would be the single most persuasive asset for this page.]
Security in multi-agent systems
Multi-agent architectures expand the attack surface in ways single-agent systems don't.
Permission scoping per agent
Least privilege enforced architecturally, not by instruction. If one agent shouldn't reach customer data, it shouldn't hold the credential.
Injection across handoffs
Content read by one agent becomes input to another. If untrusted content passes as instructions rather than data, injection propagates through the chain. Every inter-agent message is treated as data.
No confused-deputy paths
A low-privilege agent must not be able to induce a high-privilege agent into acting on its behalf.
Full audit trail
Every agent action, every handoff, every tool call logged with the reasoning attached.
Irreversible actions gated
Payments, deletions, outbound messages behind human confirmation regardless of which agent proposes them.
Hosting & Compliance
[FILL: hosting options, retention, certifications you actually hold.]
Frequently asked questions
Find out whether you need one agent or several
Book a free architecture review. Bring the use case, or the system that isn't working. You'll get a recommendation with the reasoning written down, a modelled cost comparison of both architectures, and an honest answer — which is “you need one agent” more often than not.