C3 Updated 2026-06-20
Pillar 1 - Memory and Context

Supersession-Aware Memory: How Agents Handle Facts That Change

Supersession-aware memory tracks when newer source evidence replaces older facts, so agents do not treat stale and current memories as equal.

Supersession-aware memory tracks when a newer fact replaces an older fact and makes that relationship visible at retrieval time. It prevents agents from treating last quarter’s policy, price, endpoint, or decision as equally current just because the old source is still searchable.

What is supersession-aware memory?

Supersession-aware memory is memory with replacement semantics. Instead of storing facts as isolated snippets, it records that one source item, artifact, or memory entry supersedes another.

The core fields are simple:

  • source_id: where the memory came from.
  • supersedes_id: the older source or memory it replaces.
  • is_current: whether this item should be treated as the current version.
  • effective_at: when the fact became true, if known.
  • invalidated_at: when the older fact stopped being current, if known.

Temporal memory systems are an active research and product area. Zep’s Graphiti paper frames agent memory around temporal knowledge graphs that capture changing facts over time (Graphiti paper). You do not need to ship a full temporal graph to use the supersession idea. You do need to stop pretending every remembered fact is timeless.

Why do agents answer with stale facts?

Agents answer with stale facts when retrieval has no concept of replacement. If a docs site has both “Pro plan is $29” and “Pro plan is $30,” a keyword search may return either. If both chunks look relevant and neither is marked current, the model has to infer the timeline from text alone.

Context engineering does not eliminate this problem by itself. Anthropic’s guidance emphasizes giving agents the right context for the task (Anthropic context engineering). Supersession-aware memory is one way to make “right context” measurable: prefer the current source, but keep the replaced source inspectable.

How does supersession differ from decay and deletion?

Supersession is often confused with decay or deletion. They solve different problems.

MechanismWhat it meansBest forWhat to inspect
SupersessionA newer fact replaces an older fact.Prices, policies, endpoints, roadmap status.Which item replaced which older item.
DecayOlder facts become less likely to retrieve over time.Preferences or weak signals that age out.Age, confidence, and retrieval weight.
DeletionA fact or source is removed or disabled.Privacy requests, incorrect imports, revoked sources.Deletion target and derived artifacts.
CorrectionA human changes or annotates a memory.Bad summaries, bad tags, wrong source mapping.Original value, new value, actor, time.

The safest system keeps these distinct. A replaced fact is not necessarily wrong. It may remain important for audit history. A deleted fact should not continue to appear simply because it was once current.

What does a concrete supersession example look like?

Imagine a product page that used to say:

Pro plan: $29 per month. Includes the old credit grant.

Then the pricing page changes:

Pro plan: $30 per month. Includes the current credit grant.

A naive memory system stores both snippets. A supersession-aware system records the second page version as current and links it to the older page version. When a user asks “What is the Pro price?”, retrieval should favor the current item. If a user asks “When did pricing change?”, the inspector should show both items and the replacement relationship.

The answer should not need a hidden prompt like “prefer newer docs.” The memory layer should carry the relationship.

What should a supersession-aware retrieval trace show?

A useful trace includes:

  • The current source item.
  • The superseded source item.
  • The reason the current item was preferred.
  • The date or version that established the replacement.
  • Any uncertainty when the system cannot infer the relationship.

That trace protects the product from overclaiming. If the system only has document-level supersession, say that. If it lacks bi-temporal validity, do not claim parity with systems that model temporal edges in detail. The honest claim is still valuable: changed source artifacts should be visible as changed source artifacts.

How should teams implement supersession without overbuilding?

Start with source artifact versioning. For each ingested source, store the canonical source ID, a content hash, a version or updated time, and whether the item is current. When a new version arrives, mark the older artifact as superseded and link the two.

Then make retrieval aware of current state:

  1. Prefer current artifacts for ordinary answers.
  2. Keep superseded artifacts available for audit and “what changed” questions.
  3. Show supersession state in the inspector.
  4. Let users correct false replacement relationships.
  5. Avoid publishing a temporal accuracy claim until you have a reproducible evaluation set.

This keeps the first implementation useful without pretending to solve every temporal knowledge problem.

Supersession is one forgetting primitive, but it is not the whole story. A superseded fact is remembered as history while no longer treated as current. A deleted fact should be removed or disabled. A decayed fact remains available but lower priority. A drifted fact may need investigation because the source changed without a clear replacement.

The ForgetEval benchmark proposal separates forgetting behaviors such as supersession, decay, amnesia, purge, and drift, which is a useful vocabulary even before you run a benchmark (ForgetEval).

Where does Answer Engine fit?

Answer Engine already positions memory around inspectable, supersession-aware source recall. The honest launch claim should stay grounded: source artifacts can carry lineage and current-state metadata; deeper temporal evaluation and product inspector views are roadmap-labeled until the relevant product issues land.

That positioning matters because agents are increasingly used against living sources: docs, tickets, drive folders, project decisions, pricing pages, and launch plans. A memory layer that cannot represent replacement will eventually teach the agent to sound confident about yesterday’s truth.

Sources

Fig. 9 FAQPage schema / visible answers
FIG. 9

FAQ

What is supersession-aware memory?

Supersession-aware memory records when a newer source or memory replaces an older one, then exposes that state during retrieval and inspection.

Is supersession the same as deletion?

No. Supersession preserves lineage while marking an older fact as replaced. Deletion removes or disables a memory according to a deletion policy.

Why does supersession matter for agents?

Agents often answer from old docs, tickets, and decisions unless the memory layer makes replacement relationships visible.

NEXT

Build memory you can inspect.

Answer Engine gives agents a persistent, tenant-isolated memory layer via MCP, with source-aware recall and roadmap-labeled inspection work.