Cleaning Agent History Can Backfire When the World Still Contains the Error

Summary:This study separates an agent's conversational history from the state of the external world and shows that sanitizing history does not necessarily improve recovery. On AgentCE-Bench, adding a truthful note beside a preserved error raised the share of correctly completed remaining targets from 51% to 66%, whereas merely recording a completed action reduced it from 50% to 44%. On AppWorld, the effect of a success receipt depended on whether the corresponding database effect actually existed: witho

---

Core Finding

This study examines a common recovery strategy for tool-using language-model agents: compressing, repairing, or rewriting a flawed interaction history so that the next agent receives a cleaner trajectory. The results show that this approach works reliably only when the history agrees with the actual state of the external world. If the record claims that an error has been resolved while the underlying database, file, or environment still contains the faulty effect, the agent may perform worse than if it had received the original error.

Rather than replacing history wholesale, the experiments freeze an agent at the exact midpoint of a task and then edit either its history or the world state. This separates two variables that are often conflated:

• History state: what the model sees, including errors, corrective notes, and tool receipts;
• World state: what actually happened, including whether a write landed and whether an incorrect value remains.

AgentCE-Bench: A Note Beats a False Completion Claim

In AgentCE-Bench, an agent first commits an incorrect value. The researchers hold the world fixed and introduce the correct value in two natural ways: by preserving the error and adding a truthful note beside it, or by recording that the agent's own action has completed.

The two edits produce opposite results:

• The truthful note raises the share of remaining targets completed correctly from 51% under a matched neutral note to 66%;
• Merely adding a completed-action record lowers performance from 50% with the unedited history to 44%.

The important variable is not whether the correct value appears in the text, but how the text asserts the underlying fact. A note tells the receiver that the error still exists and must be corrected. A completed-action record instead encourages the receiver to treat an unwritten change as a fact, potentially skipping the compensating action. That can be worse than preserving the original error.

In other words, an error in the history is not necessarily harmful. Mislabeling the error as resolved can be harmful.

AppWorld: A Success Receipt Must Match a Real Side Effect

The AppWorld experiment studies tool receipts after database writes. The researchers independently vary whether a receipt reports success or failure and whether the corresponding database effect is actually present.

When the effect is absent, a success receipt lowers whole-task success from 45% to 28%. When the effect is present, the same success receipt raises success from 38% to 49%. Pooled across the two conditions, the difference is 27 percentage points. The direction is positive for six of eight receiver models at the 97.5% level and seven at the 95% level.

The value of a receipt is therefore conditional rather than constant:

Recovery benefit ≈ evidence reliability × state consistency − skipping cost from a false completion claim

This is a conceptual summary of the observed mechanism rather than a formula supplied by the paper. A reliable receipt backed by a real effect reduces redundant work and frees context. A receipt that contradicts the world creates a false closure: the agent neither retries the operation nor selects an alternative path.

Why the Experimental Design Matters

The study's main technical contribution is a controlled history–world intervention protocol. Conventional agent benchmarks often change prompts, tool outputs, and environment state together, making it difficult to attribute performance changes to language context or actual execution. Freezing the world while editing history, or holding history fixed while changing the world, exposes the marginal effect of each source of truth.

The findings still have boundaries. AgentCE-Bench and AppWorld cover controlled error repair and database writes rather than every kind of external side effect. In production systems, services may return ambiguous receipts, and asynchronous jobs can move from apparent failure to eventual completion. The paper also does not show that every receiver model can reliably distinguish these states.

The 27-point pooled difference is based on two receiver models and eight receiver instances. It supports the overall direction, but it does not establish the same effect across every architecture, language, tool-use policy, or long-horizon workload. Teams should reproduce the protocol with their own model and tool stack rather than treating the reported gain as a universal constant.

Engineering Trade-offs

The simplest response is to add more warnings, verification results, and status annotations to the history. This increases context length and token cost. Longer histories can also make the valid current state harder to locate, while irrelevant details dilute critical recovery instructions. A larger context window is not a substitute for explicit state management.

A more robust design treats history as a potentially stale cache, not an authoritative database. Before handing work to another agent, the system should:

1. Extract completion claims, tool receipts, and pending actions from the history;
2. Run read-only probes against critical records such as files, database entries, orders, or permissions;
3. Distinguish verified completion, attempted-but-unknown completion, and confirmed failure;
4. Keep compensation separate from history rewriting, since correcting text cannot replace a missing write;
5. Use idempotency keys, transaction IDs, or checksums for side effects that cannot be queried directly.

This approach adds one or more tool calls and introduces verification latency. In return, it can reduce the combined cost of erroneous skipping and repeated execution. Database workflows benefit from readable commit results, transaction status, and version numbers. File writes, message delivery, and payments require task-specific completion evidence rather than a generic language template.

Deployment Recommendations

Agent frameworks should store structured state alongside natural-language history:

• claimed_success: the model says the action completed;
• verified_success: an external system confirms completion;
• effect_absent: the target effect is confirmed missing;
• unknown: the tool timed out, returned an ambiguous response, or exposes no observable side effect.

Recovery should skip a step only when verified_success holds, not merely when claimed_success appears. Background or asynchronous tools should default to unknown until a query or reconciliation process resolves the state.

Evaluation suites should add negative cases such as false-success receipts, corrected text with uncleared side effects, and truthful notes that preserve an existing error. An agent demonstrates state-aware recovery only when it verifies state or compensates when reality and history disagree.

The central principle is direct: a correct statement in context is not a fact, and a tool receipt is not world state. Agent recovery depends on whether the two agree.

---

Source: ArXiv AI (cs.AI) (2026-11-13)

— END —

Tags: #Tool-Using Agents Follow #Context Repair Follow #State Consistency Follow #Error Recovery Follow #AgentCE-Bench Follow