Govern how agent memories are created, corrected, expired, and removed across source records, summaries, embeddings, caches, and backups.
Agent memory is a managed data product rather than an indefinitely growing conversation history. Each retained fact or artifact needs a purpose, owner, source, access scope, and lifecycle. Forgetting means making information unavailable through the defined serving paths and managing retained copies according to explicit policy; deleting one chat message is rarely the whole operation.
Distinguish short-lived working context from durable user preferences, task records, and shared knowledge. Derived summaries can preserve information after the source changes, while embeddings and caches can continue surfacing stale facts. Use provenance and dependency tracking so corrections and deletion requests propagate to the artifacts that depend on the original material.
A proof of concept can retain only session context and document why any information must survive the session.
Production requires memory classification, write policy, source provenance, expiry, correction handling, access filtering, and a tested deletion or suppression workflow.
Enterprise scale adds derived-artifact inventories, asynchronous deletion tracking, retention exceptions, backup restoration controls, tenant boundaries, and verification that removed content cannot reappear in serving indexes.
Checks purpose, sensitivity, user scope, and allowed retention before creating durable memory.
Links memory items to source records and downstream summaries, embeddings, caches, and exports.
Enforces current access, validity, expiry, and suppression before memory enters a prompt.
Coordinates correction, expiry, deletion, and acknowledged cleanup across dependent stores.
Test serving-path removal and prevent old backups or replay jobs from resurrecting suppressed records.
flowchart LR
S["Authorized source fact"] --> G["Memory write gate"]
G --> M["Scoped durable memory"]
M --> D["Summaries embeddings and caches"]
C["Correction expiry or deletion"] --> P["Provenance lifecycle controller"]
P --> F["Serving suppression"]
P --> M
P --> D
P --> V["Verification and restore controls"]Identify whether the item is transient context, a durable preference, an operational record, or shared knowledge with a defined purpose.
Apply the write policy and attach owner, source, scope, creation time, expiry, and correction mechanism before persistence.
Filter retrieved memory by current access and validity, preferring authoritative source updates over stale generated summaries.
Accept a correction, expiry, or deletion request and immediately suppress affected serving records where the policy requires it.
Traverse provenance links to update or remove summaries, embeddings, caches, and exports while tracking acknowledgements and exceptions.
Probe retrieval paths, record completion evidence, and apply suppression records during backup restoration or index rebuild.
Travel and hospitality · Illustrative enterprise scenario, not a reported customer outcome.
Illustrative architecture: A traveler changes an earlier meal preference that appears in a profile, itinerary summary, search embedding, and support cache.
Deleting the profile field alone leaves the old preference available to future agents through derived stores.
Update the preference consistently and prevent the superseded fact from reappearing during retrieval or restoration.
A provenance registry links derivatives to the preference source; the serving filter suppresses the old version while lifecycle workers rebuild affected artifacts.
A delayed index job tries to write the old preference again; source-version and suppression checks reject the stale derivative.
Measure correction propagation time, stale-memory retrieval rate, cleanup acknowledgement coverage, and restoration consistency without claiming that one delete call erases every retained copy.
| Decision | Benefit | Cost |
|---|---|---|
| Minimal durable memory | Reduces exposure, staleness, and cleanup work. | Limits personalization and requires users to repeat some context. |
| Provenance-linked derivatives | Makes corrections and deletion more complete. | Adds metadata and dependency-management overhead. |
| Immediate serving suppression | Prevents continued use while cleanup runs. | Storage removal and backup handling still require separate completion tracking. |
Detect: Deletion verification retrieves the suppressed fact from a derivative without a valid source.
Recover: Quarantine the derivative, repair provenance coverage, and rerun cleanup across affected stores.
Detect: Restore validation finds records covered by a newer suppression or expiry registry.
Recover: Apply current lifecycle policy before exposing the restored store to serving traffic.
Retain only purpose-justified items with explicit scope and lifetime.
Maintain derivative lineage and require cleanup acknowledgements.
Document which systems retain information and handle model-data obligations through their separate governed processes.