One AI Agent Beat the Whole Team — Amazon's 13-Workflow Test Says Stop Building Agent Swarms

Every vendor demo this year shows the same thing: a swarm of AI agents, handing work to each other in a beautiful diagram, while a single lonely agent sits in the corner looking obsolete. If you build enterprise automation, the pressure to build the swarm is real — your boss saw the diagram too. A new study from Amazon researchers says the diagram is lying to you. They ran a controlled test across 13 real enterprise workflows, changed only the architecture, and found that the single agent is usually the smartest choice — and the swarm can cost you nearly five times the tokens for nothing.

The paper is "Agent Architecture Cost–Success Trade-offs: A Controlled Evaluation across Enterprise-Style SOPs" by Subhrangshu Nandi and 13 colleagues (arXiv:2611.12953, 7 November 2026). SOPs are standard operating procedures — the long, branching, tool-intensive playbooks companies use for routine work: look up a record, check a rule, fill a form, escalate the exception. The team held the model, the tasks and the tools fixed, and varied only the architecture. That is the part most agent benchmarks skip — and it is why this result is worth your attention.

What the researchers did

Four designs went into the test, in eight variants:

• A function-calling single agent — one model, able to call tools such as looking up a record or submitting a form.
• A skill-augmented agent — the same single agent, plus written "skills": reusable definitions of how to do a recurring sub-task well.
• Centralised multi-agent orchestration — a coordinator agent that plans the work and hands pieces to specialist agents.
• A triage swarm — agents that route work between themselves with no central boss.

All of them ran the same 13 enterprise SOPs, with the same model and the same tools. The researchers also built a skill-definition quality rubric, so they could test matched sets of high-quality and low-quality skills and see whether the writing of the skill mattered as much as the architecture around it.

Three takeaways emerged. First, there is no universal best architecture — the right choice depends on the SOP. On a given workflow, task success ranged from under 10% on the hardest to near 100% on the easiest, and no architecture was statistically separable in aggregate. Extra structure only plausibly paid off on complex, branching SOPs — a directional trend, not a proven one.

Second, extra architecture has a price, and it usually does not pay for itself. 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. The single agent, at a 67.4% task success rate, is the efficient default. High-quality skills did lift it, to 73.1% — but degraded skills dragged it below the baseline. A bad skill is worse than no skill.

Third — and this is the headline — implementation quality outweighs the single-versus-multi-agent choice. One plausible multi-agent implementation lost to the single agent outright. But a targeted redesign of that same multi-agent setup became the only arm to significantly beat the baseline, reaching 75.6% against 67.4%. Same idea, different execution, opposite result. The architecture on the slide was never the deciding factor; the engineering underneath it was.

Why it matters

If you are paying per token — and you are — a 4.7x token multiplier for no significant gain is not an architecture decision, it is a budget fire. At enterprise volume, the multi-agent version of a workflow that runs 10,000 times a month costs roughly what the single-agent version costs for 47,000 runs. The latency gap matters just as much: 2.6 to 5.8 times slower means a workflow that answered in 20 seconds now takes over a minute, and in a customer-facing or employee-facing process, that is the difference between "the AI handled it" and "I gave up and did it myself".

There is also an honest tension with the research we covered this afternoon, where ten teams of ten agents beat 100 solo agents by 27% — but that was on long-horizon tasks with a verifier that could score every attempt, like formal proofs and GPU kernels. Enterprise SOPs are a different world: branching checklists, tool calls, exceptions, human rules. The two papers agree on the deeper point, and so does Amazon's first takeaway: there is no universal winner. The right architecture depends on the task. Anyone selling you one architecture for everything is selling you a diagram, not evidence.

The practical lesson is narrower and more useful than "multi-agent is bad". It is: start simple, spend your effort on the quality of what the agent knows, and only add orchestration when a specific workflow proves it needs it — then measure whether the extra cost bought you anything.

How YOU can use it

Here is the decision flow the paper supports, as a checklist you can run on your next automation project:

Step 1 — Ship the single agent first. Give one function-calling agent the tools for your SOP and a clear instruction to follow it step by step. Measure its task success rate and its token cost per run. That number is your baseline — everything else has to beat it, not just look cleverer.

Step 2 — Write skills, not swarms. The cheapest win in the whole study was a high-quality skill. A skill is a short, written definition of how to do one recurring sub-task. The paper's rubric rewards clarity, so use this template for each skill you write:

SKILL: [name, e.g. "verify-vendor-invoice"]
WHEN TO USE: [the exact trigger — "when the SOP reaches an invoice
  with a vendor ID and an amount over $500"]
INPUTS: [what the agent must have before starting]
STEPS: [numbered, each step one tool call or one check]
DONE WHEN: [the exact success condition — "invoice matched to a PO
  and marked verified, or flagged with the mismatch reason"]
NEVER: [the failure modes to avoid — "never approve without a PO match"]

Write the skill, test it on five real cases, and keep it only if success goes up. The study warns you plainly: a sloppy skill hurts more than having no skill at all, so treat skills like code — reviewed, tested, versioned.

Step 3 — Only then, consider orchestration — for one workflow, as an experiment. Pick your most complex, branching SOP, the one where the single agent actually struggles. Build the multi-agent version, run both side by side on the same cases, and demand the numbers: does success rise enough to justify 1.4–4.7x the tokens and 2.6–5.8x the latency? If it does not, delete the swarm and keep the single agent. Most of the time, the study says, it will not.

Step 4 — Budget in tokens, not in agents. Before you approve any multi-agent design, ask for its cost per successful task: tokens per run divided by success rate. A design that succeeds 75% of the time at 4x the tokens is more expensive per success than a single agent succeeding 67% of the time. That one division is the whole paper, reduced to a calculator.

Key takeaways

• Amazon tested four agent architectures across 13 enterprise SOPs with the model, tasks and tools held fixed — only the architecture varied.
• No architecture won overall. Success ranged from under 10% to near 100% depending on the workflow, and extra structure only plausibly helped on complex, branching SOPs.
• Every coordinated design cost 1.4–4.7x the tokens and 2.6–5.8x the latency of a single agent, for gains that were usually small and rarely significant. The single agent (67.4% success) is the efficient default.
• High-quality skills lifted the single agent to 73.1%; degraded skills pushed it below the baseline. Skill quality is a lever you already own.
• Implementation beat architecture: a redesigned multi-agent setup reached 75.6% — the only significant win over baseline — while a plausible version of the same idea lost to the solo agent.
• Your move today: ship the single agent, write tested skills, add orchestration only as a measured experiment on one hard workflow, and judge every design by cost per successful task.

Read the original paper: "Agent Architecture Cost–Success Trade-offs: A Controlled Evaluation across Enterprise-Style SOPs" by Subhrangshu Nandi, Hitesh Arora, Yunfei Bai, Udita Patel, Chirag Shah, Hannah Kwon, Wei Zhang, Weian Chen, Chloe Ruoqi Li, Alberto Sconfienza, Ayush Goyal, Yasmine Lee, Ming Xiong, and Prathap Ramachandra. Link: https://arxiv.org/abs/2611.12953