False failures on τ³-bench: when the cancel worked and the agent said it didn’t

We ran fault-injected integrity tests on Sierra τ³-bench retail and airline write tools. Under timeout-after-send, a naive Gemini agent often told the user the cancel failed — after the write had already landed in the system of record. Receipts both told the truth and finished the job.

The bug, in one picture

Same call. Same dropped response. Two ways an agent can handle it — this is the real retail_cancel trace from the run below.

Without Afterstate Naive retry

Cancel order cancel_pending_order()
Response lost timeout — outcome unknown
Retries blind same call, no check first
Rejected order already cancelled

Agent tells the customer: “I couldn’t cancel it.” The cancel landed on the first try. This is a false_failure — nothing duplicated, but the agent lied by mistake.

With Afterstate Claim → observe → receipt

Cancel order cancel_pending_order()
Response lost timeout — outcome unknown
Observes the order DB evidence, not a guess
Receipt: applied next_step = continue, don’t retry

Agent tells the customer: “Your order is cancelled.” True the first time — verified_success. One write, one correct answer.

Headline

Three arms, same tools, same fault. Safe means no integrity failure (duplicate write, false failure, hallucinated success). Completion means verified_success — the write happened once and the agent reported it correctly.

Arm	Safe	Completion	Dominant outcome
naive blind retry	33% 5 / 15	0% 0 / 15	`false_failure` ×10
observe_first prompt: check before retry	93% 14 / 15	0% 0 / 15	`escalated` ×13
afterstate claim → observe → receipt	100% 15 / 15	100% 15 / 15	`verified_success` ×15

Completion rate (verified success)

naive

observe_first

afterstate

100%

What happened

Typical retail cancel under timeout-after-send — the mutation lands; the agent never sees the success response.

Gemini calls cancel_pending_order → τ DB status becomes cancelled → timeout returned to the agent.
Naive arm retries blind → τ rejects: Non-pending order cannot be cancelled.
Gemini tells the user it could not cancel.
Our grade (SoR vs claim): false_failure

Transcript-only evals and LLM-as-judge often miss this. The conversation looks like a failed tool call. The database disagrees.

What Afterstate did

Same fault → observer finds status=cancelled → receipt applied with next step do not call again → Gemini reports success → verified_success.

Observe-first (prompt only) usually stayed safe by refusing to finish — mostly escalated. Safe, but not complete.

By scenario

Scenario	naive safe	observe_first	afterstate
`retail_cancel`	0 / 5	5 / 5 (escalate)	5 / 5 verified
`retail_return`	0 / 5	4 / 5	5 / 5 verified
`airline_cancel`	5 / 5*	5 / 5 (escalate)	5 / 5 verified

*Airline naive often escalated rather than false-failed — still 0% verified completion.

Scale study — 2,016 τ³ traces

Same world, no in-house lab scenarios. Gemini 2.5 Flash + Claude Opus × 4 write scenarios × 3 faults × 28 trials. 2,016 graded runs, 0 infra failures.

Arm	Safe	Completion
naive	71% 475 / 672	54% 363 / 672
observe_first	92% 616 / 672	50% 337 / 672
afterstate	100% 672 / 672	100% 672 / 672

Timeout-only slice (224/arm): naive 25% safe / 12% complete · afterstate 100% / 100%.
Naive failure mix: false_failure ×113, duplicate_write ×84, escalate ×111.
Afterstate perfect on both Gemini and Opus (336/336 each).

Earlier extended matrix

Gemini-only precursor (180 runs) before the 2,016-trace scale study: +airline_book and faults network_down + double_ask.

Arm	Safe	Completion
naive	75% 45 / 60	42% 25 / 60
observe_first	92% 55 / 60	8% 5 / 60
afterstate	100% 60 / 60	98% 59 / 60

Timeout slice alone: naive 0% complete · afterstate 100%.
airline_book: naive and observe_first still produce duplicate_write; afterstate stays single-write.
One afterstate non-completion was a safe honest_failure (network down; agent did not retry after not_applied).

How to read this

This is

Fault-injected integrity grading on τ³ write tools
Evidence that unknown outcomes produce false failures
A comparison of blind retry vs prompt care vs receipts

This is not

“SOTA on τ-bench”
A claim about overall task success rates
An endorsement by Sierra Research

Methods

Tools and databases from sierra-research/tau2-bench (τ³).
Arms: naive, observe_first, afterstate.
Baseline fault: mutation commits in τ DB; agent receives TimeoutError.
Verdicts from claim vs SoR diff — never from the transcript alone.
Baseline run id: world_bench_gemini_t5b. Multi-fault precursor: world_bench_gemini_deep. Scale study: world_bench_tau_n2016 (2,016 traces).

$env:PYTHONPATH = "…\tau2-bench\src;…\tau2-bench"
cd afterstate-core
python -m benchmark.world_runner --models gemini opus --trials 28 `
  --scenarios retail_cancel retail_return airline_cancel airline_book `
  --faults timeout_after_send network_down double_ask `
  --out results/world_bench_tau_n2016

If your agents write to a system of record

False failures and silent duplicates are the same family of bug: unknown outcomes without reconciliation. We are building the receipt layer with design partners.

Request early access See the demo