AI Agent Orchestration vs Choreography: The 15x Token Tax

A single agent performs beautifully in a demo. The room is sold. Then it meets production traffic and quietly falls apart. Scale it into a multi-agent system without a plan and you get circular loops, contradictory outputs, and logic collisions nobody can explain. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.

The instinct when an agent misbehaves is a better prompt or a bigger model. Both help. Stanford HAI's 2026 AI Index records agents moving from answering questions to completing tasks, with accuracy on computer-use benchmarks rising from roughly 12% to 66%, while still failing roughly one attempt in three. Capability moves the number. It doesn't change the shape of the curve. Structure does.

The architecture nobody chose

Most engineering teams don't choose their multi-agent architecture. They fall into it.

The default is choreography: agents react to events and broadcast outputs into a free-form mesh, with no central authority checking the work. It borrows the topology of the choreography variant of the Saga Pattern from microservices (event-driven, decentralized, no conductor) but without Saga's compensating transactions, which is the part that makes failure recoverable.

The math is unforgiving. Every agent you add opens a path to every agent already there: n(n−1)/2 in total. Two agents have one path. Five have ten. Ten have forty-five. The state space is worse: because system state is the combination of every agent's state, it grows exponentially, not linearly.

But the real problem isn't complexity. It's that a choreographed system fails plausibly. A microservice fails in ways that surface: an exception, a failed health check, a broken contract. An agent chain fails silently, and the failure gains credibility at every handoff.

This has been measured. Google Research found that multi-agent systems whose agents worked in parallel without cross-checking amplified errors by 17.2x, while systems with a central orchestrator contained amplification to 4.4x. The orchestrator acts as a validation bottleneck. Note that 4.4x is containment, not elimination. Orchestration reduces the blast radius; it does not remove it.

The 15x token tax: what it buys

Here's the objection you're about to raise, so let's take it head-on. True orchestration needs a lead agent that plans every step, manages every handoff, and synthesizes every result. Anthropic's multi-agent research reports multi-agent systems consuming roughly 15x the tokens of an ordinary chat interaction, or about 4x a comparable single-agent setup. Orchestration is the expensive option, and there is no version of it that isn't.

What the premium buys is the difference between tracing a hallucination and guessing at one. In a choreographed system you reconstruct fragmented logs across event streams. In an orchestrated system, coordination runs through a single thread.

One myth worth killing: orchestration is not inherently slower. A lead agent runs its sub-agents in parallel. Anthropic reports cutting research time by up to 90% on complex queries by doing exactly that. The cost is tokens and coordination overhead, not latency.

And the 15x is gross, not net. Much of what an agent spends tokens on is rediscovering context it should have been handed: querying systems, reconciling records, rebuilding relationships that already exist somewhere. Correlate that context before the agent runs and the per-decision cost drops sharply. In OnStak's AIOps work we see a typical 15-20× token reduction per decision from that alone. So the honest framing isn't 15x more expensive. It's: you pay a coordination premium, and you can claw most of it back on the context side.

The number worth putting in front of a CFO isn't the multiplier. It's the fully loaded cost of one decision, the same claim assessed or the same alert triaged, run both ways, with rework and unexplainable outputs priced in. That number is knowable.

The 95% fallacy, and the guardrails that fix it

Reliability compounds multiplicatively. A chain is only as good as the product of its steps. At 95% success per step, a number most teams would call production-ready, a 20-step chain completes about 36% of the time. Push every step to 99% and you're still at 82%. That's not a rounding error hiding behind a good-looking slide; it's a coin flip with worse odds.

The empirical picture matches. METR's evaluations of frontier models find success rates falling off sharply as task length grows: near-perfect on tasks a human would finish in minutes, dropping steeply on tasks measured in hours. The failure isn't in any single step. It's in the length of the chain.

Which means the fix isn't a better model. It's putting deterministic code where the model doesn't belong. Reserve the model for decision points that genuinely need open-ended reasoning; everything else (branching logic, state management, stopping conditions) belongs in conventional code. Concretely, every long-running chain needs:

Hierarchy is about accountability, not intelligence

The structural answer to a flat mesh is a hierarchy, and the shape has converged across both the research and the frameworks teams actually ship on. A lead agent owns the objective and decides what happens next. Specialized agents beneath it do bounded work with the tools their job requires. Nothing broadcasts sideways.

Hierarchy solves the coordination problem. It doesn't solve the context problem, and the two get confused: a lead agent can sequence work perfectly and still hand its sub-agents fragmented or contradictory context. That upstream layer is where OnStak's AI Correlation Fabric (patent-pending) sits.

None of this makes any individual agent smarter. It makes the system accountable. That's a different property, and for enterprise deployment a more useful one.

When orchestration is the wrong answer

Orchestration is not free and it is not always right. The same Google Research work gives a usable decision rule: coordination helps most on tasks that genuinely decompose into independent parallel work, and hurts on tasks that are inherently sequential, where it degraded performance substantially. It also identifies a capability threshold: once a single agent already clears roughly 45% accuracy on your task, adding agents tends to produce diminishing returns or outright regressions, because coordination overhead starts to dominate.

The practical read: if a task is high-volume, low-stakes, naturally parallel, and a single agent already handles it well, a lighter event-driven pattern is the correct engineering choice and orchestration is over-engineering. Orchestration earns its cost when a wrong answer is expensive, when the chain is long, or when somebody will eventually ask you to prove how a decision was reached. Match the topology to the task, not to the trend.

The plumbing is standardizing: A2A and MCP

For two years, connecting an agent to a tool, or to another agent, meant bespoke work every time. That's ending, driven by the largest players rather than by any one framework.

Agent2Agent (A2A) connects agents to each other. Google donated it to the Linux Foundation in June 2025, where a multi-vendor steering committee maintains it; it reached v1.0 in March 2026, with the Foundation counting support from more than 150 organizations as of April 2026.

Model Context Protocol (MCP) connects an agent to tools and data. Anthropic donated it in December 2025 to the Agentic AI Foundation, a separate Linux Foundation entity. A significant revision shipped on 28 July 2026, moving to a stateless request/response model and tightening authorization requirements. Anthropic describes MCP as a USB-C port for AI applications: one standardized way in, instead of a connector per integration.

A third track opened in July 2026: a Linux Foundation-hosted alliance building open tooling for securing and auditing agent behavior. That's a reasonable signal of where enterprise scrutiny heads next.

The consequence for architects is that the integration layer is becoming less of a differentiator, which makes what sits above it more of one. Model routing is where that shows up first, and three strategies have settled out:

Which one fits depends on where the agent sits in your portfolio and what a wrong answer actually costs you.

When the judge gets gamed

There's a hole in everything above, and it's worth naming. Hierarchy works because the lead agent checks the work, which raises the obvious question of who checks the checker. As LLM-as-a-Judge becomes the default way to evaluate agent output at scale, Goodhart's Law arrives with it: when a measure becomes a target, it stops being a good measure.

An agent optimized against a judge learns to produce what the judge rewards rather than what's good. The literature calls this reward hacking, and the failure modes are documented: judges show self-preference bias, the same bias that argues for separating author from reviewer in the first place, along with position bias and verbosity bias. All three are gameable.

No single metric catches this, and anyone selling you a universal threshold is overselling. Teams that monitor for it watch the distribution of judge scores over time rather than the scores themselves, using measures like Jensen-Shannon divergence or population stability index against a rolling baseline, calibrated per system. What matters more than the measure is the escalation path: when the distribution moves, a human looks at it. Without that, "the judge said it was good" is a sentence that means nothing.

How OnStak builds agents that survive production

Deloitte projects the global agentic AI market could reach $35 billion by 2030, up from around $8.5 billion in 2026, and as high as $45 billion if enterprises orchestrate agents more effectively and manage the attendant risks. That conditional is the whole point. The value accrues to organizations treating orchestration as an architectural discipline rather than a prompt-engineering trick.

Before we discuss which model to use, we ask whether the system is built on a conversation or a contract, whether failures are traceable or laundered, and whether a decision can still be explained six months later to someone who wasn't in the room. If your team is scaling past single-agent pilots and seeing the fragile-mesh symptoms above, that's the signal for an orchestration-first redesign rather than another round of prompt tuning.

In regulated sectors there's a further layer architecture alone doesn't settle: what supervisors expect you to evidence about an agent's behavior, and who decides what "governed" means when the guidance explicitly doesn't. We've covered that separately for financial services.

If you're working out where your own agents sit on this spectrum, OnStak's AI & Agents practice helps enterprise teams move from chaos to structure without starting over.