Memory: Retrieval and Forgetting

In one line: the assistant knows a lot and can use a little, so what surfaces is decided by a scoring function — and what it gets wrong is usually staleness rather than relevance.

Scoring

Pure semantic similarity is not enough, because the most similar memory is often not the most useful one. The common shape combines three factors.

Relevance — semantic similarity to the current task. The base signal.

Recency — how long ago, with a decay. A preference stated last week outranks the same preference stated two years ago, because people change.

Importance — how much this memory matters. Explicit statements ("always cc my manager on these") outrank inferred patterns; things the user corrected outrank things they never mentioned.

Two practical notes. Weight the memory type as well: a semantic preference is usually more useful to a current task than a specific episode, so the tiers get different multipliers. And keep the retrieved set small — the published patterns land on a handful of memories under a tight token budget, which is far less than instinct suggests.

Stale is worse than missing

The failure that matters most, and it is asymmetric in a way people underestimate.

A missing memory produces a generic assistant. Mildly disappointing, and the user can supply the information.

A stale memory produces a confidently wrong one. It books the hotel near the office you left last year, cc's a colleague who has moved teams, or schedules around a commitment that ended. And it does so with the fluency of something that knows you, which is precisely why it is worse — the user has no reason to check.

Decay and pruning

Which produces an explicit forgetting policy rather than an implicit one.

Decay by tier. Working memory ends with the task. Episodes decay over weeks unless referenced. Semantic facts persist and still need review — a preference not reinforced in a year is a candidate for retirement.

Refresh on use. A memory retrieved and acted on without correction is evidence it is still true, so its decay resets. One that is retrieved and then contradicted should be weakened immediately, not merely left.

Prune on contradiction. The strongest signal available. If the user says "actually I prefer the window now", the old fact is not merely outdated — it is wrong, and it should be replaced rather than left to compete.

That last one requires noticing the contradiction, which means memory writes have to check against existing facts rather than appending blindly. An append-only memory accumulates contradictory beliefs and retrieves whichever scores higher, which is arbitrary.

Time-bounding facts

The refinement that prevents a large class of staleness.

Many facts are true for a period rather than forever. A project, a role, a living arrangement, a recurring commitment. Storing "works on Project Falcon" without an expectation of change means it persists indefinitely.

So where the type of fact suggests it, attach a review horizon — not a hard expiry, but a point at which the fact is treated as uncertain and worth confirming. "You used to work on Falcon — still?" is a cheap question and it prevents a year of quietly wrong assumptions.

Deletion has to work

The requirement that is a legal obligation and a trust one.

A user asking the assistant to forget something must have it actually forgotten — from the semantic store, the episodic log, the embeddings, any cache, and anything derived from it. The last is the difficult one: a semantic fact consolidated from three episodes survives the deletion of those episodes unless the derivation is tracked.

Which is the practical argument for keeping provenance on consolidated facts: without it, deletion is incomplete by construction, and you cannot answer "why do you think that about me?" either.

Two more requirements worth stating. Deletion must be available in the moment — a user who notices a wrong memory should be able to remove it there, not in a settings page. And the memory store should be inspectable: showing people what the assistant has learned about them is both the honest thing and the cheapest way to get corrections.

The retrieval failure to watch

One specific mode, because it is common and confusing.

The assistant retrieves a memory that is relevant and current and still wrong for this task, because the context differs. "Prefers aisle seats" is a real preference and does not apply when booking for the user and their partner, who want to sit together.

There is no clean mechanical fix. The mitigation is to treat retrieved memories as defaults rather than constraints — the assistant proposes based on them and remains open to the current request overriding. Concretely, an explicit instruction in the current turn always beats a remembered preference, which sounds obvious and is exactly what a naive prompt assembly gets wrong when the memory is injected with equal weight.

Next: acting without being asked.