One Agent Beats a Team: In Customer Conversations, a Multi-Agent Setup Loses to a Single Agent

This is a finding, not a technique. The comparison setup:

SINGLE AGENT:  policy verbatim in the prompt → talks to the customer itself → calls tools itself

MULTI-AGENT:   Orchestrator (talks to the customer, keeps the plan)
                 ├→ DB agent (the only one that calls tools)
                 └→ Policy advisor (gives a verdict with quotes from the policy)

Conditions: one model, one shared token budget per conversation
Outcome:    the single agent wins almost everywhere

Where the finding hits hardest: a support agent that talks to the customer and changes something in the system (plan, order, booking). Here the "don't split into roles" lesson applies directly.

The task: You're setting up a support agent for a regional internet provider (think a smaller cousin of Comcast or Spectrum). The agent needs to change plans, enable a "payment extension," and reset a port. The temptation: build an "orchestrator," an "executor," and a "policy lawyer." Instead, we build a single agent.

Prompt (system instructions for the single agent):

You are a support agent for the internet provider "NorthNet." You talk to the customer and call the tools yourself.

Below is the policy. Follow it strictly. If the customer asks for something the policy forbids, refuse and explain why.

<policy>
1. A plan can be changed only after verifying that the customer has no outstanding balance.
2. A "payment extension" is available once every 30 days, for no more than 3 days.
3. A port reset is allowed only after the customer has confirmed they rebooted their router.
4. Any change to the account happens only after an explicit "yes" from the customer.
</policy>

Working rules:
- First read the customer's data, then act.
- Perform actions that modify data only after the customer confirms.
- Call each tool with exactly the parameters the customer confirmed.
- If the customer needs to do something themselves (reboot the router), ask for it and wait for their reply.

Result: The agent runs the conversation in a single context. It reads the customer's data, checks the policy, asks for confirmation, and only then calls a write tool. There are no hand-offs between roles, so no details get lost in hand-offs. Token usage will be lower than with a team. The agent decides "payment extension or plan change" on its own, without the orchestrator relaying it secondhand.

The team's weak spot. Every hand-off between roles is a retelling. The orchestrator phrases an order in words, and the executor turns it into a tool call. If the orchestrator doesn't know the tool schema (which parameters, which formats), it writes the order "roughly." The executor carries it out differently than intended. In the study this happened to most write commands. On top of that, every role burns tokens on planning and coordination. Under a shared budget, that eats the room needed for the actual conversation.

The single agent's strength. It keeps all the context in one place: the customer's words, the policy, the tool results. It doesn't have to retell anything. Modern models handle this kind of conversation well on their own. In the study the single agent was the baseline configuration, and with zero tuning it came out stronger.

What this means for you. Splitting into roles isn't free. You pay in tokens, latency, and hand-off losses. Your levers: - Tool access. If you do split into roles, the executor must receive a complete order with exact parameters, and the orchestrator must know the tool schemas. - The "advisor" role. Instead of a separate agent, paste the policy verbatim into the main prompt. - Testing on your own data. Before rolling out, run 30–50 real conversations through both versions.

This is the baseline configuration from the study: one agent, the policy pasted verbatim, tools called directly.

You are the {agent_role} agent for {company}. You talk to the customer and call the tools yourself.

Follow the policy strictly. If the customer asks for something the policy forbids, refuse and explain the reason.

<policy>
{policy_verbatim}
</policy>

Rules:
- First read the data, then act.
- Make changes only after the customer's explicit confirmation.
- Call each tool with the parameters the customer confirmed.
- {customer_action_rules}

What to fill in: - {policy_verbatim} — the full text of the policy, no paraphrasing or trimming. - {customer_action_rules} — what the customer has to do themselves (in telecom: rebooting, checking indicator lights).

⚠️ A defect in the team itself: In the experiment, the orchestrator planned without seeing the tool schemas. The authors openly call this a deviation from their own plan. They built a fixed version but didn't run it across the full grid. So the conclusion applies to this particular architecture, not to every multi-agent design.

⚠️ Only one kind of team: Only a centralized setup with a single orchestrator was tested. Agent debates, independent agents, and hybrids weren't tested, because in a customer conversation they need separate adaptation.

⚠️ Simulator dependence: The customer was played by another model. When it was swapped for the default simulator, the team suddenly gained in one cell. The result depends heavily on which "customer" is used in the test.

⚠️ No answer on model strength: The study couldn't establish whether the benefit of a team shrinks as model capability grows. The confidence interval is too wide. They didn't confirm the "threshold around 45%" rule itself, but they didn't definitively refute it either.

⚠️ Only user-facing conversations: For autonomous tasks with no human in the loop (software development, analytics), the conclusion doesn't necessarily carry over.

The idea was simple: take the popular rule "a team of agents helps weak models and hurts strong ones, with a threshold around 45% accuracy" and test it where agents actually work — in conversation with a customer. They used the τ²-bench benchmark with three domains: airline, retail, and telecom. In telecom, the customer takes actions on their own device.

Six models from three families, roughly 7,950 simulated conversations, 50 tasks per cell, and three runs each. The study was preregistered and kept a public changelog. That guards against tweaking things until the result looks right.

The hard part is a fair comparison. In a conversation, the bulk of tokens go to reading context (in the pilot, every generated token came with 57 read tokens). So they compared by generated tokens, with one shared "meter" for the whole conversation. The budget was calibrated to the single agent's actual usage. The team got four times that headroom.

The result: the team didn't win a single cell. The average loss was about 28 points. In the two cells where the rule predicted a benefit, the team lost by 13 and 22 points. When the budget was removed entirely, at best it tied the single agent while spending 5.5 times more tokens. The surprise: the team did not reduce the number of erroneous database writes, which is usually the whole reason to build one. Some failures turned into "ran out of budget" or doing nothing.

🔧 Technique: if you do split into roles → give the executor a complete order

A lesson from the experiment's defect: the orchestrator couldn't see the tool schemas, and write commands got distorted. In the orchestrator's role description you can explicitly demand precision:

Copy

When you pass the executor a command that changes data, specify:
- the exact tool name,
- all parameters with concrete values,
- where each value came from (the customer's words or a read result).
Do not paraphrase in your own words.

This is my extrapolation; the study didn't test this prompt. But it follows directly from the failure cause they found.

🔧 Technique: policy advisor → policy block in the main prompt

Instead of a separate advisor agent, paste the policy verbatim into the system prompt and add a rule: "Before changing data, quote the policy clause that allows it." That way the check stays inside one context, with no hand-off.

Extrapolation: run your own mini-test before adding complexity. Take 30–50 real support requests. Run them through a single agent and through a team. Compare not on "how nice the answer sounds," but on whether the system state changed correctly (order, status, amount). That's what the authors measured.

• Paper: Does Multi-Agent Collaboration Pay When Agents Serve Users? Testing Agent Scaling in Dual-Control Settings.
• Authors: Ethan Yang, Xiangcheng Shi, University of Pennsylvania.
• Code, prompts, and experiment plan: https://github.com/ethanyyang/agent-scaling-dual-control
• Trajectories and budget logs: https://doi.org/10.5281/zenodo.23458286
• The rule under test: Kim et al. (2026), "capability-saturation principle," threshold around 45%.
• Benchmark: τ²-bench (Barres et al., 2025).
• Related work: Tran & Kiela (2026), Jwalapuram et al. (2026), Cuadron et al. (2025), Kang et al. (2026).