What Reliable Long-Term Memory Must Preserve

This series has treated long-term agent memory as a state-management system rather than a larger recall buffer. The final question is what that system must preserve when facts change, actions alter an environment, and the cost of maintaining state grows over time. The answer is update fidelity: a reliable memory must keep enough identity, time, provenance, state transition, and causal relationship information to retrieve the evidence that a current answer or action actually requires. It must also make that fidelity visible through tests of freshness, downstream behavior, and lifecycle cost.

Reliability means preserving change, not just retrieving facts

A fact can be retrieved and still be the wrong answer. If a user’s preference changed, the current value may be right for one query and the earlier value right for another. If a software interface has several revisions, the latest syntax may be useless to someone debugging an older release. If an agent is operating in an environment, a statement about an object may be relevant while its location, visibility, or state has already changed. Retrieval without the meaning of the update is not reliable memory; it is the recovery of a plausible fragment.

The distinction among current-state recall, historical lookback, and aggregation provides the first part of a unified model. Current-state recall asks for the value after applicable updates. Historical lookback asks for the value at a named earlier point. Aggregation asks the system to collect several states or events and combine them through ordering, counting, comparison, or multihop reasoning. These are not progressively harder versions of one operation. They demand different evidence access.

MINTEVAL makes this visible with evolving state, dialogue, Wikipedia revisions, and GitHub commits. Its Simple questions target recent state; its History questions reach back through later revisions; its Ordering, Counting, and Multihop questions require several targets. The evaluated systems average about 28 percent overall in the paper’s aggregate reports, with the best overall result at 33.4 percent. Simple questions average 47.5 percent, while History averages 21.0 percent and multi-target aggregation 26.5 percent. The exact aggregate is reported slightly differently in the abstract and the table discussion, but the durable result is the large gap between recent recall and update-dependent reasoning.

That gap is not just a retrieval problem. In the Wiki Revisions analysis, the required evidence exists in the full history by construction, yet only 58.3 percent of cases contain it in the retrieved documents or constructed memories. The source attributes a 41.7-point loss to retrieval or memory construction, followed by a further average 25.2-point loss when the evidence is present but the answering model still fails. The figures come from one subset and an LLM-based evidence check, not a universal causal law. They nevertheless expose a sequence of obligations: preserve the evidence, surface it, and then reason over it.

Agent trajectories add a second dimension. The relevant unit is no longer a sentence but a transition: an action, an observation, a tool result, and the state that connects them. A memory that names the goal but loses a precondition can cause an invalid action. A memory that preserves a destination but drops the key or unlock step is semantically related and operationally inadequate. AMA-Bench therefore distinguishes recall, causal inference, state updating, and state abstraction. The point is not to replace ordinary recall, but to show what recall must support when the agent is acting in a changing world.

These cases become one model when memory is viewed as a loop. An interaction produces evidence. Construction turns the evidence into persistent state. Storage determines which relationships and exact values remain available. Retrieval chooses a context according to the query’s operation. The answer or action changes what happens next. Maintenance consolidates, resolves, forgets, or re-embeds state, and the loop begins again. A failure can occur at every boundary: a lost update, a merged version, a missing causal edge, a stale store, an incomplete retrieval, or an answer that misuses available evidence.