Memory and State Management

Memory and State Management

Memory Expiration and TTL

46 of 69 in this book · 3 min read

What it is

Attaching a lifetime to a stored memory so that it lapses without anyone deciding to remove it: a session note that dies with its session, a "currently blocked on" that is meaningless in a month, a cached derivation that must not outlive the material it was derived from. The mechanism is a clock and a sweep. The design work is deciding what the clock is attached to, what the lapse means to a reader, and which items are allowed to be exempt.

Why lapsing is not erasure

Expiry is an availability policy chosen because old memories stop being useful. It can be best-effort, enforced lazily, and nobody is harmed if a sweep runs a day late. Erasure is an obligation: it is requested or legally compelled, it must reach derivatives and backups, and it has to be provable afterwards. A TTL sweep is not a deletion mechanism even though it deletes, because nothing in it produces evidence that a particular item is gone, and nothing in it guarantees the sweep ever ran.

Why it matters

Without lifetimes the default for every memory system is permanent, and permanent is the wrong answer for most of what gets written. Circumstances change, and an agent acting confidently on a stale circumstance is worse than one that has forgotten it. Expiry is also the cheapest control available on unbounded growth and on the standing exposure of a store that otherwise only ever accumulates — most of the risk in a memory store is content nobody has needed for a year.

Key decisions

  • What the clock attaches to: the write, the last read, the validity of the underlying fact, or the lifetime of a parent object. A sliding last-read clock keeps useful memories alive and keeps the over-retrieved wrong ones alive just as well.
  • Whether lapse is enforced at read — immediately correct, with the bytes still in the store — or by a sweep, which shrinks the store and leaves items retrievable until it runs.
  • Which classes of memory may be exempt from the default, who may grant an exemption, and whether exemptions themselves expire.
  • What happens to items derived from something that is about to lapse: lapse together, survive independently, or hold the parent alive.
  • Whether lapse is observable to the agent, which decides whether it can say that it used to know something rather than behaving as if it never did.
  • How a lifetime is chosen per memory type rather than once for the store, since a stated preference and a recorded system state deserve very different ones.

Failure modes

  • The lifetime is set on the original record and the consolidated summary that absorbed its content has none, so the content outlives its own expiry in a different row.
  • Expiry is enforced only at read, the privacy posture assumes the data is gone, and the bytes have in fact been present for two years.
  • A sliding last-read clock keeps alive exactly the memories that retrieval over-selects, so the least accurate items are the most immortal.
  • Every memory gets the store's default lifetime because the write path has no way to express a type-specific one, and the default was chosen for the first use case anyone implemented.
  • The sweep interval and the externally stated retention commitment have never been compared, and they are inconsistent by weeks.
  • An item lapses mid-conversation and the agent contradicts within a single session something it asserted ten turns earlier.
  • The store is memory-bounded and evicts under pressure well before the stated lifetime, so the TTL is an upper bound that nobody treats as one.
  • Expiry is implemented but unmonitored, the sweep job fails silently for months, and the first sign is a storage alert rather than a retention report.

Related capabilities

Applies: Production readiness · Design questions