You ask your AI agent what it knows about you. It cannot tell you — not in a format you can read, not in a way you can verify, not in a way you can correct. The agent has been accumulating facts from every conversation: your preferences, your coding habits, your project decisions, maybe your health concerns or financial details. But the memory is a black box — stored in a vector embedding or an opaque agent state block, accessible only through the tool’s API, if at all. You cannot open it in a text editor. You cannot diff it against last week. You cannot delete a single fact and prove it is gone. For a developer, this is a debugging nightmare. For a user, it is a privacy problem. For an enterprise, it is a compliance liability.
The fix is memory that is editable and auditable by design — stored in a format you can read, inspect, correct, and erase. Not all agent memory systems offer this. The distinction is not between open-source and proprietary; it is between open format (human-readable, inspectable) and closed format (opaque, API-only access).
Most agent memory systems store what the agent learns in one of three opaque formats:
Vector embeddings — Text is converted to a high-dimensional vector and stored in a vector database. You cannot read the vector. You can query it (“find memories similar to X”) but you cannot open it and see what the agent knows. Mem0, LangChain memory modules, and many RAG-based systems work this way.
Agent state blocks — The agent’s memory is stored as structured state in a database, managed through the agent’s tool API. Letta (formerly MemGPT) stores core memories and archival memories this way. You can query it through the API, but you cannot open a file and read what the agent knows.
Knowledge graphs — Facts are stored as entity-relationship triples in a graph database. Zep and Graphiti use this approach. More structured than vectors, but still requires graph queries to inspect — not something you can diff in git.
In all three cases, the memory is write-once, read-through-API. You can add memories and search memories, but you cannot:
This is not a limitation of the tools; it is a consequence of the storage format. If the format is opaque, the memory is opaque.
When an agent makes a wrong decision, you need to know what memory it was operating on. Was it a stale fact? A misremembered preference? A correction that was not captured? If the memory is a vector embedding, you cannot inspect it — you can only re-query and hope the retrieval surfaces the same memory. If the memory is a human-readable YAML file, you can open it, read it, find the error, and fix it.
The EU AI Act (Regulation 2024/1689, entered into force August 2024) requires transparency for high-risk AI systems — including the ability to understand and trace the system’s outputs. GDPR Article 17 establishes the right to erasure: a data subject can request deletion of their personal data. If your agent’s memory is a vector embedding, how do you prove erasure? You can delete the vector, but the text it was derived from may exist in backups, logs, or the model’s training data. If the memory is a file, you can delete the file — and prove it with a git diff.
A 2024 survey of LLM-based agent memory mechanisms (Zhang et al., “A Survey on the Memory Mechanism of Large Language Model based Agents,” arXiv:2404.13501) noted that memory transparency and control are emerging concerns: as agents accumulate personal data from interactions, the ability to inspect, correct, and delete that data becomes a requirement, not a nice-to-have.
A user who cannot see what the agent knows cannot trust it. A developer who cannot inspect the memory store cannot debug it. An enterprise that cannot prove erasure cannot deploy it in regulated environments. Transparency is not a feature; it is a prerequisite for adoption at scale.
An editable, auditable memory system has five properties:
Each memory is stored in a format you can read without an API. Plain text, YAML, JSON — something a developer can open in a text editor. The engram format (PLUR, github.com/plur-ai/plur) stores each memory as a YAML entry with an id, statement, type, domain, scope, confidence, provenance, and timestamps. You can open the file and read what the agent knows.
You can list all memories, search them, and view any individual memory. Not through a vector similarity query — through a direct read. You can ask “what does the agent know about my coding preferences?” and get a list of specific, readable entries, not a cosine similarity score.
You can edit a memory in place. If the agent learned that you use Jest but you actually use Vitest, you can open the YAML file, change the statement, and save it. No retraining, no re-embedding, no API call. The next time the agent recalls that memory, it reads the corrected version.
You can delete a single memory and prove it is gone. If the memory is a file, you delete the file and commit the deletion to git — the diff is your proof. If someone asks “did you delete the memory about X?”, you can show the commit. This is not possible with vector embeddings, where deletion leaves no auditable trace.
Because each memory is a file, you can put the entire memory store under version control. You can see what the agent knew last week vs today. You can roll back to a previous state. You can branch and experiment. This is impossible with a vector database or an agent state block.
| Tool | Format | Inspect? | Edit? | Delete? | Prove erasure? |
|---|---|---|---|---|---|
| Mem0 | Vector store | Via API search | Via API update | Via API delete | No (vector may persist in backups) |
| Letta | Agent state blocks | Via API / visualizer | Via API | Via API | No (state blocks in database) |
| Zep / Graphiti | Temporal knowledge graph | Via graph query | Via graph update | Via graph delete | Partial (graph node removal, but temporal history persists) |
| Cognee | Graph + vector + relational | Via API | Via API | Via API | No |
| ChatGPT memory | Proprietary | Via settings UI | Via settings UI | Via settings UI | No (opaque, no audit log) |
| Claude Code (CLAUDE.md) | Markdown file | Yes (read file) | Yes (edit file) | Yes (delete line) | Yes (git diff) |
| PLUR | YAML files (open format) | Yes (read file) | Yes (edit file) | Yes (delete entry) | Yes (git diff) |
The pattern is clear: file-based memory is auditable; database-based memory is not. CLAUDE.md — Claude Code’s built-in persistent instruction file — is the simplest form of editable, auditable memory: a markdown file you write, read, and edit. It is limited to static instructions, not accumulated knowledge. PLUR extends this principle to dynamic, agent-learned memories: each engram is a YAML entry with full provenance, stored in plain local files, editable in any text editor, and version-controllable in git.
When a user asks you to delete what your AI agent knows about them, you need to do three things:
This is why format matters more than license. An Apache-2.0 memory engine that stores memories in opaque vectors is open-source but not open-format. You can read the engine’s source code, but you cannot read your own memories. PLUR’s engram format (Apache-2.0, plur.ai/spec.html) is both: the engine is open-source and the memory format is human-readable YAML. You can read the code AND read the memories.
The Model Context Protocol (specification 2025-11-25) — an open protocol from Anthropic — standardizes how LLM applications connect to external tools. An MCP memory server exposes tools like recall, learn, forget, and feedback that any MCP-compatible agent can call. This means the same memory server works across Claude Code, Hermes, OpenClaw, Cursor, and any other MCP-compatible runtime.
But MCP defines the transport, not the format. Two MCP memory servers can be fully protocol-compatible and store memory in completely different ways — one as a vector embedding, one as a YAML file. If auditability is your requirement, the format is the differentiator, not the protocol.
| If you need… | Start with |
|---|---|
| Zero-setup memory for one agent (Claude Code) | CLAUDE.md + auto memory |
| Structured memory with a simple API, no infra | Mem0 (cloud) |
| Self-managing stateful agent with memory tiers | Letta |
| Time-aware facts with sub-200ms retrieval | Zep |
| Memory you can inspect, correct, version-control, and prove erasure | PLUR (YAML engrams via MCP) |
The underlying question is: what do you need to own? If you need to audit what your agent knows — for debugging, for compliance, for trust — you need memory in a format you can read, edit, and diff. That means files, not vectors. The license is secondary; the format is primary.
Can I see what my AI agent remembers about me? It depends on the tool. ChatGPT shows memories in settings. Claude Code has CLAUDE.md (readable) and auto memory (less transparent). Memory engines like Mem0, Letta, and Zep expose memories through APIs. PLUR stores memories as YAML files you can open in any text editor.
How do I delete a specific memory from my AI agent? Each tool handles this differently. Mem0, Letta, and Zep offer delete APIs. ChatGPT lets you delete memories through the settings UI. PLUR lets you delete the YAML entry directly — and if the memory store is under git, the commit diff is your proof of erasure.
Can I edit what my AI agent remembers without retraining? Yes, if the memory is stored externally in an editable format. Fine-tuning bakes facts into model weights you cannot read or edit. External memory — whether in a vector store, knowledge graph, or YAML file — can be updated without retraining. But only file-based memory (CLAUDE.md, PLUR engrams) lets you edit memories in a text editor without an API call.
Is agent memory subject to GDPR? If the memory contains personal data about an identifiable individual, yes. GDPR Article 17 gives individuals the right to request erasure of their personal data. Agent memory systems that store personal data need a mechanism to find, delete, and prove erasure of that data. File-based memory makes this straightforward; vector-based memory makes it difficult to prove.
What is the difference between open-source and open-format memory? Open-source means the engine’s code is public (e.g., Apache-2.0). Open-format means the memory data itself is in a human-readable, standardized format (e.g., YAML). A project can be open-source but store memories in opaque vector embeddings — you can read the code but not your own memories. PLUR is both: the engine is Apache-2.0 and the memory format is human-readable YAML.