How to Delete Specific Things an AI Remembers About You
Whether you can delete a specific AI memory depends on two things: which AI you are using and what storage format its memory uses. Consumer AI assistants like ChatGPT and Claude Projects let you delete individual memories through a settings panel — but only report success; they cannot prove the underlying data is gone. Developer-facing agent memory tools (Mem0, Letta, PLUR) offer deletion via API or CLI. The critical difference is the storage format: systems that store memory as plain files — open-format memory — can prove deletion with a file diff. Systems that store memory as vector embeddings or opaque database records cannot. This distinction matters for privacy-sensitive applications, GDPR compliance, and any scenario where a user needs to trust that deletion actually happened.
Deleting memories from consumer AI assistants
ChatGPT (OpenAI)
ChatGPT's memory stores facts you have shared across conversations. To delete a specific memory:
- Open ChatGPT and go to Settings → Personalization → Manage memory (or ask the chat directly: "What do you remember about me?")
- Browse the list of stored memories
- Click the trash icon next to the memory you want to remove, or ask: "Forget that I [specific fact]"
OpenAI's Memory FAQ (help.openai.com/articles/8590148) notes that when you delete a memory, "it is removed and won't be used in future chats." However, deletion through the UI does not guarantee erasure from server backups or audit logs — OpenAI's data retention policies govern what happens at the infrastructure layer.
You can also turn off memory entirely under Settings → Personalization → Memory → Off, which stops ChatGPT from creating new memories without deleting existing ones.
Claude Projects (Anthropic)
Claude Projects store context you add to a project (via the project instructions field) and, in some configurations, persist facts across conversations within that project. To remove stored context:
- Open the project and edit or clear the Project instructions field
- If the platform has stored conversation-derived facts, look for a memory management option in project settings
Claude's in-conversation memory does not persist between separate conversations unless you are using a Claude Projects session with memory enabled. Anthropic's privacy controls are documented at privacy.anthropic.com.
Microsoft Copilot
Copilot's memory settings are documented at support.microsoft.com. You can manage and delete stored memories through the Microsoft 365 privacy dashboard.
Google Gemini
Gemini's memory features vary by product surface. For Gemini Advanced, memory is managed through Gemini Apps Activity in your Google account. You can delete individual memory entries or turn off memory entirely through the Google Account privacy dashboard.
The proof problem: why "deleted" does not always mean gone
With all consumer AI memory systems, the deletion UI removes the memory from the active recall surface. What it cannot guarantee:
- The vector embedding derived from that memory is removed from all backup stores
- The source text is not retained in server logs for safety or audit purposes
- The memory is not retained in a training dataset snapshot
This is not a failure of these products — it reflects the tension between privacy controls and operational requirements (backups, safety monitoring, legal holds). For most users, UI deletion is sufficient. For regulated industries or GDPR-sensitive deployments, the inability to prove erasure is a compliance problem.
Deleting memories in developer agent systems
If you are building agents — coding assistants, research agents, autonomous workflows — memory deletion is your responsibility, not the AI provider's. Your agent accumulates facts about users across sessions; when a user asks to delete specific data, you need to:
- Find all memories related to that user
- Delete them
- Prove they are gone
How well you can do each step depends on the memory system you chose.
Memory systems and deletion capability
| System | Format | Find specific memory | Delete specific memory | Prove erasure |
|---|---|---|---|---|
| Mem0 | Vector store | Via API similarity search — may miss entries with low similarity | Via mem0.delete(memory_id)
|
No — vector may persist in backups |
| Letta | Agent state blocks | Via API / Letta Studio UI | Via API DELETE /v1/agents/{id}/memory
|
No — database record may persist |
| Zep / Graphiti | Temporal knowledge graph | Via graph query | Via graph node deletion | Partial — temporal history chain remains |
| PLUR | YAML files (open format) |
plur recall <query> or grep in ~/.plur/
|
plur forget <engram-id> — retires the engram (excludes from recall; physical removal requires manual YAML edit) |
Yes — git diff shows status change or entry removal |
The key variable is storage format. File-based memory can be grepped, diffed, and deleted with proof. Database-backed or vector-backed memory cannot.
Implementing deletion in PLUR
PLUR stores each memory (engram) as a structured YAML entry in a local file store (~/.plur/ by default). Deletion is explicit:
# List what the agent knows about a topic
plur recall "user preferences"
# View a specific engram
plur show ENG-2026-0512-042
# Delete it
plur forget ENG-2026-0512-042
# Confirm it is gone
plur recall "user preferences" # should not surface the deleted engram
Because the store is a local directory (and optionally a git repository), retirement leaves a verifiable trace: the engram's status field changes from active to retired in the YAML, and git log shows exactly when it happened and the reason provided. For complete physical erasure, you can delete the retired entry from the YAML file and commit — the diff then shows the entry is gone entirely. This is the closest you can get to provable erasure in an agent memory system without a separate audit log.
PLUR's explicit retirement design — nothing is auto-deleted; only plur forget can retire an engram — is the same property that makes it trustworthy from a compliance perspective. You can be confident that if you did not call plur forget, the memory is still active and retrievable.
GDPR and the right to erasure
GDPR Article 17 ("right to erasure," also called the right to be forgotten) requires that a data controller delete personal data when the data subject requests it, when the data is no longer necessary for its original purpose, or when consent is withdrawn.
For developers building AI agents that process EU user data, this creates a concrete requirement: when a user requests deletion, you must be able to:
- Identify all personal data stored about that user (name, email, preferences, conversation history, derived facts)
- Delete it
- Demonstrate that deletion occurred (for potential regulatory review)
Agent memory is personal data under GDPR if it contains information that can identify an individual. Vector embeddings of personal information are still personal data even though they are not human-readable (the WP29 and EDPB have consistently taken this position).
The compliance gap with most agent memory systems is step 3: demonstrating deletion. File-based, open-format memory makes this tractable; vector or graph-based memory makes it difficult.
The EU AI Act (Regulation 2024/1689, in force August 2024) adds additional transparency requirements for high-risk AI systems, including the ability to trace system outputs and understand the data informing decisions. Agent memory that cannot be inspected or audited may create additional exposure under the Act.
Note: this is not legal advice. Consult a qualified privacy lawyer before making compliance decisions.
For developers: a checklist for deletion-ready agent memory
- [ ] Can you list all memories associated with a specific user ID?
- [ ] Can you delete a specific memory by ID (not just by query similarity)?
- [ ] Can you prove that deletion occurred (file diff, audit log, database record timestamp)?
- [ ] Is the memory store backed up, and does your deletion propagate to backups (or does your backup policy exclude deleted records after N days)?
- [ ] If a user exercises GDPR Article 17 rights, can you produce a deletion record?
- [ ] Is the source text of memories (the raw conversation turns) stored separately, and do you have a deletion path for that too?
FAQ
Can I make ChatGPT permanently forget something?
You can delete a specific memory from ChatGPT's active recall using the Settings → Personalization → Manage memory panel. This removes the memory from future conversations. ChatGPT's server-side data retention policies govern whether the underlying data is retained in backups or logs — consult OpenAI's Privacy Policy for details.
Which agent memory tools let me inspect and delete what the AI remembers?
All major agent memory tools (Mem0, Letta, Zep, PLUR) provide deletion APIs. The practical difference is inspectability and proof of deletion. PLUR stores memory as local YAML files — you can open, read, grep, edit, and delete entries directly without an API, and a git diff serves as a deletion record. Vector-based stores (Mem0, some Zep configurations) are harder to inspect and cannot prove erasure.
Is AI agent memory GDPR compliant?
It depends on the architecture. Agent memory that stores personal data about EU residents is subject to GDPR, including the right to erasure (Article 17). Open-format, file-based memory systems make erasure easier to implement and demonstrate. Vector embedding stores are technically GDPR-covered personal data but harder to fully erase. This is an active area of regulatory attention as agent systems scale.
How do I implement the right to be forgotten in an AI agent?
The implementation steps: (1) tag every memory with the user ID it was derived from at creation time, (2) provide a deletion path that removes all memories with that user ID, (3) generate an audit record of the deletion. File-based memory systems (PLUR) make all three steps straightforward. For vector-based systems, step 3 typically requires a separate audit log, since the vector store itself does not record deletions.
What is the difference between deleting a memory and turning off memory entirely?
Turning off memory stops the agent from creating new memories but does not delete existing ones. Deleting a specific memory removes that individual entry but leaves other memories intact. Turning off memory and deleting all existing memories are separate operations in most systems.
Sources
- OpenAI Memory FAQ: help.openai.com/articles/8590148
- GDPR Article 17 (right to erasure): gdpr-info.eu/art-17-gdpr
- EU AI Act (Regulation 2024/1689): eur-lex.europa.eu
- "A Survey on the Memory Mechanism of Large Language Model based Agents" (Zhang et al., 2024): arxiv.org/abs/2404.13501
- PLUR open-format engram memory: github.com/plur-ai/plur
- Microsoft Copilot memory management: support.microsoft.com/en-us/microsoft-365-copilot/manage-copilot-memory-in-microsoft-365-copilot
Top comments (0)