Provable forgetting is the ability to show that an agent memory, its source artifact, and its derived summaries or embeddings were removed, disabled, or superseded. It matters because memory products turn user data into reusable context, so deletion has to be traceable instead of aspirational.
What is provable forgetting?
Provable forgetting means a product can answer “what happened after this deletion request?” with evidence. At minimum, the system should identify the target memory, the source object that created it, the derived artifacts that were produced from it, and the status after the request.
That does not mean every product can honestly claim cryptographic erasure on day one. It means the product has a deletion model and an audit trail. Stronger proof, such as crypto-shredding derived data with tenant-scoped keys, should stay roadmap-labeled until it is implemented and tested.
The term is important because ordinary chat deletion is not enough. An agent memory system may have source rows, summaries, embeddings, cache entries, retrieval logs, and answer citations. Forgetting one screen while leaving derived context retrievable is not enough.
Why does regulation make forgetting urgent?
GDPR Article 17 gives data subjects the right to have personal data erased in qualifying circumstances (GDPR Article 17). The details depend on data type, controller role, exemptions, and jurisdiction, so this article is not legal advice. The product lesson is simpler: if personal data enters memory, deletion must be part of the architecture.
The EU AI Act also raises expectations for traceability. Article 12 covers automatic logging capabilities for high-risk AI systems, and Article 26 includes obligations for deployers around keeping logs where the logs are under their control (Regulation (EU) 2024/1689). The Act’s main application date is August 2, 2026, with staged obligations before and after that date. For a memory product, the practical point is that auditability is no longer a nice-to-have.
What are the five forgetting primitives?
Forgetting is not one operation. Use distinct primitives:
| Primitive | What it does | Example |
|---|---|---|
| Supersede | Marks an old fact as replaced by a newer fact while keeping history. | Old pricing page replaced by new pricing page. |
| Decay | Lowers retrieval priority over time without deleting. | A weak preference becomes less relevant after inactivity. |
| Amnesia | Removes conversational carryover for a thread or user context. | Forget the temporary debugging plan from yesterday. |
| Purge | Deletes or disables a source and its derived artifacts. | Remove a customer transcript and related embeddings. |
| Drift | Flags a memory as suspect because the source changed without a clean replacement. | A policy page changed but no successor was linked. |
ForgetEval uses a similar vocabulary to evaluate forgetting behaviors in LLM agents, including supersession, decay, amnesia, purge, and drift (ForgetEval). You do not need to publish a benchmark to use the vocabulary. You do need to avoid calling purge and supersession the same thing.
What should a deletion audit trail contain?
A deletion audit trail should include:
- Request ID and actor.
- Tenant, workspace, user, and source scope.
- Target memory or source artifact.
- Derived artifacts: summary, embedding, tags, extracted entities, and citations.
- Action taken: superseded, disabled, deleted, or scheduled.
- Time of action.
- Verification query or tombstone state.
- Exceptions or retained records required by policy.
The important part is specificity. “We delete your data” is not enough. A memory product should know which derived objects existed because of a source and what happened to each one.
How is forgetting different from unlearning?
Machine unlearning usually refers to removing information from trained model parameters. Agent memory forgetting usually refers to removing information from an external memory layer: source artifacts, embeddings, summaries, retrieval state, and logs.
Those are different problems. Research surveys describe machine unlearning for large language models as a difficult and still-developing area (machine unlearning survey). Product teams should not imply that deleting external memory rewrites a foundation model. They should say exactly what memory layer they control and what deletion affects.
This is why external memory can be more accountable than implicit model memory. If the product stores source-linked memories outside the model, it can give users more direct lifecycle controls.
Can embeddings be forgotten?
Embeddings can be deleted as rows or index entries when the product owns the vector store. The harder question is whether every derived artifact and cache path is covered. A credible memory system needs to key derived artifacts back to source objects so deletion has a target.
For launch copy, be precise:
- Safe: “Deletion requests target the source artifact and derived memory artifacts we control.”
- Safe: “Stronger cryptographic erasure proof is roadmap-labeled until tested.”
- Unsafe: “The model forgets everything instantly.”
- Unsafe: “We can prove every downstream system forgot” without a testable design.
How should teams design for provable forgetting?
Design for forgetting before the first import:
- Give each source artifact a durable ID.
- Store derived summaries, tags, and embeddings with that source ID.
- Keep retrieval logs scoped and queryable.
- Use tombstones or status fields so old references stop serving.
- Make deletion idempotent so retrying a request does not create inconsistent state.
- Report what was deleted, disabled, retained, or scheduled.
- Test that a deleted target no longer appears in retrieval.
This is not only compliance plumbing. It is a trust feature. The ability to prove an agent forgot a sensitive fact may matter more to a technical buyer than another decorative dashboard.
Where does Answer Engine fit?
Answer Engine should frame forgetting honestly: tenant isolation, source-aware memory, and deletion pathways are part of the product promise; stronger crypto-shred proof remains roadmap until it is implemented and verified. That honesty is better than overclaiming.
The product story is simple: if your agent can remember across tools, it must also have a memory lifecycle. Remember, inspect, supersede, and forget are one system.