A True Tool Result Can Still Be Wrong: ReplayBench Found a 64.9% Error Rate

Consider two order tasks running in the same agent system. Task A checks order 1837 and receives a genuine status result. That same result is later delivered to a separate cancellation task for order 2941. The content has not been forged or edited. The second agent treats it as evidence for its own task anyway and executes a cancellation for the wrong order.

The TRAP paper calls this tool-result misbinding. The problem is provenance and context: which task produced a result, which object it referred to, whether it is still fresh, and whether the action it supports has already happened. A result that was valid when it was produced can stop being valid when the task, the state, or the authorization changes.

That distinction matters for production systems. Agent runtimes routinely keep tool results in caches, checkpoints, durable event stores, and queues so work can resume after a failure. Those mechanisms are useful. They also create paths where an old result can re-enter a new execution. If the runtime delivers the bytes without checking the binding, the model is left to guess whether the evidence belongs to the job in front of it. ReplayBench measures how often that guess ends in a persistent wrong state.

What ReplayBench actually tests

ReplayBench covers 19 scenarios in areas such as email, calendars, file sharing, payments, identity and access management, cloud operations, and incident response. Each scenario runs in a sandbox with persistent state that the researchers can check after execution.

The benchmark varies three things at once.

First, the failure template. There are four: cross-task wrong-object replay, stale-context replay, duplicate-effect replay, and out-of-order replay. In plain terms, a result can belong to another task, belong to an earlier version of the world, trigger an action a second time, or arrive in an order that breaks the causal sequence.

Second, the replay mechanism. Results re-enter through durable recovery, queue redelivery, or cache resume. Those three paths map to ordinary engineering choices: store events so a job can recover, let a queue redeliver work, or restore a checkpoint when a session resumes.

Third, the stack. The cross-task test covers eight LLMs and three agent frameworks. The authors also track four stages: whether the wrong result was delivered, whether the model generated a wrong action, whether the runtime accepted that action, and whether the final external state was wrong. That last stage is the headline metric, Final-State Error Rate, or FSER.

Finding 1: Cross-task replay failed in almost two thirds of cases on average

Across the cross-task test, the mean FSER was 0.649. In 64 of 168 model, framework, and scenario configurations, or 38.1%, FSER reached 1.0. In those configurations every valid trial ended in an incorrect persistent state.

The full benchmark result was higher still. When the authors extended the evaluation beyond the cross-task template, the reported mean FSER was 0.989. Read that number carefully: the full-benchmark figure aggregates the wider set of failure templates and settings reported in the appendix, so it should not be compared with the 0.649 cross-task mean as if both were the same test. The useful point is consistent across both: once a real result is delivered in the wrong context, downstream checks in the tested stacks often fail to stop the resulting action.

Finding 2: Model choice moved the result far more than framework choice

Model-level mean FSER in the cross-task test ranged from 0.019 to 0.967. The authors attribute about 74% of the observed FSER variation to model identity.

Framework choice told a different story. Framework-level mean FSER stayed in a tight band, from 0.607 to 0.686, and the authors say framework identity explained less than 1% of the variation. All three frameworks remained susceptible.

For a practitioner, that ordering is actionable. Swapping frameworks is a weak defense against this class of failure. The model matters more in this test, and even the stronger end of the range still points to a runtime problem: delivery reached the target in almost all trials, and the divergence happened when the model decided whether to act on the result.

Finding 3: Passing the easy mismatch did not mean passing the harder ones

Some models rejected an explicit cross-object mismatch and still failed when the object stayed the same but another validity condition broke. The paper gives Qwen3.8-Max as the example: FSER of 0 on cross-task wrong-object replay across all three frameworks, then FSER of 1.0 on the stale, duplicate, and out-of-order templates in the follow-up test on cloud file sharing.

That result should change how teams write agent tests. A check that compares object IDs catches one template. It does not prove freshness. It does not prove an action has not already been committed. It does not prove a sequence is complete. The authors tested a simple object-ID binding defense separately and found the same limit: it blocked cross-task replay, then failed on same-object duplicate replay with FSER of 1.0.

Most of the stale, duplicate, and out-of-order settings in that follow-up reached FSER of 1.0. Object consistency alone did not establish validity.

Finding 4: Hints helped a little. Implicit changes helped almost not at all

The authors tested whether extra context in the result itself would let the model reject bad evidence.

Freshness fields such as result age, logical epoch, and state version made little difference for fresh and intermediate-age results, where FSER remained 1.0. For highly stale results, exposing the freshness fields reduced FSER to 0.60. Better, and still a failure in most cases.

Environment changes showed a similar pattern. When the underlying resource state changed without an explicit signal, WAR, AAR, and FSER stayed at 1.0 in the tested setting. When the system explicitly marked the previous authorization as revoked, those measures fell to 0.20.

The lesson is narrow and practical. Models can use explicit validity information, but they use it unreliably. A timestamp in a payload is a clue for the model, not a control. Controls belong in code that can reject an action before state changes.

Finding 5: Runtime validity checks stopped the tested failures without blocking recovery

The defense test compared three runtime mechanisms at the tool gateway: call-ID binding, one-shot tickets, and world-state epochs.

Call-ID binding ties a result to the invocation that produced it and rejects a result whose identifier does not match the pending request. A one-shot ticket gives a result a single-use authorization for a state-changing action. A world-state epoch ties a result to the state generation of the object it refers to and rejects actions based on stale state.

In the evaluated templates, all three defenses brought FSER to 0. They intervened at different points. Call-ID binding stopped the wrong result before it reached the target agent. The ticket and epoch checks allowed delivery, then rejected the invalid action before state changed.

In that defense test, all three reported a false-refusal rate of 0 and a recovery rate of 1.0, meaning legitimate recovery still succeeded in the tested cases. That is the strongest claim in the paper, and it comes with the narrowest test bed: the main defense comparison used one model and one framework, GPT-5.5 with LlamaIndex, on email operations and cloud file sharing. Treat the result as proof that binding can work in these settings, not as a guarantee for every gateway and workflow.

What this means for data and AI practitioners

If you build agents that change external state, add a replay test to your evaluation set and add binding checks to your runtime. A workable starting list:

1. Bind every result to its call. Store the invocation ID, task ID, and object ID with the result. Reject a result that does not match the pending request in the current execution.
2. Make state-changing results single-use. If a result has already supported a committed action, a second delivery should not support the same action again.
3. Version the world, not just the payload. Attach a state epoch or version to results that depend on permissions, balances, or resource state. Re-check that version at action time.
4. Treat freshness fields as evidence, not enforcement. Expose age and version to the model if they help reasoning, and enforce expiry in the gateway regardless of what the model decides.
5. Test all four templates. Cross-task, stale, duplicate, and out-of-order replay fail in different ways. A suite that tests only wrong-object delivery will miss the other three.
6. Measure the final state. A polite refusal in chat means little if a tool already changed a record. Score the sandbox or database state after execution, as ReplayBench does.

The broader point extends beyond one benchmark. Teams spend a lot of evaluation effort on whether tool content is malicious: injected instructions, poisoned documents, corrupted outputs. Misbinding is a quieter failure. The content is clean. The plumbing delivers it to the wrong place, and the agent does the damage itself.

Against and in favour

Against

Controlled replay may overstate real-world risk. The researchers deliberately deliver wrong results, often in every trial. A well-run production system may misdeliver rarely, may have idempotency keys and transaction checks that the sandbox frameworks do not enable by default, and may require human approval for the actions that matter most. The paper also names recent incidents, including a LangGraph.js report of cross-thread state contamination and an MCP TypeScript SDK vulnerability listed as CVE-2026-25536, but anecdotes and a benchmark do not add up to an incidence rate.

In favour

The failure survived changes that many teams would expect to help. It appeared across eight models and three frameworks, through three ordinary replay paths, and under stale and out-of-order conditions even when the object matched. Stage tracking located the break mainly at model-side action generation, which matches how real systems fail: the runtime delivers, the model trusts, the action layer accepts. The defense results, although narrow, show the failure is addressable with ordinary distributed-systems techniques rather than a new model generation.

What would make me wrong

Three results would weaken the case for urgent runtime binding.

First, a field study of production agent systems showing that misdelivery from caches, queues, and recovery is vanishingly rare, and that existing idempotency controls already block nearly every case that occurs.

Second, a replication where current models, given well-formed provenance metadata, reject misbound results reliably across all four templates, including duplicate and stale cases, without gateway enforcement.

Third, a broader defense evaluation showing that call-ID binding, one-shot tickets, or state epochs break legitimate recovery at a meaningful rate in real workflows. If the cure blocks valid work, teams will disable it, and the practical recommendation changes.

Until evidence like that appears, the safer reading is the one the data supports today: keep the recovery mechanisms, and check the binding before the action.

Have you tested what your agent does when a correct tool result arrives for the wrong task, twice, or after the underlying state has changed? If your suite has a replay case, what does it check: the reply text, or the final state?

Related on Everyday Data Science

• MCP, Explained for Data People: It Standardizes the Plumbing, Not the Thinking
• Passed Once Is Not Reliable: ThinkingBox Grades Agents on the Database, Not the Demo
• Your Agent Tests Pass. They Mostly Test the Plumbing.

Sources

• Zhi et al., TRAP: Tool-result Replay Attack for Probing Misbinding in LLM Agents, arXiv:2610.16333
• TRAP full text, HTML version on arXiv
• ReplayBench code repository