The stale-memory problem

You told your agent something once: the staging endpoint, a config value, a customer’s status, a preference. Then it changed. The problem isn’t that your agent forgot — it’s the opposite. It remembers, perfectly, the version that’s no longer true. Both the old fact and the new one sit in memory with near-identical embeddings, recall surfaces the stale one, and the agent acts on it with full confidence. A wrong action, at the speed of inference.

This is the single most common failure of agent memory, and it’s the open problem the field admits it hasn’t solved at the tooling level. Retrieval has a blind spot: it has no representation of time. “The timeout is 1800 seconds” and “the timeout is 3600 seconds” differ by one token and sit right next to each other in any embedding space. The store returns both. The model has no principled way to tell which is current — so it guesses, often serving the stale value.

Deleting the old record doesn’t fix it either: its influence has already leaked into summaries and derived context. What you actually need is for memory to model change as evolution — this replaced that, as of then — not as a pile of contradictory facts ranked by recency and similarity.

Current-truth recall (free)

MADB 0.2.13 adds Temporal Validity. When a fact changes, you mark the old memory superseded by the new one:

From then on, recall returns current truth — the superseded version is hidden, its replacement surfaces. Your agent stops acting on facts it already updated. The old record isn’t deleted; it’s demoted. Ask recall(as_of=T) and MADB reconstructs what you believed at time T — the honest answer to “what did we know when we made that call?”. Because MADB is causal, this is the same graph that powers trace_cause: freshness and lineage are one object, not two systems bolted together.

Provable forgetting (enterprise)

Sometimes “no longer true” means “must be removed” — a poisoned memory, a retracted fact, a compliance deletion. Deleting a record is not the same as removing its influence: it may already live in summaries and derived beliefs. MADB’s revoke walks the memory’s bounded provenance closure, tombstones the belief and its direct derivations, and returns a Memory Revocation Certificate — proof that the belief no longer reaches a live decision, with the closure, the tombstoned set, and a residual-reference count of zero. Provable forgetting, not best-effort deletion. This is an enterprise capability; current-truth recall is free.

Why MADB can do this and a vector store can’t

Supersession needs three things a flat vector store doesn’t have: a notion of time on every memory, a causal graph to bound what a fact’s revocation touches, and a durable record that survives a restart. MADB has had the first two since day one — every memory carries a hybrid-logical timestamp and a caused_by lineage — and 0.2.13 made the third rock-solid. It’s the same substrate, doing one more honest thing: telling your agent what’s still true.