C38 Updated 2026-06-20
Pillar 4 - Troubleshooting

How to Delete or Forget a Specific Memory in an Agent

Delete a specific agent memory by targeting the source artifact, derived artifacts, retrieval paths, and audit record instead of relying on prompt instructions.

To delete a specific agent memory, target the stored source and its derived artifacts, not just the next prompt. Find the delete handle, disable or remove summaries and embeddings, record an audit event, rebuild affected retrieval indexes, and verify the old fact no longer returns in a fresh agent question.

Last updated: June 20, 2026.

Why is “forget this” not enough?

Telling an agent “forget that” can influence the current conversation, but it does not necessarily remove stored artifacts. If the memory exists as a source item, summary, embedding, tag, or retrieval candidate, the next session may retrieve it again.

The GDPR right to erasure is about erasure under qualifying circumstances, not polite model behavior. Even outside GDPR scope, users expect deletion to affect storage and retrieval.

What do you need before deleting?

You need a delete handle. The handle should identify the source artifact and the derived artifacts created from it:

ArtifactWhy it matters
Source document or transcript turnOriginal evidence behind the memory
SummaryMay still expose the deleted fact
EmbeddingMay retrieve the deleted fact by similarity
Tags/entitiesMay route future retrieval toward the fact
Retrieval logsMay need retention policy or redaction
Supersession edgesMay need a replacement rather than deletion

Provable Forgetting explains the broader lifecycle. This post is the operational checklist.

How do you inspect the memory before deleting?

Start with source lineage. Ask:

  • Which source created the memory?
  • Was the memory manually saved or extracted from a transcript?
  • Which derived artifacts exist?
  • Which library and tenant can retrieve it?
  • Was it already superseded?
  • Does the answer cite it directly?

The NIST AI Risk Management Framework is useful as a governance reference because deletion is a risk-control process, not just a UI action.

What is the safe deletion sequence?

Use this order:

  1. Freeze writes for the target memory while deleting.
  2. Mark the source artifact deleted or disabled.
  3. Delete or tombstone derived summaries, embeddings, and tags.
  4. Remove the memory from active retrieval indexes.
  5. Write an audit event with actor, time, source id, and action.
  6. Run negative retrieval checks.
  7. Keep only retention-required logs under policy.

If the fact changed rather than needed removal, supersede it instead. Deleting history when the real need is current-state correction creates audit gaps.

How do you verify it worked?

Run four checks:

CheckExpected result
Direct content lookupDeleted source is unavailable or marked deleted
Full-text searchDeleted phrase does not return as active evidence
Vector or hybrid searchSimilarity search does not return the deleted artifact
Agent answerAgent says it cannot find active source-backed evidence

If any check returns the old fact, inspect the derived artifacts. The bug is often an orphaned summary or embedding.

What if the user wants correction, not deletion?

Deletion is not the right response to every bad memory. If the underlying fact changed, create a current source-backed replacement and mark the old memory superseded. That preserves the audit trail while preventing the old fact from being treated as current evidence.

Use deletion when the memory should no longer be available at all: a user revokes consent, a sensitive artifact was imported by mistake, or a source must be removed from active retrieval. Use supersession when the memory is historical but no longer current.

What should your product expose?

A usable memory product should expose a deletion surface with stable handles, source lineage, affected derived artifacts, and verification status. A button that hides a memory from the UI but leaves its embedding active is not enough.

At minimum, expose:

ControlWhy it matters
Source idTargets the original evidence
Derived artifact countShows what else must be removed
Actor and timestampSupports audit review
Retrieval verificationProves the memory stopped returning
Undo or retention policySeparates accidental deletion from policy erasure

Use the Memory Failure-Mode Catalog for the symptom map, then read Provable Forgetting and RAG leaks docs to wrong users for adjacent lifecycle and permission issues.

Sources

Fig. 9 FAQPage schema / visible answers
FIG. 9

FAQ

How do I delete a specific agent memory?

Find the source artifact and derived memory records, disable or delete them, write an audit event, rebuild affected indexes, and verify the fact no longer retrieves.

Is telling the agent to forget enough?

No. A prompt instruction can change the next answer, but it does not remove stored source artifacts, embeddings, summaries, or retrieval candidates.

What is a delete handle?

A delete handle is the stable id that targets the source and derived artifacts affected by a deletion request.

What should I verify after deletion?

Run a direct lookup, a semantic search, a hybrid search, and a fresh agent question for the deleted fact.

NEXT

Build memory you can inspect.

Answer Engine gives agents a persistent, tenant-isolated memory layer via MCP, with source-aware recall and roadmap-labeled inspection work.