Supersession, decay, and forget

Most memory products fold three different questions into a single "delete" or "rank lower" behaviour. A correction can disappear, a stale preference can still win at retrieval, or an erasure request can leave records in a backup table nobody queries.

SurrealDB Agent Memory keeps the three mechanisms separate:

If these share one overwrite or one ranking pool, you either lose the audit trail or you let two "current" beliefs fight at query time.

Supersession - replacement with history

When an updated preference or corrected fact arrives from the same kind of source (for example two statements from the same user over time), SurrealDB Agent Memory treats it as you changing your mind, not a contradiction to flag.

• •

  The prior belief is closed in time, not erased.

• •

  The new belief becomes the single current answer for “what is true now?”

• •

  You can still ask what the value was last month and when it changed.

Instructions behave the same way: “always use formal tone” superseded by “prefer casual” means the agent follows casual now, but the shift remains auditable.

Cross-provenance clashes are different - an uploaded policy versus a user assertion - and surface as uncertainty instead of a clean supersession. See Authority when pillars meet.

Decay - relevance without destruction

Not everything should live at full strength forever. Context fades quickly; knowledge fades more slowly; identity is comparatively stable. SurrealDB Agent Memory applies category-aware importance decay on a schedule.

Decay is not blind deletion: a decayed fact can still be retrieved. Recall does not currently raise a fact's importance, so a fact that is retrieved often decays at the same rate as one that is never retrieved.

The decay pass runs once a day and multiplies each fact's importance by a fixed rate for its category:

Decay changes importance only. It never ends a fact, so a decayed fact can still be retrieved.

The figure below plots the starting importance and daily rate of each category over 60 days.

Expiry of context facts

A context fact expires 7 days after its known time (created_at). Agent Memory checks for these facts every hour. Expiry sets the fact's valid_until, so the fact leaves current retrieval but stays in the entity's history. Nothing is deleted.

The expiry pass applies to context attributes and actions. It skips:

• •

  facts that already have a valid_until

• •

  facts that a later value superseded

• •

  relations, whatever their category

• •

  topic rollups and gists, which end when the facts they summarise end

What you can configure

The 7-day expiry and the decay rates are the same for every Context, scope and principal, and on every deployment, including Enterprise deployments. You cannot set them per Context or per scope. You control them in these ways:

• •

  Choose the category at write time. Triples take a memory_category, so a fact that must not expire can be written as knowledge or identity.

• •

  Run a pass on demand. POST /api/v1/{context_id}/lifecycle/expire runs the expiry pass and needs the memory:forget grant. POST /api/v1/{context_id}/lifecycle/decay runs the decay pass across the whole Context and needs the grant:manage grant over /. Both use the same rules as the scheduled passes.

Background consolidation can also crystallise repeated observations into durable beliefs (source.kind = "consolidation") - the “between conversations” evolution described in Traces and memory evolution.

Forget - explicit removal

When something must stop influencing the agent - privacy, compliance, or a hard reset - use POST /forget or entity delete. Default behaviour expires matched records from current retrieval while keeping audit history; purge: true and scoped forget exist for erasure requirements.

Forget does not block future extraction: if a later turn mentions the same topic again, new memory can be created. Combine product policy with forget when a topic must stay gone.

The figure below compares what each mechanism on this page leaves in current recall, in point-in-time reads, in history and in storage.

Long sessions and compaction

Existing model context windows encourage compaction, namely the process of squashing a long thread into a summary. Summaries are inherently lossy, often discarding details you did not know you would need later.

SurrealDB Agent Memory’s approach is complementary: important facts from turns are promoted into durable, queryable memory (entities, attributes, instructions) while the full episodic transcript remains addressable via sessions and provenance. Consolidation and reflection run between interactions so you are not dependent on remembering to compact at the right moment for memory to survive the next session.

Who owns the decision?

The reconciler owns the bookkeeping guarantees - supersession chains, confidence floors, decay schedules, uncertainty when sources disagree. Signals come from agent actions: turns, corrections, document ingest, reflection, and traces of what was retrieved and used.

When the system genuinely cannot decide (cross-provenance conflict, confidence below the calibration floor), it records uncertainty for the agent or a higher-level policy to resolve rather than silently picking a winner.

Related reading

• •

  Reconciliation and supersession

• •

  Tri-temporal model

• •

  Forgetting memories

• •

  Traces and memory evolution