Stop Decorating Invoices: Why Multi-Agent Systems Fail the Token Multiplier Test

4.7 times the tokens. That is what every coordinated arm paid in a controlled study of thirteen enterprise workflows, and the success gains were usually small and rarely significant.

The setup is what makes the number worth your attention. Same model. Same tasks. Same tools. Only the architecture changed.

Then came the twist. A redesigned multi-agent build hit 75.6% success against a 67.4% baseline, the only arm in the study to significantly beat the single agent. The architecture did not win that round. The implementation of it did.

If your team is about to add a second agent, read the ledger below first.

WHAT THE STUDY ACTUALLY DID

The paper is Agent Architecture Cost-Success Trade-offs: A Controlled Evaluation across Enterprise-Style SOPs, on arXiv as 2611.12953, submitted 7 November 2026 by Subhrangshu Nandi and thirteen co-authors. Read it before you argue with anything below, because the details are the argument.

Most agent benchmarks vary everything at once. They swap the model, swap the harness, swap the task set, and then publish a score. That measures confusion, not architecture.

This study held the model, the tasks, and the tools fixed and varied one thing: the shape of the workflow. It compared a function-calling single agent, a skill-augmented agent, centralized multi-agent orchestration, and a triage swarm, eight arms in total, across 13 enterprise SOPs.

An SOP here is a standard operating procedure, the long branching workflow a company actually runs: intake, checks, tool calls, handoffs, sign off. The kind of process with twelve steps and three places it can dead-end.

The authors also built a skill definition quality rubric and used it to assemble two matched corpora, one with high-quality skill definitions and one with deliberately degraded ones.

THE LEDGER: WHAT COORDINATION COSTS

Every coordinated arm, multi-agent or skill-augmented, spent 1.4 to 4.7 times the tokens and 2.6 to 5.8 times the latency of the single agent.

For gains that were usually small and rarely significant.

On any given SOP, success ranged from under 10% on the hardest to near 100% on the easiest. In aggregate, no architecture was statistically separable. Added structure only plausibly paid off on complex branching SOPs, and the authors call that a directional trend rather than a significant one.

This is the part that hits your bill and not your benchmark. Token accounting per request hides the whole problem now. Coordination means an orchestrator that talks to two workers that call tools that return to the orchestrator. Every hop re-sends context. Your dashboard shows a fleet of cheap calls. The invoice shows the multiplier.

THE ARCHITECTURE MULTIPLIER LEDGER

Name the thing so your design review can point at it. The Architecture Multiplier Ledger is four steps.

1. Instrument tokens and latency per SOP on your current single-agent before anything new lands.
2. Classify each SOP by branching depth and length, because those are the only shapes where a gain is even plausible.
3. Add coordination only where a measured gain clears the recorded multiplier.
4. Re-run the ledger after every skill corpus change, since definition quality moves success more than architecture does.

The ordering rule is the whole framework: record the multiplier before you add the structure. If the gain does not clear the multiplier, the structure is a donation to your inference bill.

An illustrative version of the measurement, not a result from the paper:

def ledger(sop, baseline, candidate):
    b = baseline(sop)                      # one run, single-agent
    c = candidate(sop)                     # same SOP, coordinated build
    token_mult = c.tokens / b.tokens
    latency_mult = c.latency / b.latency
    return {
        "sop": sop,
        "token_mult": round(token_mult, 2),
        "latency_mult": round(latency_mult, 2),
        "success_gain": c.success - b.success,
        "clears": c.success - b.success > token_mult,
    }

Run it per SOP, not per system. One average across thirteen workflows is how a bad arm hides.

WHY DEFINITION QUALITY BEAT ARCHITECTURE

High-quality skill definitions lifted success from 67.4% to 73.1%. Degraded definitions fell below the baseline.

Same model, same tools, same SOPs. The only variable was how well the skill was written. That is a bigger move than most teams get from their entire orchestration layer, and it costs a documentation pass instead of a second agent.

This is the same law measured a second time, and it lines up with the earlier note on tool descriptions costing 66% accuracy. The words you put in front of the model are the product. The topology around them is overhead.

The practical consequence is uncomfortable for people who think of prompt files as scratch work. A skill corpus is a testable asset. It belongs in version control, with a rubric, and it should be scored the same way you score code before a release.

THE REDESIGN RESULT

The sharpest finding is not that multi-agent lost. It is that a plausible multi-agent implementation lost to the single agent, and a targeted redesign of that same implementation became the only arm to significantly beat the baseline at 75.6%.

One build failed. The same build, fixed, won. Nothing about the category changed between those two rows.

So the variance inside one architecture is larger than the gap between architectures. Your team is arguing about a category while the outcome sits in the build. That is why the debate never resolves.

And the tooling is following the bill rather than the benefit. A Claude Code hooks module called Reinwatch, posted the same morning it was written, reports per-agent token counts, and can stop a single runaway agent inside a running workflow. People ship products for problems that already hurt.

WHAT TO DO TODAY

• [ ] Turn on per-agent token and latency accounting for every agent you run, in your own harness if you have nothing off the shelf.
• [ ] Baseline your single agent on your five most used SOPs before you add a second one.
• [ ] Audit your skill definitions for staleness and vagueness, because that is where the points are.
• [ ] Kill one coordinated arm you cannot justify with a measured gain. You already know which one.
• [ ] Put the multiplier ledger in your design document template this week.

THE UNCOMFORTABLE QUESTION

If your team's architecture debates never end in a measured token multiplier, are you engineering a system or decorating an invoice?

Same setup, different layer: in Programmatic Tool Calling: Why Your AI Harness Beats Your Model Choice, the same task, same model, and same tools run 36 requests and 3.1M tokens through one harness and 2 requests and 61K through the other.