Skip to content

CONCEPT Cited by 1 source

Memory supersession

Definition

Memory supersession is the discipline of updating an agent-memory fact or instruction by keeping the old memory, linking it forward to the new one, and retiring its index entries — rather than deleting-then-inserting. The mechanism: every fact / instruction gets a normalised topic key at classification time; when a later memory has the same key, a forward pointer is written from the old memory to the new one, and the old vector is deleted in parallel with the new upsert.

The outcome is a version chain per topic — durable audit of how a fact evolved — while retrieval only surfaces the current version.

Canonical wiki instance: Cloudflare Agent Memory.

"Facts and instructions are keyed. Each gets a normalized topic key, and when a new memory has the same key as an existing one, the old memory is superseded rather than deleted. This creates a version chain with a forward pointer from the old memory to the new memory."

— (Cloudflare, 2026-04-17)

Why supersession, not delete

  • Temporal queries. "What did we think the rate limit was before the April 10 incident?" needs the old value on disk.
  • Audit. How did this agent's understanding of the user's preferences drift?
  • Rollback. If the new fact was an extraction error, reverting is a pointer flip, not a re-ingestion.
  • Vector cleanliness. Searching should hit only the current version — so the old vector is retired, but the old memory row stays. Vectors for superseded memories are deleted in parallel with new upserts (not sequentially — the system does not accept a retrieval window in which both the old and new vector live).

Topic key as the supersession unit

The topic key is the what is this memory about classification — a normalised label under which at most one fact / instruction can be live.

  • Good: "package-manager-preference", "prod-database-hostname", "ci-test-timeout-setting".
  • Bad: "user said", "agent decided" — not scoped to a topic.

The topic-key normalisation algorithm is not published in the launch post; what is published is the semantic constraint — keyed by a stable topic, same key ⇒ supersede.

Memory types and supersession

Not all memory types supersede:

Type Keyed? Superseded?
Fact yes yes
Instruction yes yes
Event no (timestamped, not topical) no — events are historical
Task no no — tasks are ephemeral

Events are a historical log; overwriting would erase the log. Tasks are explicitly ephemeral (the classifier's TTL-like category); supersession isn't the right mechanism — eviction is.

Interaction with content-addressed IDs

Content-addressed message IDs give idempotent re-ingestion — the same conversation, re-posted, produces a no-op. Supersession handles the different case: new information about the same topic, arriving as a structurally-distinct memory. Both mechanisms avoid duplicate-memory pollution, at different granularities (exact-content vs same-topic-key).

Write amplification

The cost of supersession:

  • One extra row (the new memory).
  • One forward-pointer update on the old row.
  • One vector delete + one vector upsert, in parallel.

Read cost at retrieval is unchanged — only the live version has a vector / current FTS token. The version chain is reachable by ID walk, not by search.

Seen in

Last updated · 200 distilled / 1,178 read