Deleting AI agent memory is a data-flow problem. Clearing a conversation may stop the interface from displaying a fact while a summary, retrieval index or pending job still carries it. Before promising that an agent has forgotten something, identify which copies your application created and which of them can return to a future task.
This reference maps sixteen places to inspect. It does not claim that every product uses all sixteen, or that removing an application record erases information from a trained model. The practical decision is narrower: what must change so your agent stops retrieving, repeating or restoring a particular piece of stored information?
- 01Start with the copies.Map source records, derived representations and operational storage before choosing a deletion action.
- 02Suppression and erasure differ.Blocking retrieval reduces exposure but does not establish physical deletion.
- 03Test reintroduction.A queued job or restored backup can bring back information that disappeared from the live application.
01 — Sixteen places to inspectSixteen places to inspect
Use the locations as an inventory template. Mark each present, absent or unknown for your system, assign an owner and record how completion will be verified. The action column is proposed engineering practice, not a statement about any vendor’s default behavior.
| Layer | Possible copy | Action to verify |
|---|---|---|
| Active context | Current model input | Rebuild the next turn without the item; stop older work that can reuse it. |
| Conversation | Saved messages | Remove the scoped record and check attached tool results. |
| Summary | Compacted history | Regenerate the summary from the permitted history. |
| Notes | Persistent agent notes | Delete or amend facts in the note store. |
| Retrieval | Original documents | Remove the source from the authorized collection. |
| Retrieval | Parsed text chunks | Delete descendants identified by source ID. |
| Retrieval | Vector entries | Remove matching vectors and any payload text. |
| Retrieval | Keyword index | Remove searchable text and stored highlights. |
| Application | Answer cache | Invalidate cached answers derived from the item. |
| Application | Generated artifacts | Find reports, files and exports containing the fact. |
| Application | Worker checkpoints | Invalidate resumable state that carries old context. |
| Application | Pending jobs | Cancel or rebuild queued jobs with copied inputs. |
| Operations | Logs and traces | Apply the retention and access policy to captured payloads. |
| Operations | Replicas | Confirm the change has reached serving copies. |
| Operations | Backups | Track expiry and prevent restoration from reintroducing the record. |
| Operations | External processors | Obtain the provider-specific deletion or retention status. |
02 — Define what forget means in your productDefine what forget means in your product
There are several defensible product promises. A preference can stop influencing new conversations. A document can stop appearing in search. A record can be removed from serving storage. A retained backup can become unavailable to routine application use while it awaits expiry. These outcomes have different tests; a single success flag obscures the distinction.
Anthropic’s context-engineering discussion distinguishes active context from persistent notes and compaction. Its context-management cookbook illustrates persistent external memory alongside changes to the conversation context. The architectural implication is that an application may have more than one place to update. Neither document establishes deletion guarantees for your deployment.
Keep model training outside this inventory unless your application actually sends data into a training process. Editing a retrieval store and unlearning model parameters are different operations. Do not use the language of one to describe the other.
03 — Keep source IDs on derived recordsKeep source IDs on derived records
A useful deletion design begins when data enters the system. Assign the source an identifier and keep that identifier on chunks, summaries and exported artifacts. If a summary combines several records, store its dependencies. Otherwise you may know the source was removed but have no reliable way to find its paraphrases.
Suppose an agent reads an outdated customer instruction and writes it into a project note. Deleting the original attachment leaves the note intact. Searching only for the attachment filename misses the copy because the note contains the meaning rather than the name. Dependency records allow the application to invalidate the note even when the wording changed.
Where a derived record mixes permitted and removed material, regeneration can be more useful than deleting the whole artifact. Rebuild it from the remaining sources, then verify that the removed fact is not carried forward. Treat a failure to rebuild as a visible exception, not as proof that the previous version is acceptable.
Say what was removed from which layer. “Removed from active retrieval; backup retention remains governed by the documented schedule” is more informative than an unsupported promise that every copy is gone.
04 — Database deletion is not the whole lifecycleDatabase deletion is not the whole lifecycle
PostgreSQL’s VACUUM documentation explains that deleted row versions are not immediately physically removed in normal operation. Reclaiming database space is also not a certificate of secure erasure across disks, replicas or backups. This is a reason to distinguish logical removal from storage lifecycle management, not a recommendation to run a maintenance command as a universal deletion remedy.
The SQL dump documentation describes a separately stored representation that can recreate a database. Our design recommendation follows from that: a restoration procedure should reapply later removals before restored data serves agent requests. Keep a minimal record of removed identifiers without retaining the sensitive content you intended to eliminate.
External services require a separate answer. Record the applicable retention commitment and its scope. An application cannot establish a processor’s physical deletion merely because its own API request succeeded. If the status is unknown, keep it unknown in the completion report.
05 — Test both fresh work and resumed workTest both fresh work and resumed work
Use a synthetic fact that is distinctive and non-sensitive. Place it through the same ingestion path as real data, allow the agent to summarize it, and then request removal. Test a fresh conversation, an existing conversation, a pending job and a controlled restore in an isolated environment. Those paths exercise different copies.
Check exact retrieval and paraphrased retrieval. A search that returns no exact string can still return a summary of the fact. Conversely, a model repeating common public knowledge is not evidence that your private record survived. Design the synthetic case so the provenance is interpretable.
The architectural options are covered in our agent memory architecture comparison. Pair the inventory with data-access controls and checkpoint and recovery design so resumed work respects the same removal decision.
This reference separates source-backed definitions from Digital Applied’s proposed checks.
- What was collected
- 16 possible storage locations in 4 groups. The complete selected classification appears above; it is not a census of every implementation.
- As-of date
- September 7, 2026. Publication is assigned to the September 4 batch; collection and review happened on September 7.
- Method
- Trace an input through context, retrieval, application artifacts and operations. Each row names a distinct place an implementation may retain information; presence must be verified locally.
- Sources and units
- Anthropic engineering and cookbook pages establish context and external-memory distinctions. PostgreSQL documents row lifecycle and dumps. The inventory and proposed checks are editorial analysis, measured in locations.
- Exclusions and gaps
- No provider deletion audit, contractual comparison, legal assessment, secure-erasure test or model-unlearning claim. Unknown means the storage owner or behavior has not been verified.
- Limitations
- These are design checks, not test results. Applicability depends on the system. An absent feature is not a failure; record it as not applicable.
06 — DecisionWhat to do next
Make the promise match the layer you can verify.
Inventory the copies before changing the product’s wording. Build removal around source dependencies and test the paths that can reintroduce information. A precise completion report is more useful than a broad claim the architecture cannot support.
For implementation support, explore our AI transformation services.