agent-readings · tau-bench

<div class="slide-frame slide-frame--center">
  <p class="deck-kicker">agent-readings / Evaluation and Benchmarks</p>
  <h1>tau-bench</h1>
  <p class="deck-subtitle">Tool-agent-user reliability</p>

<div class="deck-meta-strip">
    <div class="deck-meta-pill"><strong>2024</strong><span>arXiv 2024</span></div>
    <div class="deck-meta-pill"><strong>7</strong><span>claims</span></div>
    <div class="deck-meta-pill"><strong>7</strong><span>evidence refs</span></div>
    <div class="deck-meta-pill"><strong>paper-read</strong><span>status</span></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">The one sentence</p>
  <h2>tau-bench evaluates whether tool-using agents can converse with simulated users, follow domain policies, update databases correctly, and do so consistently across repeated trials.</h2>
  <p class="deck-note">For production agents, pass@1 is not enough. tau-bench makes reliability visible by asking whether the same task succeeds repeatedly under stochastic user conversations.</p>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Before this paper</p>
  <h2>The friction was structural.</h2>
  <div class="apple-card-grid apple-card-grid--three">
    <div class="apple-card"><p>Many tool-use benchmarks provide all required user information in a single instruction.</p></div>
<div class="apple-card"><p>Function-calling benchmarks often evaluate individual tool calls rather than long-horizon dialogue plus database mutation.</p></div>
<div class="apple-card"><p>Agent benchmarks often omit domain-specific policies that constrain what actions are allowed.</p></div>
  </div>
  <div class="deck-callout">
    <span>Key gap</span>
    <p>The paper asks how to evaluate agents in realistic tool-agent-user interactions where user communication, API actions, and policy compliance all matter.</p>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Core idea</p>
  <h2>Build domains with realistic databases, APIs, policy documents, and user scenarios; run agents in conversations with LM-simulated users; then compare final...</h2>
  <p class="deck-note">Build domains with realistic databases, APIs, policy documents, and user scenarios; run agents in conversations with LM-simulated users; then compare final database state to annotated goal state across multiple trials.</p>
  <div class="idea-loop" aria-label="Agent loop">
    <div><strong>Model</strong><span>reason</span></div>
    <div><strong>Runtime</strong><span>act</span></div>
    <div><strong>World</strong><span>observe</span></div>
  </div>
  <div class="step-strip">
    <div class="step-item">
  <span>01</span>
  <p>Manually design domain schemas, APIs, and policy documents.</p>
</div>
<div class="step-item">
  <span>02</span>
  <p>Generate realistic database entries with LM assistance and manual verification.</p>
</div>
<div class="step-item">
  <span>03</span>
  <p>Create and verify user scenarios and target goal states.</p>
</div>
<div class="step-item">
  <span>04</span>
  <p>Run an agent with access to policy text and API tools.</p>
</div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Action grammar</p>
  <h2>The agent is an interface contract.</h2>
  <div class="apple-card-grid apple-card-grid--two">
    <div class="apple-card"><p>agent message: natural-language response to user.</p></div>
<div class="apple-card"><p>user message: simulated-user utterance based on hidden scenario.</p></div>
<div class="apple-card"><p>tool action: database API call such as get, update, cancel, book, or refund.</p></div>
<div class="apple-card"><p>policy document: domain-specific rules available as context.</p></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Executable shape</p>
  <h2>The mechanism should fit on one screen.</h2>

```python
for task in tau_bench:
    successes = []
    for trial in range(k):
        db = reset_database(task.initial_state)
        user = SimulatedUser(task.scenario)
        agent = Agent(policy=task.policy, tools=task.apis)
        transcript = run_conversation(agent, user, db)
        successes.append(compare(db.state, task.goal_state))
    pass_k[task] = all(successes)
```
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Evidence</p>
  <h2>The proof objects.</h2>
  <div class="proof-grid">
    <div class="proof-card">
  <span>E-benchmark-setup</span>
  <p>tau-bench emulates dynamic conversations between an LM-simulated user and an agent with domain-specific API tools and policy guidelines.</p>
</div>
<div class="proof-card">
  <span>E-db-state-eval</span>
  <p>The benchmark compares final database state after a conversation to annotated goal state, allowing stochastic conversation paths that should end in the same outcome.</p>
</div>
<div class="proof-card">
  <span>E-passk</span>
  <p>The paper proposes pass^k to evaluate reliability of agent behavior over multiple independent trials.</p>
</div>
<div class="proof-card">
  <span>E-domains</span>
  <p>The first benchmark includes tau-retail and tau-airline domains with realistic databases, APIs, policy documents, and user scenarios.</p>
</div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Claim map</p>
  <h2>What the review actually supports.</h2>
  <div class="claim-grid">
    <div class="claim-card">
  <span>C1 · paper-supported</span>
  <p>tau-bench evaluates dynamic conversations between an LM-simulated user and an agent with domain-specific API tools and policy guidelines.</p>
  <small>E-benchmark-setup</small>
</div>
<div class="claim-card">
  <span>C2 · paper-supported</span>
  <p>The evaluation compares the database state at the end of a conversation with an annotated goal state.</p>
  <small>E-db-state-eval</small>
</div>
<div class="claim-card">
  <span>C3 · paper-supported</span>
  <p>pass^k measures the consistency and robustness of agent behavior across k independent trials.</p>
  <small>E-passk</small>
</div>
<div class="claim-card">
  <span>C4 · paper-supported</span>
  <p>The first tau-bench domains are customer-service-style retail and airline tasks with databases, APIs, policies, and user scenarios.</p>
  <small>E-domains</small>
</div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Agent infrastructure</p>
  <h2>What changes if you build systems.</h2>
  <div class="apple-card-grid apple-card-grid--two">
    <div class="apple-card"><p>Production agent evaluation needs users, not just tools. Missing information must be gathered through conversation.</p></div>
<div class="apple-card"><p>Policy compliance should be tested against state changes, not only against plausible natural-language explanations.</p></div>
<div class="apple-card"><p>Final database state is the right verifier for many business agents because tool calls are side effects.</p></div>
<div class="apple-card"><p>pass^k is a better reliability signal than pass@1 when small stochastic differences can break a workflow.</p></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Caveats</p>
  <h2>What this does not prove.</h2>
  <div class="apple-card-grid apple-card-grid--two">
    <div class="apple-card"><p>The users are LM-simulated, not actual humans.</p></div>
<div class="apple-card"><p>The first benchmark covers retail and airline, not all real-world domains.</p></div>
<div class="apple-card"><p>Database-state matching can miss conversational quality unless quality is encoded in the task.</p></div>
<div class="apple-card"><p>pass^k can be expensive because it multiplies trials per task.</p></div>
  </div>
</div>

---

<div class="slide-frame">
  <p class="deck-kicker">Run it</p>
  <h2>No PoC yet.</h2>
  <p class="deck-note">No PoC yet - contributions welcome. A compact PoC could implement one retail database, two API tools, a simulated user, and pass^k over repeated conversations.</p>
  <div class="reference-list">
    <ul><li>Paper: <a href="https://arxiv.org/abs/2406.12045">tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains</a></li><li>Project/code: <a href="https://github.com/sierra-research/tau-bench">https://github.com/sierra-research/tau-bench</a></li><li>complements: <a href="https://arxiv.org/abs/2307.13854">WebArena</a></li><li>tool_use: <a href="https://arxiv.org/abs/2307.16789">ToolLLM</a></li><li>runtime_need: <a href="https://docs.dbos.dev/why-dbos">Durable Execution</a></li></ul>
  </div>
</div>

Note: This deck is synthesized from `data/reviews/tau-bench-yao-2024.json`. Update the review record, then run `bun run build`.