Why design deliberate forgetting into agent memory, and how would you choose TTLs?

## Forgetting is a feature Engineers instinctively treat deletion as loss, so agent memory tends to be built append-only and then quietly rots. The argument for deliberate forgetting is that a memory store is not an archive — it is a working belief set that gets injected into decisions. Three costs make unbounded growth actively harmful: - **Stale recall.** A fact that was true a year ago is retrieved with no signal that the world moved on, and the model treats it as current. This is the most damaging failure because it is silent. - **Crowding.** Only a handful of memories reach the model on any turn. Every expired-but-stored fact competes with a live one for that space. - **Liability and privacy.** Personal data retained past its purpose is a compliance problem in most jurisdictions, and "the agent still remembers something I told it two years ago" is a trust problem even where it is legal. ## Volatility classes, assigned at write time The cheapest and most defensible policy assigns an expiry when the fact is written, based on what kind of fact it is. The extractor already has the context to make that call. - **Structural / near-permanent.** Headquarters city, legal entity, account identifier, a stated lifelong preference. No expiry; these change rarely and a change will arrive as an explicit contradiction. - **Slow-moving.** Job title, team ownership, tooling in use. Long horizon — a year or more — with re-confirmation resetting the clock. - **Situational.** "Currently evaluating a competitor", "blocked on a security review", "hiring for two roles". Give these a bounded life; something around 180 days is a common shape, chosen because the claim's *meaning* includes the word "currently" and that word does not survive two quarters. - **Ephemeral.** Anything about the present moment. Ideally never written at all. The useful test when setting a horizon: *how long until this fact is more likely wrong than right if nobody ever mentions it again?* That is the expiry. It is a judgment, and stating it as a judgment is what a senior answer looks like. ## Decay as an alternative to hard horizons Fixed TTLs are crude for facts whose relevance is uneven. The alternative is a score that falls with time since last confirmation and rises with use and importance, with archival below a threshold. Re-confirmation is the key input: each time a fact is restated or corroborated, its clock resets. That makes the policy track reality rather than the calendar — a preference the user mentions every month never expires, while one stated once and never referenced again fades. The risk of decay scoring is that importance is hard to estimate at write time and "never recalled" is not the same as "not important": a critical safety constraint may go a year without being retrieved and must not be dropped. Practical answer — exempt a small, explicitly marked class from decay entirely. ## Soft versus hard deletion Default to **archival**: mark the record expired, exclude it from recall, keep it queryable for audit. That preserves the ability to answer "why did the agent do that in March?", and it makes expiry reversible when a horizon turns out to be too aggressive. But soft deletion is not enough when the requirement is *erasure*. A user exercising a deletion right, or data that must not be retained, needs a genuine hard delete that also reaches derived artefacts — index entries, summaries built from the record, and anything downstream that copied it. A system whose only deletion path is a status flag cannot honour that, and discovering it late is expensive. Design both paths from the start and know which requests route to which. ## Making the policy visible Because expiry is a judgment, it should not be invisible. Two things help: showing users what the agent remembers and letting them delete it, which turns the policy into a controllable product surface and yields a direct signal about extraction quality; and pinning — letting a user or operator mark a fact as never-expiring, which handles the long tail your classes get wrong. ## How you would know a policy is wrong Too aggressive shows up as the agent re-asking for things the user already told it, and as users repeating themselves. Too lax shows up as confidently stale answers. Both are observable in production if you look for them; neither is observable from the store's size. The honest framing for an interview is that these horizons are set by judgment, monitored by their symptoms, and adjusted — not derived from a formula. ## The contested part There is no settled consensus in 2026 on how much an agent should forget. One camp keeps everything and pushes all the work to retrieval, arguing that storage is cheap and judgment about relevance is best made when the question is known. The other argues that a belief set which never shrinks inevitably poisons decisions and that expiry is the only reliable defence. Saying this openly, and then giving the shape of your own trade-off, is a stronger answer than asserting a rule.