What an Agent Should Forget (and Why That's the Harder Problem)

Every agent-memory vendor pitch starts the same way: your agent will remember everything, across every session, forever. It's a good pitch. It's also the wrong goal. An agent that remembers everything, indiscriminately, doesn't behave like a thoughtful assistant with a good memory — it behaves like someone who brings up an argument you had four years ago in the middle of an unrelated conversation. Perfect recall isn't the same as good judgment about what's still relevant.

The engineering conversation around agent memory spends most of its energy on storage, retrieval, and persistence — how do we make facts survive a session boundary. Almost none of it addresses the inverse: how do we make facts stop surviving once they're wrong, stale, or simply no longer useful. Forgetting isn't a missing feature bolted on as an afterthought. It's a design problem at least as hard as remembering, and most production memory systems handle it badly or not at all.

Three different things people mean by "forget"

The word "forget" hides at least three distinct problems that deserve different solutions.

The first is staleness: a fact was true and no longer is. "User works at Acme" needs to become "user works at Beta Corp" without the system treating both as simultaneously valid. This is a contradiction-resolution problem, and it's the one most memory frameworks handle best, because it maps cleanly onto database semantics — update a record, or version it.

The second is irrelevance without falsehood: a fact remains technically true but has stopped mattering. The user mentioned, eighteen months ago, that they were considering a career change. They didn't; nothing about that fact is false, but surfacing it today would be strange and slightly unsettling. This is harder, because nothing marks the fact as wrong — it just decayed in relevance, and relevance decay doesn't announce itself the way a contradiction does.

The third is deliberate deletion: the user asked the system to forget something, or a legal/compliance requirement demands it be purged. This one is the least technically interesting and the most operationally unforgiving, because "forget" here has to mean actually gone — not soft-deleted, not still retrievable through some fallback path. It's the subject explored more fully in The Privacy Question Nobody Answers When They Ship Agent Memory, but it's worth flagging here because it's the one case where "the agent forgot" needs to be a hard guarantee, not a soft heuristic.

Contradiction resolution is where temporal graphs earn their keep

For the staleness problem, the frameworks that handle this best are the ones that never treat memory as a flat append-only log in the first place. Zep's Graphiti engine models memory as a temporal graph precisely so that "user works at Acme" and "user works at Beta Corp" aren't competing facts an LLM has to arbitrate at inference time — they're the same fact at two different timestamps, and the system can simply serve whichever is current, or serve both with their validity windows attached when history actually matters.

Contrast that with a plain vector store, which has no native notion of time. Both facts get embedded, both get retrieved when they're semantically close to a query, and the burden of figuring out which one is current falls entirely on the model reading the retrieved context — which will get this wrong often enough to matter, especially under prompt pressure from a long conversation.

Relevance decay is a scoring problem, not a deletion problem

The irrelevance-without-falsehood case is subtler, because deleting the fact outright is usually the wrong move — it might become relevant again. The better mental model is decay: a fact's retrieval priority should fall over time and with disuse, the way a login session times out rather than being immediately revoked. A memory system that scores facts by recency and access frequency, downweighting things nobody's touched in months, gets most of the benefit of forgetting without the risk of actually losing information that turns out to matter later.

This is where the core-memory-versus-archival-memory split explored in Core Memory vs Archival Memory does double duty. A fact that decays out of relevance is a natural candidate to demote from core memory (always in the prompt) to archival memory (retrieved on demand) rather than being deleted outright. It's still there if a future conversation genuinely needs it; it just stops paying rent in every single turn until it does.

Why unbounded accumulation is a silent failure mode

The failure mode of not forgetting isn't dramatic — it's slow. An agent that never prunes anything accumulates memory at a rate that eventually degrades retrieval quality across the board, not just for the stale facts specifically. More stored memories means more noise for any similarity search to sift through, more candidates for a graph traversal to consider, more tokens competing for space if too much gets pulled into a single prompt. A memory system with no forgetting policy doesn't fail cleanly; it just gets gradually worse at retrieving the right thing, in a way that's hard to diagnose because nothing is technically broken.

Frameworks that treat memory management as an ongoing background process, not a one-time write, are the ones built for this reality. LangChain's LangMem SDK is explicit about this split — it supports both memory extraction during a live conversation and background memory processing that consolidates, updates, and prunes what's already stored, running as its own maintenance pass rather than something that only happens at write time. That background consolidation step is exactly where a forgetting policy belongs: not as a reactive fix when retrieval quality visibly degrades, but as routine maintenance that runs whether or not anyone's noticed a problem yet.

Designing a forgetting policy on purpose

A memory system without an explicit forgetting policy has an implicit one — usually "never," which is the worst possible default because it fails silently and expensively. Building the policy on purpose means answering a small number of concrete questions before you ship: which categories of fact are time-bound by nature (a user's current job, an active project) versus durable (a stated preference, a name)? What triggers a demotion from core to archival, or from archival to cold storage? Does the user get a way to explicitly correct or purge something, and does that correction actually propagate everywhere the old fact was cached, not just in the primary store?

None of these questions have universal answers — they depend on what your agent is for. But not asking them isn't neutral; it's a decision to let staleness accumulate until a user notices the agent confidently repeating something that stopped being true months ago. That moment — where the agent's memory becomes evidence against it rather than for it — is the one every serious memory implementation is trying to design around, and it's the reason forgetting deserves the same engineering attention as remembering, not less.

Part of the "Agent Memory" series on aiskill.market.