Tau2

Evaluating Conversational Agents in a Dual-Control Environment

Overview

This is an inspect-native implementation of the Tau2 benchmark, Tau2 original code.

Warning

This benchmark uses a high amount of tokens. For example, airline on gpt5-nano might use 60,539,475 tokens [I: 57,885,918, CW: 0, CR: 49,725,440, O: 2,653,557, R: 2,254,976] For testing purposes, use a –limit 5 flag to limit the number of samples on which the eval is run, as well as -T message_limit=10 flag to limit the number of messages per sample.

Usage

Installation

There are two ways of using Inspect Evals, from pypi as a dependency of your own project and as a standalone checked out GitHub repository.

If you are using it from pypi, install the package and its dependencies via:

pip install inspect-evals

If you are using Inspect Evals in its repository, start by installing the necessary dependencies with:

uv sync

Running evaluations

Now you can start evaluating models. For simplicity’s sake, this section assumes you are using Inspect Evals from the standalone repo. If that’s not the case and you are not using uv to manage dependencies in your own project, you can use the same commands with uv run dropped.

uv run inspect eval inspect_evals/tau2_airline --model openai/gpt-5-nano
uv run inspect eval inspect_evals/tau2_banking --model openai/gpt-5-nano
uv run inspect eval inspect_evals/tau2_retail --model openai/gpt-5-nano
uv run inspect eval inspect_evals/tau2_telecom --model openai/gpt-5-nano

To run multiple tasks simultaneously use inspect eval-set:

uv run inspect eval-set inspect_evals/tau2_airline inspect_evals/tau2_banking inspect_evals/tau2_retail inspect_evals/tau2_telecom

You can also import tasks as normal Python objects and run them from python:

from inspect_ai import eval, eval_set
from inspect_evals.tau2 import tau2_airline, tau2_banking, tau2_retail, tau2_telecom
eval(tau2_airline)
eval_set([tau2_airline, tau2_banking, tau2_retail, tau2_telecom], log_dir='logs-run-42')

After running evaluations, you can view their logs using the inspect view command:

uv run inspect view

For VS Code, you can also download Inspect AI extension for viewing logs.

If you don’t want to specify the --model each time you run an evaluation, create a .env configuration file in your working directory that defines the INSPECT_EVAL_MODEL environment variable along with your API key. For example:

INSPECT_EVAL_MODEL=anthropic/claude-opus-4-1-20250805
ANTHROPIC_API_KEY=<anthropic-api-key>

Options

You can control a variety of options from the command line. For example:

uv run inspect eval inspect_evals/tau2_airline --limit 10
uv run inspect eval inspect_evals/tau2_banking --max-connections 10
uv run inspect eval inspect_evals/tau2_retail --temperature 0.5

See uv run inspect eval --help for all available options.

Parameters

tau2_airline

• shuffle (bool): (default: True)
• message_limit (int | None): (default: None)
• tasks_file_override (str | None): (default: None)

tau2_banking

• shuffle (bool): Whether to shuffle the dataset. (default: True)
• message_limit (int | None): Max messages per sample (None for no limit). (default: None)
• retrieval_config (str): How the agent accesses the knowledge base. One of “grep” (default; offline KB search tool), “full_kb” (entire KB inlined, ~215K tokens — needs a large-context, high-TPM model), or “no_knowledge” (no KB access; ablation baseline). (default: 'grep')
• tasks_file_override (str | None): Optional path to an alternative tasks file. (default: None)

tau2_retail

• shuffle (bool): (default: True)
• message_limit (int | None): (default: None)
• tasks_file_override (str | None): (default: None)

tau2_telecom

• shuffle (bool): (default: True)
• message_limit (int | None): (default: None)
• tasks_file_override (str | None): (default: None)

Dataset

The dataset for Tau2 is taken directly from the Tau2 benchmark repository. It is described in detail in the Tau2 paper and the Tau paper. There are 4 separate domains, each with their own dataset:

• airline
• banking
• retail
• telecom

Telecom stands out as it has a significantly larger dataset and it allows for the user-simulator to interact with the environment via tool calls.

Banking (the banking_knowledge domain, taken from this later revision of the benchmark) is a knowledge-heavy domain. Rather than a single flat policy file, its policy is a knowledge base of documents that the agent must consult, and many of its tools are discoverable: the agent has to find a tool in the knowledge base and unlock it (or hand it to the user) before it can be called. As in telecom, the user-simulator can interact with the environment via tool calls.

Banking retrieval configuration

Unlike airline/retail/telecom — which each have a single flat policy.txt and therefore expose no policy configuration — banking_knowledge ships with multiple knowledge-access strategies upstream (tau2-bench’s --retrieval-config). tau2_banking mirrors this with a retrieval_config task parameter:

retrieval_config	Knowledge access	Notes
grep (default)	A grep search tool over the knowledge base (upstream grep_only)	Offline, small prompts; runs on any model/tier
full_kb	The entire knowledge base (~215K tokens) inlined into the system prompt (upstream full_kb)	Needs a large-context model and a high tokens-per-minute limit; impractical on small tiers
no_knowledge	None (upstream no_knowledge)	Ablation baseline

uv run inspect eval inspect_evals/tau2_banking -T retrieval_config=full_kb --model openai/gpt-4.1

grep is the default because it is faithful to a real upstream config while remaining runnable everywhere; the upstream default (alltools) and the embedding/sandbox configs (bm25, openai_embeddings, terminal_use, …) are intentionally not ported as they require external embedding services or a sandbox runtime not available in this offline harness. Because the implemented configs differ from the upstream leaderboard’s alltools setup, banking results here are not directly comparable to taubench.com.

Known differences from the banking original implementation

• The interest_discrepancy_reports table is declared. Upstream’s TransactionalDB does not declare this table, so calls to submit_interest_discrepancy_report_7294 silently fail to persist data in the original code. This implementation adds the table, making the write succeed. Because both the expected and actual databases are built by the same code, scoring is unaffected.
• query_database is not ported from KnowledgeUserTools. The original implementation’s query_database doesn’t have an @is_tool or @is_discoverable_tool decorator, so the AI agent’sget_tools() and use_tool() cannot reach it. It is dead code upstream and is intentionally omitted here.
• The retrieval-config difference, documented above.

Scoring

Again discussed in etail in the Tau2 paper and the Tau paper. Each domain has its own scoring function,

• airline: For each task an agent may have to perform certain tool calls, and relay certain information to the user. Then, the task also has to complete one or more goals described by natural language. A grading model is used to assess whether the goals have been met. The task is considered successful if all tool calls are made correctly and all goals are met.
• retail: For each task an agent may have to perform certain tool calls, and relay certain information to the user.
• telecom: For each task an agent may have to perform certain tool calls, and relay certain information to the user. Then, the end environment state is compared to the desired end state. The task is considered successful if all tool calls are made correctly and the end state matches the desired end state.
• banking: Most tasks are scored by comparing the end environment state (the database) to the expected state produced by replaying the task’s required actions; the remainder are scored by checking that the required actions were performed. The task is considered successful when the database matches the expected end state (for DB-scored tasks) and any required actions were taken.

Evaluation Results

pass^1 rate Agent Model: GPT-5 - User model: gpt-4.1-2025-04-14

Domain	Inspect Evals Accuracy[1]	Inspect Evals Stderr	Tau2 Leaderboard[2]
Retail	0.825	0.036	0.816
Airline	0.580	0.071	0.625
Telecom	0.939	0.023	0.958

[1] Inspect Evals accuracy is calculated across 1 try for each task and message_limit is infinity. [2] The leaderboard accuracy is calculated across 4 tries for each task (equivalent to --epochs 4 in Inspect) and message_limit is 100.

Changelog

[3-A] - 2026-06-17

• Added a test to check the Tau2 Banking tools against the upstream version to ensure they have the same functionality and docstrings.
• Updated the banking tools accordingly.
• Other domains remain unchanged.

[2-A] - 2026-02-16

• Migrate version to new scheme. See #907.