Forgetting as a feature
Lesson 4 of 5 in Agent Memory: Remembering and Forgetting on Purpose.
All three failure families in lesson 3 share a root cause: memory that is permanent, anonymous, and invisible by default. The fixes share a shape too — make it none of those things.
Human memory forgets by design, and it turns out that was never a flaw to engineer away. A healthy agent memory system forgets on purpose: facts carry expiry dates, every entry knows where it came from, and the person the memory is about can see it and delete it. Forgetting is not data loss. Forgetting is quality control for beliefs.
| Control | What it counters | What it looks like in practice |
|---|---|---|
Expiry / review dates | Stale facts resurfacing | Every entry gets a time-to-live or a review-by date; expired facts are dropped or demoted to "re-verify before use". Volatile facts (addresses, prices, org charts) get short fuses; stable ones get long fuses — none get no fuse. |
Provenance | Poisoning and unaccountable beliefs | Each fact records who or what wrote it, when, and from what source. Facts derived from untrusted content (webpages, emails, tool output) are tagged as such and trusted less — and when poisoning is suspected, provenance is the trace that finds every tainted entry. |
Write gates | Poisoning at the point of entry | Persisting a memory is an action, and consequential actions get gates: facts from untrusted sources require explicit confirmation — a human-in-the-loop approval or at minimum a quarantine tier — before joining trusted memory. |
User-visible memory | Privacy accumulation and silent drift | The user can open the memory, read every fact about them, edit, and delete. Visibility converts memory from covert profiling into a shared, correctable artifact — and doubles as a poisoning tripwire, because users notice facts they never said. |
Scoped stores | Cross-contamination | Memory is partitioned per user, per project, per tenant. A fact learned in one scope cannot leak into another — the least privilege principle applied to knowledge instead of permissions. |
Walk the write gate: should this fact enter long-term memory?
Interactive decision tree — outcomes:
- Keep it on the session horizon
Do not persist. The default answer to "should we remember this?" is no — every write is a liability accepted, and this one buys nothing.
- Stop — this is the poisoning doorway
Untrusted content asking to be remembered is exactly how memory poisoning works (OWASP ASI06). Do not write it directly to trusted memory. Quarantine it, tag its provenance as untrusted, and require explicit human confirmation before promotion.
- Persist only with the privacy kit attached
Store it only if the user can see it, edit it, and delete it — with a retention limit and a scope boundary. If you cannot offer user-visible memory, do not store personal data at all.
- Write it — with provenance and a short expiry
Record source and date, and set a near-term review-by date. Volatile facts are tomorrow’s stale facts; the fuse is what keeps them honest.
- Write it — with provenance and a long fuse
Even stable facts get provenance and an eventual review date. "Permanent" is not a memory tier; it is a bug report scheduled for later.
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.