Forgetting and Eviction in AI Agent Memory

Why does an agent memory system need to forget?

Because retrieval quality falls as the store grows, long before storage cost becomes an issue. Forgetting is usually presented as a capacity problem. It is a precision problem, and treating it as capacity leads to the wrong policy.

Consider what a store looks like after a year of use. A user has hundreds of records, most of them true when written and irrelevant now: a project that shipped, a preference stated in a context that no longer applies, a question they asked once. All of them are still semantically close to plausible queries, so all of them are still candidates, and every one takes a place that a current fact could have held.

The consequence is not slow search. Modern stores handle far more records than any single user will ever accumulate. The consequence is that the top few results returned to the model contain something out of date, and the model presents it as current, because nothing in the prompt says otherwise. That failure looks to a user like an agent making things up.

There is a second reason, cheaper to act on than any eviction policy: much of what needs forgetting should never have been written. A write path that stores every turn creates the problem that a forgetting policy then has to solve, and tightening extraction is more effective than any pruning rule, as set out on writing memories.

Assuming the store is already accumulating what it should, the question becomes which records to remove and on what basis: which eviction strategies exist, and what does each get wrong?

Should you delete a memory or retire it?

Retire it, in almost every case. Two very different operations get called forgetting, and conflating them is why so many memory systems have a policy nobody can tune and nobody can undo.

Retiring means the row stays and stops competing. It is excluded from ordinary retrieval by a predicate every read already carries, it can still be reached by an explicit lookup or an audit, and the decision can be undone if it turns out to have been wrong. In schema terms it is one column, which is the shape described on storage backends.

Deleting means the record is gone. That is the right operation for a narrow set of cases: a person asking for their data to be removed, a record that should never have been stored, a retention limit that requires destruction rather than concealment. Those cases are real and they are governed by obligations rather than by quality judgements, which is why they belong on memory security and privacy.

The practical argument for retiring is that it keeps the evidence. A deleted memory tells you nothing about whether deleting it was correct. A retired memory that would have been the best match for a later query is a measurable signal that the policy is too aggressive, and that signal is the entire basis of the testing approach further down this page.

Retiring on supersession is straightforward, because a newer fact justifies it. Retiring on age needs a number, and choosing that number is where most systems guess: how do you choose a time-to-live without guessing?

What happens to a fact that goes stale without being contradicted?

It stays, and it stays confident. This is the failure mode of relying on supersession alone, and it is the reason decay is a complement to it rather than an alternative.

Supersession retires a record when a newer statement contradicts it. That works whenever the user says the contradicting thing. It does nothing at all when they simply stop mentioning the old one. Someone who moved city and never announced it, whose project ended, whose child grew out of a stage, whose job title changed: the store holds a fact that was true, has no successor, and will keep being retrieved with full confidence.

Research on human memory has treated forgetting as an active process rather than simple loss for decades, and the same framing is the useful one here: the mitigation is a gentle time-based decay applied on top of supersession, so that an old fact gradually loses weight even with nothing to replace it. It never disappears on its own, which is correct, because a fact that has been true for two years is not less true for being old. It simply stops outranking newer, better-evidenced records.

A second mitigation is worth building for high-value facts: ask. An agent that surfaces a two-year-old preference and adds a light confirmation is doing what a person would do, and a confirmed fact can have its written-at value refreshed, which resets the decay honestly rather than by assumption.

There is a third case worth separating out, because it is not staleness at all: the fact that was never true. A model inferred something from a turn and stored it as though the user had said it, and no contradiction arrives because the user never knew it was recorded. Decay eventually lowers its weight, which is a slow remedy for something that should not have been written; the faster one is marking inferred records as inferred at write time so they can be weighted differently or confirmed before they are ever asserted.

Both of those push in the direction of forgetting more. The opposite failure is more visible to users and worth guarding against explicitly: how do you avoid forgetting the things that mattered?

Is summarising the same as forgetting?

No. It is lossy compression, and the loss is chosen by a model rather than by your policy. Summarisation is frequently offered as the humane alternative to eviction, and it is a genuinely useful technique with a different risk profile that deserves stating plainly.

Replacing twenty session records with one summary reduces volume while keeping something of everything, which is the appeal. What it also does is discard specifics without telling you which ones. The summary keeps the gist and drops the exact figure, the qualifying condition, the name. Those details are often precisely what a later query needs, and unlike an evicted record, a summarised one cannot be recovered, because the original is gone.

The safer pattern is to summarise and retire rather than summarise and delete. Write the summary as a new record, retire the originals, and keep them. Retrieval improves because the summary is a better match for general queries, and the specifics remain reachable when something needs them. This costs storage, which is the cheapest thing in the system.

The wider treatment, including when consolidation is worth running at all and how it interacts with idle time processing, is on memory consolidation. The distinction to carry away is that eviction removes records you judged unnecessary, while summarisation removes details a model judged unnecessary.

Every mechanism on this page changes what the agent knows, silently, which raises the question the sources on this subject do not: how do you test that forgetting is working?

What has to be deleted rather than forgotten?

Anything a person has asked you to remove, and anything you should not have stored. These are obligations rather than tuning decisions, and retiring does not satisfy them, because the record still exists.

The distinction matters in practice because the two paths look similar in code and are not similar in consequence. A retired memory is present in the database, in its backups, and in any index that has not been rebuilt. If a person exercises a right to have their data removed, which the GDPR calls the right to erasure and several other regimes mirror, a boolean column does not discharge that, and neither does removing the row while leaving the vector in an index that was built from it.

A deletion path therefore has to cover every tier that holds a copy: the record, its vector and index entry, any summary derived from it, the event history that logged it, and the cached session that may still hold it in working state. That is easier to guarantee when the tiers share a database, which is one of the arguments on storage backends, and it is a path worth designing when the schema is designed rather than when it is first requested.

Three categories are worth deleting on sight rather than retiring: credentials or secrets that reached the store through a conversation, data belonging to a category you have no basis to hold, and anything written under an identity that turned out to be wrong. The obligations, the categories and the practical mechanics are covered on memory security and privacy, which owns that subject.

For everything else, the policy on this page holds: retire rather than delete, put a floor under age and usage rules, add decay so that stale facts fade without needing a contradiction, and keep the evidence that tells you whether any of it was set correctly. The loop these decisions sit inside is on how AI memory works, and what should reach the store at all on writing memories.