What an assistant should forget
A Socratic walk-through of what an assistant should forget — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #How does a system remember you usefully without accumulating everything you ever said?
Storage is cheap, so the obvious design is to keep everything. Every message, forever, and let retrieval sort it out later. An assistant that remembers all of it would surely be the most useful one.
Then imagine using it. You mention once, in passing, that you are avoiding sugar this month. Two years later it declines to give you a cake recipe. Nothing malfunctioned — the fact was stored correctly and retrieved correctly. So the failure is somewhere else, and finding where is the whole subject.
Reasoning it through
REASONING #The failure is that a stored fact carries no expiry, and most facts about a person have one. "I live in Berlin", "I am learning Rust", "I prefer terse answers", "we are migrating off Oracle" — each was true when said, and each has a half-life that is nowhere in the record. Keeping everything does not preserve the truth; it preserves a snapshot and then quietly misdates it.
That is the first of three separate costs, and they are worth keeping apart because they pull in different directions.
The second is retrieval precision. Ask what happens as the store grows. Each new item is another candidate for every future lookup, and the ones that win are the ones that look most relevant — not the ones that are most true. Ten thousand remembered fragments do not make an assistant ten thousand times better informed; they make the signal-to-distractor ratio worse, and past some point the model spends its attention reconciling stale fragments with the current request.
The third is obligation and exposure. Anything retained can be disclosed, subpoenaed, or leaked, and must be deletable on request under data-protection regimes that also expect a reason for collecting it at all. Retention is a liability that accrues quietly, at rest.
So forgetting is not a concession to limited storage. It is a correctness feature, a retrieval feature, and a safety feature at once. The design question becomes: forget what, and how?
There are two moments where the decision can be made. At write time, you choose what is worth promoting from a conversation into durable memory. Notice that most of what is said is not a durable fact about the person — it is the details of the current task, which stop mattering when the task ends. The durable residue is small: stable preferences, identity and context, standing constraints. Extraction of that residue is a judgement, made by a model, and it is wrong sometimes — and a wrongly promoted fact is worse than a forgotten one, because it will be recalled with confidence forever.
At read time, you choose what surfaces. A well-known formulation from the Generative Agents work (Park and colleagues, 2023) scores each candidate memory on recency, importance and relevance together. Notice what recency-weighting really is: soft forgetting. Nothing is deleted, but old items stop winning, so the store can grow while its influence does not.
Soft forgetting is not enough on its own, for two reasons. First, facts do not merely fade — they get replaced. If you move city, both claims now sit in the store and retrieval may surface either. What is needed is supersession: the new claim marks the old one as superseded and dated, so the history is intact but only one is current. Second, decay does not satisfy an erasure request. Only deletion does, and deletion has to reach every derived copy — the rolling summary, the embedding index, the backups, the logs. A fact removed from the store but baked into a summary has not been forgotten; it has merely been laundered.
One more, less obvious, reason to forget. Memory is written by conversation, and conversation includes text the user did not author — a pasted document, a web page, a tool result. Anything that can write to durable memory is a place where an instruction can be planted and recalled later as though it were the user's own. Bounded retention limits how long such a planted item survives, which makes forgetting a containment mechanism as well.
And an honest caveat: what is worth keeping is not settled. There is no agreed benchmark for good forgetting, and current systems run on heuristics, expiry and user-visible controls rather than on anything provable.
The analogy
THE ANALOGY #Think of a good colleague as opposed to a complete transcript of everything you have ever said to them. The colleague remembers that you dislike long meetings and that your team owns billing; they have lost the details of a project that ended two years ago, and they update rather than accumulate when you tell them you have changed roles. The transcript is more complete and far less useful.
The colleague's forgetting is involuntary and unauditable — they cannot prove they have forgotten something, and cannot be made to forget on demand — whereas a system's forgetting has to be deliberate, provable, and chased down through every copy it has made along the way.
Clarifying the model
THE MODEL #Three refinements.
First, memory and context are different things, and conflating them causes most of the confusion here. The context window is what is in front of the model right now, and it is rebuilt every turn; memory is what persists between turns and is selected into that window. Nothing is remembered by having been in a context window, and nothing in memory has any effect until retrieval puts it back there.
Second, a stored memory should carry more than its claim — when it was learned, from where, and how it was inferred. Provenance is what makes a fact correctable, showable to the user, and challengeable. A bare sentence with no source cannot be audited, and cannot be sensibly aged either.
Third, a misconception: that more memory always makes an assistant feel more personal. Past a point it feels unpredictable, because behaviour depends on fragments the user cannot see and does not remember saying. The remedy is visibility as much as better retrieval — letting the user read, edit and delete what is held turns an opaque accumulation into something a person can steer.
A picture of it
THE PICTURE #How to readRead each line as "this thing relates to that thing", and the crow's-foot marks as counts. A conversation yields many candidate memory items, which is why the self-relation matters: an item points at the older claim it replaced, so the store keeps history without keeping ambiguity. Two different edges reduce an item's influence and they are not interchangeable — the retention rule makes it fade, the erasure request removes it, and only the second discharges an obligation. The provenance edge is the one most often left out of real designs, and it is what makes the rest auditable.
What became clearer
WHAT CLEARED #Forgetting is not what you do when storage runs out; it is how a memory stays true, stays findable, and stays defensible. The work splits into deciding what is durable enough to write, letting the rest decay so it stops winning retrieval, replacing rather than accumulating claims that change, and deleting outright — through every derived copy — when someone asks or a rule says you must.
Where to go next
ONWARD #- Consolidation: rolling summaries that compress old conversations, and what they silently make undeletable.
- Memory poisoning, and why the write path deserves the same scrutiny as a privileged tool call.
- User-visible memory controls, and how showing the store changes what people are willing to tell it.
Key terms
TERMS #| Term | What it means |
|---|---|
| Durable memory | facts promoted out of a conversation to persist between sessions, as distinct from the context window. |
| Extraction | the write-time judgement about which statements are worth keeping. |
| Recency weighting | scoring older memories lower at retrieval so they fade without being deleted. |
| Supersession | marking an older claim as replaced by a newer one, rather than storing both as equals. |
| Provenance | the record of when a memory was learned, from what source, and by what inference. |
| Memory poisoning | planting a durable instruction or false fact via ingested content, to be recalled later as trusted. |
Every term the collection defines is gathered in the glossary.