Deletion Across Agent Memory & Derived Data
What copies remain after the original record is removed?
Reference notes by Min · Reviewed October 15, 2026
Definition
Deletion propagation is the process of carrying an authorized removal decision through relevant copies and derivatives of information. Agent systems need to account for retrieved documents, embeddings, summaries, caches and saved task state rather than deleting only the source record.
Deleting one database row does not necessarily remove information an agent can still recall. A derived summary may preserve the sensitive fact without preserving the original identifier. Designing removal requires understanding both stored copies and the transformations that create them.
What it covers
- Inventory
- Where source and derived information reside.
- Decision
- What must be deleted, restricted or retained.
- Propagation
- How removal reaches dependent stores.
- Evidence
- How completion and unresolved copies are recorded.
Separate deletion from access restriction and retention. Some evidence may need controlled preservation for a legitimate purpose, while active retrieval should stop. Record the basis and owner of that distinction instead of using one indefinite retention rule for every store.
In practice
Practical design patterns by Min.
- Map stores before promising a deletion capability.
- Prevent removed information from being retrieved again.
- Document backup, retention and external-recipient limitations.
Use stable links between sources and derived objects where practical. Test removal with representative synthetic records across retrieval, cache and memory paths. If a store cannot remove individual items, define rebuilding or expiry behavior and disclose the operational delay accurately.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Manage the data lifecycle deliberately
NIST’s Privacy Framework supports organizational privacy-risk management. The store-by-store removal procedure is an editorial engineering application, not a statutory deletion timetable.
Source: NIST: Privacy Framework ↗
Working example
A customer profile is removed
An assistant has used the profile in a retrieval index and a persistent summary.
- Resolve the authorized removal scope.
- Delete or rebuild affected derivatives and invalidate caches.
- Check retrieval behavior and retain only the required minimal completion evidence.
Why the controls matter
The profile example can fail if a background job recreates a summary from an old snapshot. Include ingestion and refresh jobs in the removal workflow. A completion check should examine the paths the agent can actually use, not only the primary database.
Common pitfalls
- Removing a source while its summary remains searchable.
- Calling embeddings anonymous without analysis.
- Claiming complete deletion from a system that cannot locate derived copies.
Model training introduces a different problem from deleting application memory. Do not imply that removing a stored prompt changes model weights. Identify whether data entered training and route that question through the relevant provider and data-governance process.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which derivatives preserve the removed information?
- Can ingestion recreate deleted context?
- What limitations must be communicated to the requester?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- NIST: Privacy Framework ↗Accessed October 15, 2026
- W3C: PROV Overview (2013 Working Group Note) ↗Accessed October 15, 2026