Amazon Study Finds One Agent Is the Efficient Default

If you are about to pay for a multi-agent architecture on an operational workflow, a controlled Amazon and University of Washington study says start with one agent instead. Across 13 enterprise-style standard operating procedures, every coordinated design (orchestrators, swarms, skill-augmented agents) used 1.4x to 4.7x the tokens and 2.6x to 5.8x the latency of a single function-calling agent, and only one of them beat it by a statistically significant margin. That one won because its builders fixed specific implementation failures, which is work you can do on a single agent first.

The paper, posted to arXiv on November 7, 2026, held the model (Claude Opus 4.8), the tools and the tasks fixed and changed only the architecture. Any gap between designs is therefore down to the design, which is the comparison you need before choosing one for your own workflow.

What Did the Amazon Study Actually Compare?

The study ran eight agent designs over 2,124 tasks each on SOP-Bench, Amazon's benchmark of procedures such as know-your-business (KYB) checks, patient intake, content flagging, dangerous-goods handling and customer service. An SOP, in this context, is a written business procedure with branching rules, required inputs and a defined output, the kind of thing a claims or trust-and-safety team runs thousands of times a week. SOP-Bench itself covers more than 2,000 tasks from expert-authored procedures across 12 business domains, with mock tools that return deterministic results.

The eight arms, per the paper:

Design	What it is	Task success	Tokens vs single agent	Latency vs single agent
Function-calling (FC)	One agent, full SOP, all tools	67.4%	1.0x (24.9k/task)	1.0x (24.0s)
Orch-v1	Decomposer, workers with SOP slices, synthesizer	58.2%	1.4x	2.6x
Swarm, no blueprint	Triage-guided handoffs	65.4%	2.1x	4.4x
Swarm, descriptive	Shared goal, unordered stages	70.4%	1.9x	4.2x
Swarm, full	Stage order plus routing logic	70.5%	2.7x	5.8x
Skills, low quality	One agent plus degraded skills	59.8%	2.4x	2.6x
Skills, high quality	One agent plus well-written skills	73.1%	3.0x	2.8x
Orch-v2	Redesigned orchestrator	75.6%	4.7x (117.3k/task)	3.1x

The authors' own conclusion is blunt: the single agent is the efficient default, and the procedure you pick explains more of the variance than the architecture you pick. Success on a given SOP and arm ran from under 10% to near 100%. By a per-SOP sign test, no arm separated from the baseline. The only significant result was Orch-v2 against the single agent, with an odds ratio of 1.72 (p = 0.007).

One caution on the source. The paper's conclusion section reports slightly different Orch-v2 figures (74.4% vs 65.6%) and refers to 12 SOPs rather than 13. The numbers above come from the results section, which is also what the trade coverage quoted.

---

What Does a Successful Task Cost on Each Design?

Measured per successful task rather than per attempt, the best multi-agent design costs about 4.2x the single agent's tokens. The arithmetic uses only the paper's figures. The single agent spends 24.9k tokens per task at 67.4% success, which is roughly 37k tokens per correct answer. Orch-v2 spends 117.3k at 75.6%, roughly 155k per correct answer. High-quality skills land in between at about 101k (3.0x the tokens at 73.1%), or 2.7x the baseline per success.

So the question for a buyer is concrete: is an 8.2-point lift in task success worth roughly four times the token bill and three times the wait? Sometimes it is. A KYB check that a human would otherwise redo costs far more than 92k extra tokens. A content-flagging decision that runs a million times a month may not be.

Latency is the cost teams forget to price. The baseline averaged 24.0 seconds per task. At 3.1x, Orch-v2 lands near 74 seconds; the full swarm, at 5.8x, near 139 seconds. If a customer or an agent-assist screen is waiting on the answer, that gap decides the design before tokens do.

This matches what the people who build these systems have said publicly. Anthropic reported in June 2025 that its multi-agent research system used about 15x the tokens of a chat, against about 4x for a single agent, and said domains where agents share context or have many dependencies "are not a good fit" today. The payoff there came on broad research, where it beat single-agent Opus 4 by 90.2% on an internal eval. Breadth-first research is the shape that rewards parallel workers. A step-by-step SOP mostly isn't.

Why Did the First Orchestrator Lose to One Agent?

The first orchestrator lost because each worker saw only its slice of the procedure and could not resolve missing inputs, so blocked workers emitted placeholder decisions. That is a design flaw, and the paper shows how much it cost: Orch-v1 scored 58.2%, nine points below a single agent with no coordination at all.

Orch-v2 kept the orchestrator shape and changed the contracts. Workers got the full SOP and the full tool set, placeholders were forbidden, a worker had to commit to a decision with its basis stated, the synthesizer could resolve gaps, and the system got one re-dispatch round plus output validation. The per-procedure recoveries were large, per the paper:

• Patient intake: 13.6% to 98.5%
• Email intent: 75.8% to 96.2%
• KYB: 23.3% to 60.0%

Read those numbers as a warning about your own pilots. A plausible architecture, built by a team that included the benchmark's authors, underperformed a single agent until someone traced the failures. Cognition made the same argument from the coding side in June 2025: share full agent traces, not just messages, because "actions carry implicit decisions, and conflicting decisions carry bad results." Orch-v1 is that failure measured on business workflows.

Google Research found the pattern at larger scale. Across 180 agent configurations, every multi-agent variant degraded sequential tasks by 39% to 70%, while centralized coordination improved a parallelizable finance task by 80.9%. Independent agents amplified errors up to 17.2x; a central coordinator held that to 4.4x. The underlying paper also built a model that picks the right architecture for 87% of unseen configurations, which tells you the choice depends on task shape and can be predicted.

---

Do Agent Skills Help, or Do They Hurt?

Well-written skills helped and badly written ones hurt: high-quality skills raised success to 73.1%, while degraded skills dropped it to 59.8%, below the single agent with no skills. A skill, in the Agent Skills sense, is a packaged instruction set with a name, a description, steps and the tools it may call, loaded by the agent when a task matches.

The failure modes are specific enough to check for in your own skill library. On one referral-abuse SOP, the low-quality skills filed decisions under an invented key (enforcement_action instead of final_decision) in 194 of 200 traces. The output was arguably right and still unusable downstream, because the skill had lost its output contract.

The paper's rubric for skill quality scores a definition out of 50:

1. Identity and discoverability, 10 points: name, description, usage scenarios.
2. Instruction quality, 15 points: ordered, specific steps mapped to tools, with termination conditions and constraints.
3. Contract clarity, 10 points: preconditions, typed input and output schemas, tool dependencies.
4. Disambiguation, 10 points: anti-patterns, explicit negative scope, boundaries.
5. Governance metadata, 5 points: domain, complexity, risk, tags.

The authors used the rubric as a manipulation check (good corpora averaged 99.8%, degraded ones 67.6%) and say plainly that they did not show rubric score predicts task success. Treat it as a review checklist, then.

Tool scoping is the other trap. Restricting each skill to its declared tools helped on KYB, which has 8 tools, and hurt on video annotation, which has 26. With open tool access, video annotation reached 57.6% against 37.6% for the scoped version. Whether least-privilege tool scoping costs you accuracy depends on the workflow, so test it per SOP.

Where the Study Is Weak

The study's limits are real and the authors list them: one benchmark, synthetic tools with no real latency or errors, one model, one implementation per architecture and one run per task. Production tools fail, time out and return inconsistent data, and a multi-agent design with a validator might recover from that better than a single agent. This paper cannot tell you.

The authors also flag that two evaluation bugs (a multi-field output parser and a trace-denominator error) would have changed their conclusions if left uncorrected, and they mark the orchestration arms' multi-field scores as provisional because the parser fix was not verified for those cells. That's a useful admission. If a benchmark team can mis-score its own runs, your internal bake-off needs the same audit, and a sample large enough to separate real gaps from noise. We covered how to size an agent eval set in September.

The strongest case for multi-agent comes from Meta's thin orchestrator, where 14 subagents brought data-column onboarding under an hour after a single agent failed. Both results can hold. Meta's job had a single agent hitting a wall it could measure. The Amazon result says most SOPs don't hit that wall, and you should find out which kind you have before buying the architecture.

---

What to Do Before You Commit to an Agent Architecture

Build the single-agent baseline first, measure it per workflow, and only then price the alternatives. That is the paper's recommendation and it echoes Anthropic's December 2024 guidance to find the simplest solution possible and add complexity only when needed.

This Week:

1. Pick the one SOP you plan to automate first and write down its success definition: the output field, its allowed values and who checks it.
2. Run a single function-calling agent with the full SOP and all its tools on at least a few hundred historical cases. Record success rate, tokens per task and seconds per task.
3. Divide tokens by success rate to get tokens per correct answer. That number, not the token price, is the baseline every alternative has to beat.

This Month:

1. Score each skill your team or vendor ships against the five-part rubric above. Fix missing output schemas and negative scope first; those caused the worst failures in the study.
2. Read 50 failed traces before changing architecture. Look for placeholders, invented output keys, over-escalation and early-exit gates that never fire. Each is fixable inside a single agent.
3. If you still want orchestration, build it with full context for workers, no placeholder outputs, a commit-with-basis contract and one validation pass, as in Orch-v2. Run it on the same cases and compare tokens per correct answer and latency.

Before Renewal or Platform Commitment:

1. Ask any vendor selling multi-agent orchestration (LangGraph, CrewAI, or a hyperscaler's agent platform) for a same-model, same-tools comparison against a single agent on your workflow. A demo against a different baseline proves nothing about your bill.
2. Set a written threshold: adopt the coordinated design only when its success gain on your SOP is statistically clear and worth the measured multiple in tokens and latency. For high-stakes procedures, the paper's authors also recommend human review and calibrated abstention over full autonomy.

The Bottom Line

Vendors are selling orchestration as the next step for every agent program. On step-by-step business procedures, this study held the model and tools constant and found that one agent is the cheaper default and that build quality decided the only significant win. The microservices wave followed a similar arc: teams split monoliths before they had the problems that justified the split, then paid for the network calls. Measure your single-agent baseline on your own SOP before you buy the orchestrator.

Continue Reading

• Meta Cuts Data-Column Prep to Under an Hour With 14 Subagents
• Only 3 of 36 Model Gaps Were Real. Size Your Eval Set.
• Your Bake-Off Ranked Harnesses, Not Models. Re-Run It.
• UNICEF Tested a Generic MCP Server. It Lost to No Tools.
• Your AI Shopping Agent May Buy After It Fails, Visa Finds
• Codex and GitHub Copilot Read Anthropic's Agent Skills