GO TO A SECTION

↑ ↓ to navigate · Enter to openExplore all sections →
FDEInterviews logo
arXiv preprint

τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment

An agent can know the fix and still fail to guide a user through it. τ²-Bench measures shared control, stateful user simulation and repeated task success.

Breakdown by FDE Interviews · 10 min read · Updated

About the original · 2025
AUTHORS
Barres, Dong, Ray, Si, Narasimhan
FROM
Sierra, University of Toronto, Vector Institute
PUBLISHED
Jun 2025 · arXiv preprint
IN THIS BREAKDOWN · 10 SECTIONS

You can read 17% of this breakdown.

01

The paper in one minute

τ²-Bench evaluates an agent helping a user who can also change the world. In its telecom environment, the agent has backend account tools while the user has phone tools. Fixing a connection may require both an account change and a device change, with neither participant directly observing everything the other can see.

This differs from a benchmark where the user only supplies information and the agent performs all operations. The assistant must explain an action, elicit the right observation and adapt when the result differs from its expectation. A correct plan can still fail through poor coordination.

The benchmark constructs tasks from smaller components with initialization steps, known solution actions and final assertions. A tool-grounded user simulator performs device actions against the same evolving environment. This reduces reliance on a language model simply claiming that an instruction worked.

For GPT-4.1, the reported telecom success rate is 34% in the normal interaction setting and 52% when the agent directly controls all tools. The comparison identifies a coordination burden in this environment. It is not a general estimate of how much human users reduce AI performance. The official repository provides the implementation needed to inspect and reproduce the task contract.

THE IDEA, VISUALLY
THE USER ALSO CHANGES THE WORLD An instruction is a message. The device changes only when the user performs the action. Agent controls the account Backend tools and account observations User controls the device Device tools and local observations Ask and explain Observe and report Account enabled: true Device enabled: true AND Verify terminal world state, then separately check policy and communication. Original illustration of sections 3.1–3.3. These two Boolean states are our teaching example.
Our dual-control illustration separates backend actions from device actions. A message requesting a change does not establish that the change occurred; the shared environment must supply evidence.
Research notes: the problem, approach and results
114

sampled telecom tasks, Table 1

34%

GPT-4.1 default telecom pass^1, Figure 4 left

52%

same model, no-user ablation, Figure 4 left

THE PROBLEM

A support agent must coordinate with a user who controls part of the environment and has different observations.

THE IDEA

Give both actors real simulated tools, construct tasks from verifiable components and compare normal interaction with diagnostic ablations.

THE RESULT

Telecom performance drops when the agent must guide the user instead of controlling every tool, and repeated-success scores expose additional fragility.

02

Why it matters to an FDE

Many enterprise workflows share control. A service desk assistant can reset an account but cannot physically reconnect a cable. A customer can change a device setting but cannot alter the backend subscription. Evaluating only the agent's own tool calls misses the handoff that determines whether the workflow finishes.

The useful design lesson is to model each actor's authority and observations explicitly. Do not let a user simulator report success merely because the assistant asked confidently. Tie observations to environment state, and make incomplete or mistaken actions visible to the agent through the same interface it would have in deployment.

For an agent gym, this also changes the test plan. Score the terminal state, inspect the trajectory and measure repeated success. A good answer in a transcript can coexist with an unresolved customer problem, an unauthorized action or instructions the user could not follow.

THE FULL BREAKDOWN

Understand the mechanism. Try it on a real problem.

Unlock this breakdown and 199 more papers.

Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.

6 months · One payment · No auto-renewal

Get Premium · ₹2,000 / $25
  • ◇1 architecture diagram
  • </>2 runnable code blocks
  • ▦3 results tables
  1. 03Key takeaways

    Six lessons for building an evaluation that includes the user's actions and observations

    Free account
  2. 04How it works

    Connect actor-specific tools, compositional tasks and diagnostic evaluation modes

    Premium
  3. 05The numbers that matter

    Read telecom results with their policy document, control mode and repeated-run definition

    Premium
  4. 06Try it yourself

    Enforce separate control and calculate all-success versus at-least-one success

    Premium
  5. 07Where it breaks

    Identify simulator bias, incomplete assertions and overinterpretation of diagnostic ablations

    Premium
  6. 08Using it on a deployment

    Build a shared-control test environment and keep outcome, policy and user burden separate

    Premium
  7. 09Interview angles

    Explain shared control, repeated reliability and the limits of a passing state assertion

    Premium
Back to the paper library →