DEV Community: gregor

Is There an Open Standard for AI Agent Memory Engrams?

gregor — Tue, 28 Jul 2026 11:49:11 +0000

Is There an Open Standard for AI Agent Memory Engrams?

For procedural memory — what an agent knows how to do — there is already a working open standard: the SKILL.md format from agentskills.io, adopted by Claude Code, Cursor, GitHub Copilot, and a growing number of runtimes. For semantic and episodic memory — what an agent has learned about you, your preferences, your decisions — there is no universally adopted standard yet. The leading open proposal is the Engram Specification (plur.ai/spec.html, Apache-2.0): a YAML-based format that encodes a discrete fact with type, domain, confidence score, and provenance in a human-readable file you can inspect, edit, and carry between systems. Whether that proposal becomes a standard depends on how many runtimes adopt it. As of mid-2026, the field is converging on engrams as the unit of agent memory — the format is still contested.

The problem standardization is meant to solve

Every production AI agent faces the same memory problem: the model forgets between sessions, the context window runs out, and learned knowledge — corrections made, preferences stated, decisions taken — vanishes. The fix is persistent external memory. But persistent where, and in whose format?

Today, the answer is: whichever tool you happen to be using. Mem0 stores memories in its own schema. Letta has its own format. Your Claude Code installation builds its own CLAUDE.md context files. None of these formats talk to each other. When you switch tools, your memory does not transfer. When you want to audit what your agent knows about you, there is no file to open — or if there is, its structure is proprietary to the vendor.

This fragmentation is the same problem that HTTP solved for web pages, and that MIME types solved for file formats: without a shared standard, every sender and receiver must negotiate a private protocol. At sufficient scale, the cost of that negotiation exceeds the cost of any individual implementation.

An open standard for agent memory engrams would provide:

Interoperability — memories created in one runtime load correctly in another
Auditability — a single known format lets users inspect and verify what agents have learned
Portability — memory travels with the user, not with the vendor
Compliance — a typed, identified format makes individual facts selectable for deletion (GDPR Article 17, right to erasure)
Ecosystem — standardized engrams can be packaged, distributed, and traded as packs, the way npm packages are distributed for code

What a standard would need to define

An engram standard is not just a file format. It needs to answer at least four questions:

What is the atomic unit? The field is converging on the following minimal structure: a unique identifier, a human-readable statement of the fact, a type classification (behavioral, procedural, architectural, terminological), a scope that defines which agents or users the fact applies to, a confidence score that decays over time as the fact ages, and a provenance record (when it was learned, from what source). Anything less and the format cannot distinguish facts that should be universal from facts that are agent-specific, or distinguish high-confidence assertions from tentative observations.

How does confidence decay? Facts age. A best practice from 2023 may be superseded in 2025. A user preference stated once may later be reversed. A standard without a decay mechanism will accumulate stale knowledge and inject it into agent context indefinitely. The format needs to encode either an explicit decay schedule or a last-verified timestamp that runtimes can use to compute relevance.

How does scope work? Some facts apply globally (a coding convention used across all projects), some apply per-project, some per-agent, some per-user. A standard without a scope field collapses all of these into a single flat namespace, making it impossible to share select facts across runtimes without sharing all facts. The PLUR spec addresses this with a scope field (global, project:<name>, agent:<name>) and a domain field for topic routing.

What is the retrieval contract? A stored engram that cannot be found at recall time is useless. A standard should define, at minimum, what metadata fields must support keyword search, and what response shape a compliant runtime must return. The PLUR spec currently specifies BM25 keyword recall and hybrid BM25+embedding search as the retrieval interface, with a structured JSON response that includes the engram, its retrieval strength, and its session injection rank.

What exists today

Procedural memory: agentskills.io (standardized)

For procedural knowledge — step-by-step instructions for how to perform a task — the SKILL.md format from agentskills.io is the de-facto standard. A SKILL.md file uses YAML frontmatter (name, description, trigger conditions, tags) followed by a markdown body containing the procedure. The format is human-authored, human-readable, and stored as a flat file in the project repository. Claude Code uses it as its primary skill extension mechanism. Cursor, GitHub Copilot, and over a dozen other tools have adopted the same convention. There is no formal RFC or standards body — the standard is defined by convergence and adoption, not a specification committee.

Procedural memory is the simpler case: the format is natural language instructions. The hard case is semantic and episodic memory: the specific facts, corrections, and preferences an agent accumulates at runtime, in response to user behavior rather than human authoring.

Semantic and episodic memory: no adopted standard yet

For the category of knowledge that agents accumulate through use — what the user corrected, what the user prefers, what was decided in a previous session — there is no adopted standard as of July 2026. The gap is widely recognized. The term "engram" (borrowed from Semon, 1904, via recent AI memory research) is spreading rapidly on GitHub as a label for this category. A search for "engram" repositories returns dozens of nascent projects, most independent of each other, each defining their own format.

The most complete open proposal in this space is the Engram Specification published by PLUR (plur.ai/spec.html). It defines:

Typed engrams with type field: behavioral, procedural, architectural, terminological
Domain tagging for topic routing (e.g., infrastructure.deployment, conventions.naming)
Scope system (global, project:<name>, agent:<name>) for cross-runtime selectivity
Confidence scoring (0.0–1.0) with documented decay mechanism
Provenance (source session, creation date, last-verified date)
Pack format — bundles of related engrams that can be published to a registry, installed by others, and version-controlled independently of the runtime

The spec is published under Apache-2.0. The reference implementation (github.com/plur-ai/plur) is also Apache-2.0, with ~226 stars as of July 2026.

PLUR is not the only structured approach. Mem0 stores memories with entity extraction and graph-based linking (their format is documented in the Mem0 API, but not published as a standalone open spec). Letta (formerly MemGPT) has a well-defined memory architecture with core memory, archival memory, and recall storage — again documented in their API, not as a portable format. Both are strong implementations; neither publishes a format spec designed for adoption outside their own runtime.

The Model Context Protocol gap

MCP (Model Context Protocol, Anthropic, 2024) defines an open standard for tool access — how an AI model calls external functions, reads files, queries databases. It does not define a standard for memory storage. A model can use MCP to call a memory server, but what that server stores and how it indexes it is outside the MCP scope. Standardizing engram format is the memory-layer equivalent of what MCP did for tool access.

Why this matters for developers

If you are building an agent today, you are making a de-facto format choice that will be hard to change later. Choosing a proprietary-hosted memory backend means your users' accumulated knowledge belongs to the backend, not to you or them. Choosing an open format — even an early-stage one — means the knowledge can travel: to a different model, to a different runtime, to the user's own machine.

The practical question is not "which standard is official" — there is no official standard yet. The practical question is: which format has the properties a standard needs, and which runtimes have adopted it? SKILL.md answers that for procedural memory. For semantic and episodic memory, the PLUR Engram Specification is the most complete open proposal in the field. Whether the wider ecosystem converges on it, or on something else, depends on adoption over the next 12–24 months.

The open-source community's track record on format convergence suggests it will happen — it always does. The question is whether the format that wins is designed for human readability, portability, and compliance from the start, or whether it is reverse-engineered from a proprietary implementation after the fact.

FAQ

Q: Is there an official RFC or ISO standard for AI agent memory engrams?
No. As of mid-2026, no standards body has published a formal specification for AI agent memory engrams. The field is converging at the project level, not the committee level.

Q: What is the PLUR Engram Specification?
An open (Apache-2.0) format specification for encoding discrete facts learned by AI agents. It defines the fields, types, scope system, confidence scoring, and pack format. Published at plur.ai/spec.html.

Q: Is the SKILL.md format a standard for agent memory?
SKILL.md (agentskills.io) is a de-facto standard for procedural memory — step-by-step instructions. It is not a format for the semantic and episodic facts agents accumulate from user interactions. Those are the domain of engram formats like the PLUR spec.

Q: Can I use PLUR engrams with any LLM?
Yes. PLUR engrams are stored as plain YAML files and injected into the LLM context window via an MCP server. The format is model-agnostic: the same engram file works with Claude, GPT-4, Gemini, Llama, or any model that supports MCP or context injection.

Q: What happens if no standard wins?
Without convergence, the cost is borne by developers and users: knowledge locked into vendor formats, no portability, compliance pain, duplicate effort across every runtime. The same outcome as the pre-HTTP web — functional for early adopters who commit to a single stack, costly for everyone else.

Sources: Semon, R. (1904). Die Mneme. PLUR Engram Specification: plur.ai/spec.html. agentskills.io SKILL.md format: agentskills.io. MCP (Model Context Protocol): modelcontextprotocol.io. Zhang et al. (2024): arXiv:2404.13501. Mem0: mem0.ai. Letta: letta.com.

Mem0 vs PLUR: Which AI Agent Memory Layer Should You Use?

gregor — Mon, 27 Jul 2026 14:56:43 +0000

Mem0 vs PLUR: Which AI Agent Memory Layer Should You Use?

Mem0 and PLUR are both open-source AI agent memory layers, but they make opposite architectural bets. Mem0 is a managed memory API: you call client.add(message, user_id=user_id) and Mem0 extracts, stores, and retrieves relevant facts, with a hosted cloud option and a self-hosted alternative. PLUR is a local-first MCP server: it stores memories as open-format engrams in ~/.plur/ on your device, and any MCP-compatible tool — Claude Code, Cursor, Hermes, OpenClaw — reads and writes the same store without SDK integration. Mem0 suits agent products where you need to manage memories for many users in the cloud. PLUR suits developers who want a single persistent memory that follows them across every AI tool they use, stays on their device, and costs nothing per query.

How each one works

Mem0

Mem0 is a memory API with a Python and JavaScript SDK. You call memory.add() with a message (or list of messages) and a user_id. Mem0 runs an extraction pass with an LLM to identify facts worth keeping, stores them in a vector database, and deduplicates or updates contradicting facts automatically. When you call memory.search(query, user_id=user_id), it returns the most semantically relevant memories for that user.

The managed version (mem0.ai) handles the infrastructure. The self-hosted version (mem0ai/mem0 on GitHub, Apache-2.0) runs with a local vector store (Qdrant by default) and your own LLM API key. Mem0 also ships an optional knowledge graph layer (using Neo4j) for relational memory.

Integration: import the SDK, instantiate a client, call .add() and .search() at the right places in your agent code. Works with any stack that can import a Python or JS package.

PLUR

PLUR is an MCP (Model Context Protocol) server that exposes memory tools to any compatible AI tool. You run npx @plur-ai/mcp init once; PLUR registers itself with your MCP-compatible tools (Claude Code, Cursor, Hermes, OpenClaw, etc.) and creates a local engram store at ~/.plur/. From then on, any session can call plur_learn to store a fact and plur_recall to retrieve one — without any SDK import in your application code.

Engrams are stored as structured YAML in the local directory (~/.plur/engrams.yaml), readable with any text editor or scripted with standard shell tools. PLUR uses hybrid retrieval: BM25 keyword search ranked with reciprocal rank fusion (RRF) alongside semantic embeddings. Confidence scores decay when facts go unused or are contradicted. The format is open and portable — you can inspect, edit, or export the store without any PLUR-specific tooling.

Key differences

	Mem0	PLUR
Default storage	Cloud managed or self-hosted Qdrant	Local directory (`~/.plur/`)
Integration model	SDK — import and call `.add()` / `.search()`	MCP server — tools pick up via MCP config
Works with any MCP tool out of the box	No	Yes
Memory format	Vectors in DB (not directly inspectable)	Open YAML engrams (text-editor readable)
Multi-user (user_id)	Yes — built-in per-user isolation	No — single-user local store
Confidence decay / forgetting	Automatic dedup and contradiction resolution	Explicit confidence decay over time
Self-hosted option	Yes (Apache-2.0)	Yes (Apache-2.0, local by default)
Pricing (cloud)	Free tier + pay per operation	Free (local); no cloud managed offering
Cross-tool portability	Requires SDK in each tool	Any MCP tool shares the same store
Privacy (data leaves device)	Yes (cloud version)	No (local by default)

When Mem0 fits better

You are building a multi-user agent product. Mem0 has native user_id isolation — each user's memories are stored separately and retrieved per-user. If you are building a product where hundreds of users each need their own memory, Mem0's managed service handles this cleanly. PLUR is single-user and local — not designed for serving many users from a shared server.

You want managed infrastructure without self-hosting. The mem0.ai managed service handles scaling, backups, and deduplication. PLUR requires you to manage the local directory or run your own backup; there is no hosted offering.

You need deep SDK integration. Mem0 is a library — you call it at specific points in your agent logic, control exactly what gets stored, and can build fine-grained extraction pipelines. PLUR is tool-level, not code-level — it integrates into AI tool sessions, not into application code directly.

You want a graph layer. Mem0's optional Neo4j integration stores relational knowledge alongside vector memory — useful for entities with relationships (users, organizations, projects). PLUR stores flat engrams without a native graph layer.

When PLUR fits better

You use multiple AI tools and want shared memory. If you work across Claude Code, Cursor, and Hermes in the same day, PLUR's single ~/.plur/ directory means all three sessions read and write the same memory store — no duplication, no sync required. With Mem0, you would need to integrate the SDK into each tool separately.

You want your memory to stay on your device. PLUR is local-first by design: nothing leaves your machine unless you configure sync. Mem0's cloud tier sends memories to managed infrastructure. For sensitive contexts (proprietary code, personal health data, legal work), local-first matters.

You want inspectable, portable memory. PLUR engrams are JSON files in a directory. ls ~/.plur/, grep -r "postgres" ~/.plur/, cat ~/.plur/store/global.jsonl — standard shell tools work. You can audit, edit, back up, or migrate without any PLUR-specific API. Mem0's vector DB is not directly human-readable.

You want to avoid per-query costs. PLUR's local retrieval is free — no API call for each recall. Mem0 cloud charges per memory operation. At high recall volumes (agent loops running hundreds of queries per day), this difference adds up.

You are a developer using MCP-compatible tools. If you already use Claude Code or Cursor with MCP, npx @plur-ai/mcp init is the only integration step. PLUR appears as a tool in your session without any application-level code change.

Can you use both?

Yes, and the combination makes sense in some architectures. Use PLUR for developer-facing memory (your own context, preferences, and agent-learned facts, shared across your tools). Use Mem0 for user-facing memory (your product's end-user personalization, per-user isolation, cloud-managed). The two stores serve different retrieval paths and do not conflict.

FAQ

What are the best open-source alternatives to Mem0?
The closest functional alternatives are Zep (temporal knowledge graph, Apache-2.0), Letta (stateful agent OS with tiered memory, open-source), and PLUR (local-first MCP memory, Apache-2.0). Zep competes most directly on the infrastructure side; PLUR competes on the local-first and cross-tool portability side.

Which agent-memory tools let me inspect and delete what the AI remembers?
PLUR stores memories as open YAML engrams — run cat ~/.plur/engrams.yaml to see everything. Run plur_forget via any MCP session to delete a specific engram. Mem0 provides an API for listing and deleting memories by user_id. Both let you programmatically inspect and delete; PLUR does so without any API call.

Is there an open-source Mem0 alternative that keeps data local?
Yes — PLUR (Apache-2.0). It stores engrams in ~/.plur/ by default, with no network calls for local retrieval. Zep can also be self-hosted, but defaults to cloud. Mem0 self-hosted requires running Qdrant locally.

Mem0 vs PLUR: which has better retrieval?
Different tradeoffs. Mem0 uses LLM-based extraction (deciding what to remember) plus vector search (deciding what to surface). PLUR uses hybrid BM25 + embedding search with RRF ranking and confidence decay over time. Mem0's extraction pass adds latency at write time but can normalize and deduplicate facts. PLUR's retrieval runs entirely locally with no LLM call.

Mem0 vs Letta vs Zep: Which AI Agent Memory Layer? — broader comparison across the open-source memory landscape
Model-Native vs Agent Memory Layer: What's the Difference? — explains the architecture distinction that shapes when each tool fits
Top 10 Open-Source AI Memory Tools in 2026 — full landscape survey including Mem0 and PLUR

Sources

Mem0 documentation — mem0.ai
mem0ai/mem0 GitHub — Apache-2.0 source
PLUR open-format engram memory — GitHub
AI Agent Memory Frameworks in 2026 — Graphlit Blog
Survey of AI memory tools 2026 — Fountain City

What Memory Layer Works with Cursor or Codex?

gregor — Sun, 26 Jul 2026 11:06:35 +0000

What Memory Layer Works with Cursor or Codex?

Cursor and Codex forget everything when a session ends. The correction you gave your agent last Tuesday — "always use pnpm in this repo, never npm" — is gone by Wednesday. The architectural decision you explained across six sessions exists nowhere the agent can access. For Cursor, the fix is a single JSON entry that installs PLUR as an MCP server; within one session, your agent is learning and recalling. For Codex CLI, the integration path depends on your version and setup.

Why "context window" is not the same as "memory"

Cursor and Codex both maintain context within a session — recently viewed files, your current conversation, the code you're editing. That context clears when the session ends or the window fills. A memory layer is something different: it extracts the facts that matter (corrections, preferences, conventions, decisions), stores them durably, and retrieves them at the start of the next session with relevance ranking. You do not re-explain; the agent already knows.

Cursor: three-minute setup via MCP

Cursor supports the Model Context Protocol for extending its AI assistant with custom tools and context. PLUR ships an MCP server that runs as a local process, so your memory store stays on disk with no cloud account and no API cost for retrieval.

Step 1: Add PLUR to your Cursor MCP config

Open or create .cursor/mcp.json in your home directory (or the project root for project-scoped memory):

{
  "mcpServers": {
    "plur": { "command": "npx", "args": ["-y", "@plur-ai/mcp"] }
  }
}

Restart Cursor. The PLUR MCP server is now active.

Step 2 (optional but recommended): Install Cursor hooks

For automatic injection at session start and automatic capture after each tool call, install PLUR's Cursor hook integration:

npx @plur-ai/cli init --cursor

This writes to .cursor/hooks.json — the same hooks mechanism Cursor uses for other session lifecycle events. With hooks installed, you do not need to call plur_session_start manually; memory is injected before your agent says a word.

Step 3: Verify

Open a new Cursor session and ask your agent: "What do you remember about this project?" It will call plur_recall_hybrid and return any relevant memories. On a fresh install that list is empty — it populates as you work.

What happens automatically

Once set up, three things happen without any action from you:

Session start — Relevant memories are injected into context before the first response. If you previously told your agent "always write async/await, never callbacks in this codebase," that preference is present immediately.

During the session — Corrections you give the agent ("actually, use X not Y") are captured automatically as engrams. High-confidence learnings are stored without you saying "remember this."

Between sessions — Memories decay if they stop being useful (the agent stops retrieving them) and strengthen when they keep proving accurate. The memory list self-organizes toward what actually matters for your work.

What Cursor's built-in features already handle

Cursor has its own context mechanisms — conversation history within a session, indexed codebase context, recently viewed files. These are not memory in the durable sense: they do not survive session resets, and they do not travel to other tools. PLUR adds the layer above that: knowledge that survives resets, transfers to other MCP-compatible agents (Claude Code, Windsurf, Hermes), and is portable to a new machine via git sync.

Codex CLI: what's supported

OpenAI's Codex CLI is a terminal-based coding agent that natively supports MCP servers via stdio and Streamable HTTP transports. To add PLUR, run:

codex mcp add plur -- npx -y @plur-ai/mcp

Verify with codex mcp list. Codex will negotiate tools with the PLUR server on each invocation and gain the full tool set (plur_session_start, plur_learn, plur_recall_hybrid, etc.).

If you prefer a Python-native path (e.g. wrapping Codex CLI via the OpenAI Agents SDK), PLUR also ships a Python SDK:

pip install plur-ai

For most Codex CLI users, the codex mcp add path is the lowest-friction option. The Python SDK is for embedding PLUR into custom agent loops, not for the Codex CLI directly.

The memory store is shared across tools

One benefit of a memory layer that sits outside any single tool: the engrams Cursor captures are available in Claude Code, Windsurf, Hermes, and any other MCP client that points at the same store. The architectural decisions you teach Cursor carry to the terminal agent you run at night. This is the practical difference between in-tool memory (session-scoped, tool-scoped) and an open-format engram layer (portable, durable, multi-agent).

PLUR's engram format is an open specification — the data is plain YAML at ~/.plur/, not locked to any service. You can inspect, edit, and export every stored memory.

Sync across machines

If you work across machines or share memory with a team:

plur_sync({ remote: "git@github.com:you/plur-memory.git" })

Memory syncs via git. On another machine, point Cursor at the same store, run plur_sync(), and you pull all memories from the remote. No cloud service required.

Frequently asked questions

Does this slow down Cursor?
No. The PLUR MCP server is a lightweight local process (Node.js). Retrieval is BM25 + local embeddings — no API calls, no network latency. Injection happens once at session start, before your agent responds, and typically takes under a second.

Where is my memory stored?
~/.plur/ — plain YAML files on your disk. You own the data.

Does PLUR replace Cursor's built-in AI memory?
No. Cursor's context mechanisms (conversation history, codebase indexing) continue to work as before. PLUR adds the durable layer above them: facts that survive the session boundary, cross-tool portability, and a feedback loop that trains which memories surface most reliably.

What if I correct the agent and it captures the wrong thing?
Call plur_forget with the engram ID, or open ~/.plur/ and delete the YAML entry. The history is preserved but the engram is retired and no longer injected.

Is Windsurf supported?
Yes — same pattern as Cursor. Add npx -y @plur-ai/mcp to Windsurf's MCP config.

How to Choose a Memory System for Autonomous AI Agents

gregor — Sat, 25 Jul 2026 08:06:27 +0000

How to Choose a Memory System for Autonomous AI Agents

For autonomous AI agents — batch pipelines, overnight research loops, multi-step task runners — three external memory tools cover most production use cases: PLUR for cross-tool portability and full auditability (open file format, no managed infrastructure, MCP-native), Mem0 for hosted semantic-search memory (user preference, interaction history), and Letta for teams who want an opinionated end-to-end agent stack. Model-native memory (ChatGPT saved memories, Claude Projects) does not work for autonomous agents — it requires a human in the loop and cannot be written to programmatically.

Why model-native memory does not work for autonomous agents

ChatGPT saved memories, Claude Projects, and Gemini's workspace memory are built for an interactive use case: a human in a chat interface tells the model something, and the model remembers it for the next conversation. They are not built for autonomous invocation.

Autonomous agents typically run without a user in the loop: a cron job fires at 02:00, an orchestrator spawns 12 parallel sub-agents, a CI pipeline calls an agent after a code commit. In these scenarios, model-native memory has two hard constraints:

No programmatic write. Your orchestration code cannot store a fact directly into ChatGPT memory or Claude Projects. Only the user and the model, inside their respective interfaces, can update those stores. An overnight agent has no interface.

No cross-tool access. If you run your autonomous agent using Claude Code one week and switch to a custom CLI the next, Claude Projects memory does not follow. Each model provider's memory is siloed inside that provider's interface.

For autonomous agents, you need a memory store your code owns — one your agent can read at startup, write during a run, and query between runs, regardless of which model or tool is doing the work.

Source: How to Build AI Agent Memory in 2026

The three memory requirements for autonomous agents

1. Crash-safe persistence

Autonomous agents run without supervision. A run that fails halfway through should not lose the work done up to the failure. This means the memory store must be durable — written to disk or a database on every update, not just at the end of a successful run. In-memory caches and context-window state fail this requirement.

2. Cross-session continuity

The value of an autonomous agent compounds across runs: facts learned on Monday improve Tuesday's results. This requires the memory store to persist between invocations — not just within a single session context window, but across separately launched processes. File-based stores (~/.plur/, SQLite) and hosted vector databases (Mem0, Zep) both satisfy this; pure in-context memory (stuffing past outputs into the prompt) does not scale past a few runs.

3. Programmatic read/write at runtime

The agent's code — not a human, not the model's own conversational output — must be able to write facts to the store and query them on demand. APIs like plur_learn, mem0.add, and zep.add satisfy this. Model-native memory does not.

Comparing the main options

PLUR (open-format, MCP-native)
Stores facts as plain-text engrams in ~/.plur/. Any MCP-compatible tool reads and writes the same directory. Crash-safe by design (file writes are atomic). Fully auditable — grep the directory, open files in any editor, diff changes with git. Free and self-hosted. Best for: agents that need cross-tool portability, full auditability, or GDPR-compliant deletion.

Mem0 (hosted vector memory)
Hosted API that stores and retrieves memories as vector embeddings. Good semantic search. Available via Python SDK, TypeScript SDK, and MCP. Managed infrastructure — no deployment. Best for: personalization memory (user preferences, interaction history) where semantic similarity search matters more than exact-match recall.

Zep / Graphiti (temporal graph memory)
Maintains a knowledge graph of facts with temporal context (who said what, when, in which conversation). Graph traversal lets agents reason about causal chains and entity relationships. Best for: multi-agent systems where relationships between entities matter (CRM data, long-term project tracking).

Letta (stateful agent OS)
Provides a full stateful agent runtime with built-in memory management (archival memory, recall memory, in-context memory tiers). More opinionated than a standalone memory layer — you write agents using Letta's framework. Best for: teams who want an opinionated end-to-end agent stack rather than composing individual components.

SQLite / file-based custom store
Maximum control, no external dependency. Write your own schema. Works for teams with specific requirements that off-the-shelf memory tools do not meet, but requires building the read/write/query logic yourself.

Source: AI Agent Memory Frameworks in 2026

Decision guide

Your requirement	Best fit
Cross-tool portability + auditability	PLUR
Semantic similarity search + personalization	Mem0
Temporal reasoning + knowledge graphs	Zep / Graphiti
Opinionated end-to-end agent framework	Letta
Full control, no external dependency	SQLite / custom
Works with any MCP tool out of the box	PLUR
Hosted, managed infrastructure	Mem0, Zep, Letta Cloud

Practical setup: PLUR for an autonomous agent

# One-time setup — installs MCP server and initializes the store
npx @plur-ai/mcp init

In your agent's run loop:

# At the start of each run: recall relevant context
facts = plur_recall(query="project dependencies", limit=10)

# During the run: persist new discoveries immediately
plur_learn(text="Confirmed: package X v2.3 is incompatible with Y v1.8", domain="project.deps")

# If the run crashes: facts written before the crash survive
# Next invocation picks up from the last durable state

The ~/.plur/ directory holds all facts as plain files. You can inspect, version-control, or back up the directory. When you switch from Claude Code to a custom CLI or another MCP-compatible tool, the same directory is automatically available.

FAQ

What's the best memory system for autonomous AI agents?
It depends on your needs. For cross-tool portability and full auditability, PLUR's open-format file store is the practical choice. For semantic search and personalization at scale, Mem0's hosted API is well-suited. For knowledge-graph and temporal reasoning, Zep/Graphiti is purpose-built. Most autonomous pipelines benefit from one of these three over model-native memory, which cannot be written to programmatically.

Why can't I just use context-window state for agent memory?
Context windows reset between invocations. An autonomous agent launched at 02:00 has an empty context — it has no access to what a 22:00 run discovered. Durable external memory (file-based or API-backed) is the only way to carry state across separately launched processes.

Does PLUR work with autonomous agents that don't use MCP?
Yes. PLUR has a Python SDK and TypeScript SDK that call the local store directly, without requiring an MCP server. The MCP server is optional — it adds integration with MCP-compatible tools (Claude Code, Cursor, OpenClaw) but is not needed for script-based autonomous agents.

How do I handle memory cleanup for long-running autonomous agents?
Autonomous agents accumulate facts over time. Plan for: (1) expiry — tag facts with a time-to-live or epoch, and decay/archive old entries; (2) deduplication — store-level dedup prevents the same fact being written 100 times; (3) explicit deletion for GDPR/right-to-be-forgotten use cases. PLUR's plur_forget and plur_batch_decay handle these; Mem0 has equivalent API calls.

Sources

How to Build AI Agent Memory in 2026 — Fountain City
AI Agent Memory Frameworks in 2026 — Graphlit Blog
PLUR open-format engram memory — GitHub

Is AI Agent Memory GDPR Compliant? A Developer's Guide

gregor — Fri, 24 Jul 2026 10:06:45 +0000

Is AI Agent Memory GDPR Compliant? A Developer's Guide

The short answer is: it depends on how you implement it. AI agent memory is not inherently GDPR non-compliant, but most default implementations create three serious compliance risks: you cannot locate all data about a specific person, you cannot prove that deletion actually happened, and embedding-based storage makes selective erasure technically impossible. This guide explains what GDPR Article 17 requires from AI agent memory, where common memory frameworks fall short, and how to design a system that is defensible.

What GDPR Article 17 Actually Requires

Article 17 of the GDPR — the "right to erasure" or "right to be forgotten" — gives data subjects the right to demand deletion of their personal data, and requires the data controller to comply "without undue delay." In the context of AI agents that remember things about users, this creates four concrete engineering obligations:

1. Identification: You must be able to find all data the agent holds about a specific data subject. If an agent has learned facts about a user across 50 sessions and stored them as vector embeddings, locating all relevant embeddings is not tractable.

2. Deletion: You must be able to remove that data completely. "Remove from the retrieval index" does not meet the standard — the underlying records must be deleted from storage.

3. Proof of deletion: In practice, regulators and data subjects may request evidence that deletion occurred. A system that logs "deleted at timestamp X" without a verifiable audit trail is harder to defend than one where deletion produces a diff of removed records.

4. Sub-processor propagation: If you use a third-party API for memory storage (a managed vector database, a SaaS memory service), you are responsible for ensuring that sub-processor also deletes the data. This has specific implications for cloud-hosted memory services.

Where Common Memory Architectures Fail

Embedding-based storage (Mem0, most RAG systems)

When an agent learns a fact — "Alice is vegetarian" — and stores it as a vector embedding, that vector encodes the semantic meaning of the fact in a mathematical space. When you "delete" the record, you remove the reference in the retrieval index, but the vector values persist in the database's underlying storage until the database compacts or vacuums. More critically, the model that generated the embedding "saw" the fact — you cannot un-teach it.

For GDPR purposes: deletion from the retrieval index removes the practical ability to retrieve the fact, but it does not constitute erasure of the underlying personal data. Vector databases such as Pinecone, Weaviate, and Qdrant do support hard deletion of individual vectors, so this is solvable — but it requires explicit implementation, not the default behavior of frameworks like Mem0.

Practical gap: Mem0's default delete_all(user_id=...) API call removes records from its managed store, but if you are using a self-hosted Mem0 with a Qdrant backend, you must also confirm that Qdrant has flushed the deleted segment before you can claim erasure.

Stateful agent memory (Letta / MemGPT)

Letta stores memory as structured "memory blocks" — persona, human, archival — that the agent itself can read and edit. Right-to-erasure requires identifying which blocks contain data about a specific person and zeroing or removing them. For single-user agents, this is straightforward. For multi-user agent deployments, where one agent instance serves many users, the isolation model becomes critical: data about User A must not persist in a block that User B's interactions can reach.

Practical gap: Letta's memory blocks are human-readable text files or database records, which makes them easier to audit than embeddings — but there is no built-in forget(user_id=...) API. You need to build this yourself.

Knowledge graph memory (Zep / Graphiti)

Zep stores memory as a temporal knowledge graph: entities (people, organizations, concepts), edges (relationships), and timestamps (when facts were learned). Right-to-erasure requires deleting all nodes and edges that encode personal data about a specific person. Graphiti's graph structure makes this more explicit than embedding search, but also more complex — deleting a person entity may require cascading deletes through related nodes.

Practical gap: Graph deletion is well-defined, but orphaned nodes (edges that reference a deleted entity) require careful handling.

Open-Format Memory and Verifiable Deletion

The technical root of most GDPR compliance friction is opaque storage formats: vectors, compressed database pages, and graph indices all make it difficult to verify what was deleted and prove that nothing remains.

Open-format memory — where each piece of remembered information is stored as a plain text record in a file — makes deletion both auditable and provable. When you delete a record from a text file and commit the change to version control, the diff is the proof of deletion.

PLUR stores each engram (a unit of agent memory) as a structured text record in a local YAML file. The plur forget <id> command retires the engram — marking it status: retired and excluding it from all future recall. Because the store is a flat file tracked by git, the retirement produces a verifiable diff: the entry's status field changes from active to retired.

# Retire a specific engram by ID
plur forget ENG-2026-0618-042

# Retire by search (when you know content but not ID)
plur forget --search "Alice is vegetarian" --reason "Article 17 request 2026-07-15"

# Verify the status change via git
git diff HEAD~1 ~/.plur/engrams.yaml

The --reason flag records the legal basis or request reference in the engram's rationale field, creating a lightweight audit log within the file's git history.

What this gives you: When a data subject exercises their right to erasure, you can search for their identifier, retire matching engrams, commit, and produce a diff showing which entries were retired and when. The retired entries remain in the YAML file but are permanently excluded from retrieval. For strict GDPR erasure (physical removal), you can manually delete the retired entries from the YAML and commit that change — the git diff then shows complete removal. This does not replace a formal data processing log, but it provides a verifiable technical artifact that supports your compliance posture.

Implementing the Right to Be Forgotten: A Practical Checklist

Regardless of which memory framework you use, a GDPR-defensible implementation needs:

1. Attribute every memory unit to a data subject

When storing a memory, tag it with the user identifier it relates to. In PLUR, this is the scope field on an engram. In a custom system, a user_id field on each record.

# Learn a fact attributed to a specific user
plur learn "Alice prefers dark mode" --scope "user:alice@example.com"

2. Build a search-by-subject function

You need to find all memories about a person efficiently. Test this before you go to production — do not discover at the time of a regulatory inquiry that your search is missing records.

# Find all active engrams for a user
plur recall --scope "user:alice@example.com" --limit 1000

3. Implement delete-all-for-subject

Map this to your framework's deletion primitives. In PLUR:

# One-liner to retire all engrams in a user scope
plur forget --search "alice@example.com" --reason "GDPR Article 17 request 2026-07-15"

For embedding-based systems, this typically means: (a) query for all records with user_id = X, (b) call the hard-delete API on each, (c) trigger a storage compaction to flush deleted segments, (d) log the record IDs and confirmation response.

4. Propagate to sub-processors

If your agent uses external memory APIs, cloud vector databases, or third-party services, confirm that your DPA (Data Processing Agreement) with each sub-processor covers deletion, and test that deletion requests propagate.

5. Create an audit trail

Log every deletion event with: request reference, subject identifier, list of deleted record IDs, timestamp, and executor. A commit diff qualifies for open-format systems; for database systems, write this to an append-only audit log.

6. Test deletion before you need it

Run a deletion drill quarterly. Create test records, exercise the right-to-erasure flow, verify that the deleted records do not appear in subsequent recall, and document the result.

EU AI Act Considerations

The EU AI Act (fully applicable from August 2026) introduces additional obligations for AI systems classified as high-risk under Annex III — including systems that interact with individuals in employment, education, credit, and law enforcement contexts. If your agent falls under a high-risk category, you have logging and traceability requirements that interact with memory: you must be able to reconstruct what the agent knew when it made a consequential decision.

This creates a tension with GDPR right-to-erasure: if you delete the memory that informed a hiring recommendation, you may lose your ability to audit that recommendation. Legal guidance for this tension is still evolving; the practical path is to maintain a separate, subject-anonymized audit log of consequential decisions, distinct from the live memory store that is subject to deletion.

Summary Table

Framework	Storage format	Search by subject	Hard delete	Provable deletion
PLUR	Structured text files	✅ `--scope` filter	✅ `plur forget` (retires; physical delete via manual YAML edit)	✅ git diff (status change or entry removal)
Mem0 (managed)	Managed vector store	✅ `user_id` API	✅ `delete_all`	Partial (server log)
Mem0 (self-hosted)	Qdrant / PG vectors	✅ `user_id` filter	Needs explicit compaction	Requires Qdrant audit
Letta	Memory blocks (text/DB)	Manual	Manual	Manual
Zep / Graphiti	Knowledge graph	✅ entity search	Graph node delete	Requires cascade audit
Custom RAG	Vector DB	Depends on indexing	Depends on DB	Depends on logging

FAQ

Is storing AI agent memories "personal data" under GDPR?

If the memories relate to an identified or identifiable natural person — their preferences, behavior, statements, or any other information about them — yes, they qualify as personal data under Article 4(1) GDPR.

Does GDPR apply if I run the agent locally on the user's device?

If you process data solely locally and do not transmit it to a server, some GDPR obligations (particularly around sub-processors) do not apply. You are still a data controller, however, and the right to erasure still applies if the user requests it.

Can I keep anonymized memories after a deletion request?

If memories have been genuinely anonymized — not pseudonymized, but fully de-identified — they fall outside GDPR scope and do not need to be deleted. The standard for anonymization is high; removing a name while retaining behavioral patterns linked to a single individual is pseudonymization, not anonymization.

Does the right to be forgotten apply to fine-tuned models?

Strictly speaking, yes — if personal data was used in fine-tuning, a data subject can request erasure. In practice, true erasure from a fine-tuned model is not yet technically feasible at scale (machine unlearning is an active research area). Regulators are still developing guidance on this. For agent memory systems, which store facts as discrete records rather than baking them into model weights, deletion is tractable.

What retention period applies to agent memories?

GDPR requires data to be kept "no longer than necessary for the purposes for which the personal data are processed" (Article 5(1)(e)). You need a defined retention policy — whether that is session-only, 90-day rolling, or indefinite with annual review — and a mechanism to enforce it.

Reviewed: 2026-07-18. This article provides technical guidance, not legal advice. Consult a qualified data protection specialist for your specific use case.

How to Delete Specific Things an AI Remembers About You

gregor — Thu, 23 Jul 2026 11:18:34 +0000

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

Do You Still Need an Agent Memory Layer if ChatGPT Already Has Memory?

gregor — Wed, 22 Jul 2026 10:11:28 +0000

Do You Still Need an Agent Memory Layer if ChatGPT Already Has Memory?

Yes — for a reason that becomes clear once you separate two different jobs. ChatGPT memory, Claude Projects, and Gemini's built-in memory solve a conversational recall problem: they remember what you told the model inside its own interface. An agent memory layer (Mem0, Zep, Letta, PLUR) solves a programmatic recall problem: it stores facts inside your application, accessible from your code, portable across every tool your agent uses. These systems serve different jobs and work best together.

What model-native memory does (and where it stops)

As of 2026, the major model providers ship built-in memory in two forms.

ChatGPT has "saved memories" — an explicit, user-editable list of facts that ChatGPT chose to remember across conversations — and "reference chat history" (launched April 2025), which implicitly draws on patterns from past chats. Saved memories are auditable: you can open Settings → Personalization → Manage memory and see exactly what is stored. Reference chat history is not auditable — you cannot see what it has inferred. ChatGPT Projects adds a Project Memory scope that captures facts within a specific project workspace, isolated from other projects and from main chat.

Claude Projects maintains a project-level instruction set and uploaded file context, scoped per project, persisting across all conversations in that project. Unlike ChatGPT's saved memories, Claude Projects does not automatically extract facts from conversations — knowledge is added explicitly via the instruction set or uploaded files.

Gemini offers workspace-scoped memory through Gemini Apps Activity, manageable through your Google Account privacy dashboard.

The common constraint: all of these live inside the model provider's servers, scoped to the model's own interface. They do not follow your agents into code.

When your Claude Code session ends, Claude's project memory does not inject into your next Cursor session. When ChatGPT remembers you prefer Python, your custom CLI agent does not know that. Model-native memory exists in one silo, per provider, per interface.

Source: ChatGPT Memory Guide 2026

What an agent memory layer adds

An agent memory layer runs in your application, not the model provider's server. It gives you four things model-native memory cannot:

Portability. The memory store is a resource your code owns. If you switch from Claude to GPT-4o, or from Cursor to a custom CLI, the memory follows automatically — no migration, no re-learning.

Programmatic read/write. Your code can store a fact at runtime (plur_learn, mem0.add), retrieve it on the next run (plur_recall, mem0.search), and update or delete it via API. Model-native memory cannot be written to by your code — only the model and the user can modify it.

Auditability. With file-based memory systems like PLUR, you can open the store with a text editor, grep for specific facts, and see exactly what the agent knows and when it learned each item. With vector-based stores like Mem0, you can query the API. With model-native memory, you are limited to what the provider's UI exposes.

Deletion control. You can implement right-to-be-forgotten policies, purge all facts about a specific user, or wipe session state programmatically. Model-native memory deletion goes through the provider's interface, not your code.

Source: How to Build AI Agent Memory in 2026, AI Agent Memory Frameworks in 2026

The complement frame: different jobs, use both

Model-native memory is useful for: "Remember I prefer Python over JavaScript" — a conversational preference stored in the model's own interface, useful when you are talking directly to ChatGPT or Claude.

Agent memory is useful for: "Remember the architecture decision we made last sprint, the user's confirmed preferences across three tools, and the intermediate results from yesterday's research loop" — operational knowledge your code needs to function, across tools, overnight, in pipelines.

The right setup for most production agent deployments: use model-native memory for its intended purpose (conversational recall in the model's own interface), and add an agent memory layer for programmatic recall in your code.

PLUR as the cross-tool layer

PLUR stores memories as open-format engrams in a local directory (~/.plur/). Any MCP-compatible tool — Claude Code, Cursor, Hermes, OpenClaw, or a custom CLI — reads and writes the same directory without additional configuration. When you switch between tools, the memory follows automatically.

# Install once — works across all your MCP-compatible tools
npx @plur-ai/mcp init

From any session, plur_recall queries the store; plur_learn adds to it. The same ~/.plur/ directory is shared. This is the portability that model-native memory cannot provide: one memory store, every tool.

Summary table

	Model-native memory	Agent memory layer (e.g. PLUR)
Where it lives	Model provider's server	Your application / local directory
Scope	That model's interface only	Any tool that speaks MCP or the API
Set by	User + model (conversational)	Your code (programmatic)
Read by your code	No	Yes
Cross-tool portable	No	Yes
Auditable in full	Partially (saved memories only)	Yes
Deletion via your code	No	Yes
Works without a chat interface	No	Yes

FAQ

Do I still need an agent memory layer if ChatGPT already has memory?
Yes, if you are building agents in code. ChatGPT memory is scoped to the ChatGPT interface — it does not follow your agents into Cursor, Claude Code, a custom CLI, or overnight pipelines. An agent memory layer stores facts in your application, accessible from any tool that queries it.

What is the difference between model memory and agent memory?
Model memory (ChatGPT saved memories, Claude Projects, Gemini) is conversational memory stored on the model provider's server, accessible only through that model's interface. Agent memory is operational memory stored in your application, accessible by your code, portable across tools. The same agent can use both: model memory for interface-level recall, agent memory for cross-session and cross-tool recall.

How does Claude Projects memory compare to agent memory?
Claude Projects memory captures facts within a project session and persists them for future sessions in that project. It is scoped to Anthropic's interface and cannot be read or written by external code. Agent memory (Mem0, PLUR, Zep) is stored in your application and is accessible from any code that calls the memory API — including code running outside any Claude interface.

Can I use agent memory alongside a model's built-in memory?
Yes, and this is the recommended approach. Use model-native memory for conversational recall within that model's interface. Use agent memory for facts your code needs to access, persist across tools, or control programmatically. The two stores do not conflict — they serve different retrieval paths.

ChatGPT vs Mem0 vs PLUR — what should I use for AI memory?
These are not direct alternatives. ChatGPT memory serves the ChatGPT web interface. Mem0 and PLUR are agent memory layers for use in code. If you are building agents: Mem0 for general personalization, PLUR if you need cross-tool portability and open-format storage. Use ChatGPT memory in addition to — not instead of — a dedicated agent memory layer.

Sources

ChatGPT Memory: Complete Guide for 2026 — gptprompts.ai
AI Agent Memory Frameworks in 2026: Memory vs. Context — Graphlit Blog
How to Build AI Agent Memory in 2026 — Fountain City
AI Memory Problem 2026: Risks in ChatGPT, Claude, Gemini — MayhemCode
PLUR open-format engram memory — GitHub

Best Tools for Giving AI Agents Long-Term Memory (2026)

gregor — Tue, 21 Jul 2026 11:21:03 +0000

Best Tools for Giving AI Agents Long-Term Memory (2026)

AI agents lose everything when a session ends. If your agent is rebuilding task state from scratch on every run, re-explaining user preferences to each tool, or contradicting decisions from last week, you need a dedicated memory layer — not a larger context window. The leading options in 2026 are Mem0, Zep, Letta, LangMem, and PLUR. Each targets a different retrieval pattern: Mem0 for general personalization, Zep for temporal reasoning, Letta for autonomous agents that manage their own memory, LangMem for LangGraph-native projects, and PLUR for cross-tool portability via the open engram format.

Why context windows are not enough

Every agent framework gives your agent a context window. When the session closes, that window clears. For agents that interact with the same user across days or weeks — or for multi-agent pipelines where one agent passes state to another — you need a mechanism that extracts the facts that matter, stores them durably, and retrieves them later with high precision.

That is what a dedicated memory layer does. It sits between your agent and its long-term store, handling extraction, indexing, retrieval scoring, and (where supported) forgetting.

The leading tools

Mem0

Mem0 is the most widely adopted agent memory platform in 2026, with 48,000+ GitHub stars. It combines vector search, a knowledge graph, and key-value storage, with automatic memory extraction built in. The architecture handles the most common case: a user-facing application that needs to remember preferences, past interactions, and learned facts without the developer writing extraction logic by hand.

On the LongMemEval benchmark — the current standard stress test for agent memory — Mem0 scores 49.0% with GPT-4o. That is a solid general-purpose result. Mem0 offers both a hosted API and a self-hosted path via the open-source repo.

Best for: teams starting out, personalization-heavy applications, the largest community and ecosystem.

Zep / Graphiti

Zep's Graphiti backend timestamps every fact in a knowledge graph, making it the strongest option when temporal relationships matter — e.g., "what did the user want last Tuesday versus today?" or "which goal is still active after three sessions?" On LongMemEval with GPT-4o, Zep scores 63.8%, currently the strongest reported result among managed services. The graph approach also makes it easier to reason over relationships between entities, not just over isolated facts.

Graphiti is the open-source knowledge graph engine underneath Zep. You can run Graphiti self-hosted if you do not want a managed service.

Best for: agents that need to reason over how facts change over time, temporal retrieval, knowledge graph use cases.

Letta (formerly MemGPT)

Letta treats agent memory like an operating system: main context is RAM, archival memory is disk, and the agent itself decides what to page in and out. This is a different philosophy from tools that abstract memory away from the agent — Letta gives the agent more autonomy over its own memory allocation, at the cost of more complex setup. Long-running agents that need to manage large, evolving knowledge bases tend to benefit most.

Best for: autonomous agents with large knowledge bases, OS-style memory management, full self-hosting.

LangMem

LangMem is the memory module from the LangChain team, designed to integrate tightly with LangGraph. If your agent is already on LangGraph, LangMem is the lowest-friction way to add persistent memory — it wires into the LangGraph state machine without a separate service.

Best for: LangGraph-native projects, teams already in the LangChain ecosystem.

PLUR

PLUR stores memories as open-format engrams: structured assertions with confidence scores, domain tags, and decay curves. Each engram is a plain-text YAML entry in a local directory (~/.plur/). Any tool that speaks MCP — Claude Code, Cursor, Copilot, Hermes, or a custom CLI — can read and write the same store without configuration changes per tool.

The open engram format is PLUR's primary differentiator. When your memory store is a local file directory rather than a proprietary API, you get portability (move between tools without migration), inspectability (open any file with a text editor or grep), and provable deletion (a git diff shows what was removed and when). PLUR includes hybrid BM25 + embedding retrieval with Reciprocal Rank Fusion, confidence decay for stale memories, and pack-based memory sharing.

Best for: cross-tool portability, MCP ecosystem, open-format auditable memory, teams that need to share memory across multiple agents or tools.

Comparison table

Tool	Architecture	Retrieval	Self-hostable	Open format	Cross-tool
Mem0	Vector + graph + KV	Semantic + graph	Yes	No	Via API
Zep / Graphiti	Temporal knowledge graph	Graph + temporal	Yes (Graphiti)	Graphiti is open source	Via API
Letta	Agent-managed memory blocks	Agent-controlled paging	Yes	No	Letta agents only
LangMem	LangGraph state	LangGraph-native	Yes	No	LangGraph only
PLUR	Open-format YAML engrams + hybrid search	BM25 + embeddings (RRF)	Yes (local default)	Yes	Any MCP-compatible tool

How to choose

Start with Mem0 if you need a general-purpose solution with the largest community and you're not constrained by format, hosting, or cross-tool requirements.

Choose Zep if your agent needs to reason about when facts were true — temporal retrieval is Zep's core strength.

Choose Letta if you're building long-running autonomous agents that should manage their own context allocation.

Choose LangMem if you're already on LangGraph and want the lowest-friction integration.

Choose PLUR if your agents run across multiple tools (Claude Code + Cursor + Hermes, for example), if you need memory to be inspectable and provably deletable, or if open-standard interoperability matters to your deployment.

Most production systems pair a dedicated memory platform with a vector store (Pinecone, Weaviate, or pgvector) for retrieval at scale — the memory tool handles extraction and scoring, the vector store handles indexing.

Quick start: PLUR

# Install the MCP server
npx @plur-ai/mcp init

# Add to Claude Code, Cursor, or any MCP-compatible tool
# Memory is stored in ~/.plur/ — readable, portable, diffable

From any MCP session, your agent can read and write engrams with plur_recall_hybrid / plur_learn (plur_recall_hybrid is the recommended default — BM25 + embeddings merged via RRF). The same store is shared across all connected tools automatically.

FAQ

What is the best open-source memory layer for LLM agents?
In 2026, Mem0 has the largest open-source community (47,000+ GitHub stars) and is the most commonly recommended starting point. Zep's Graphiti engine is the strongest option for temporal reasoning. PLUR is the best choice if you need memory to be portable across tools and stored in an open, auditable format.

How do I stop an AI agent from forgetting context between sessions?
Add a dedicated memory layer. The pattern: on session end, have the agent write key facts to the memory store; on session start, query the store for relevant context and inject it into the system prompt. All five tools above support this pattern with different levels of automation — Mem0 and PLUR offer the most out-of-the-box extraction.

What is the difference between an agent memory layer and a vector store?
A vector store (Pinecone, pgvector, Weaviate) handles indexing and similarity search. An agent memory layer handles the higher-level workflow: deciding what to remember, extracting structured facts from conversations, scoring relevance, decaying stale memories, and handling deletion. Most production setups use both.

Do agent memory tools work with any LLM?
Yes. Memory layers are model-agnostic — they store and retrieve text-based facts, which any LLM can consume. The LLM you use for extraction and retrieval scoring can differ from the LLM running your agent.

Sources

AI Agent Memory in 2026: Mem0 vs Zep vs Letta vs Cognee — A Practical Guide — DEV Community
Best AI Agent Memory Providers in 2026: Mem0 vs Zep vs Letta vs Cloudflare — Developers Digest
Best AI Agent Memory Systems in 2026: 8 Frameworks Compared — Vectorize
Best AI Agent Memory Frameworks in 2026: Compared and Ranked — Atlan
PLUR open-format engram memory — GitHub

How Do I Make My AI Agent's Memory Editable and Auditable?

gregor — Mon, 20 Jul 2026 11:52:22 +0000

How Do I Make My AI Agent's Memory Editable and Auditable?

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).

The problem: black-box memory

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:

Open a memory file and read what it says
Correct a single fact without an API call
Diff the memory store against a previous version
Prove that a specific memory was deleted (you can delete it through the API, but you cannot prove erasure — the vector or graph node may persist in a backup)

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.

Why this matters

Debugging

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.

Privacy and compliance

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.

Trust

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.

What editable and auditable memory looks like

An editable, auditable memory system has five properties:

1. Human-readable format

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.

2. Inspectable

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.

3. Correctable

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.

4. Deletable with proof

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.

5. Version-controllable

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.

How existing tools handle inspection and deletion

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.

The right-to-be-forgotten problem

When a user asks you to delete what your AI agent knows about them, you need to do three things:

Find all memories related to that user. If memories are files, you can grep them. If they are vector embeddings, you need to query by similarity and hope you got them all.
Delete those memories. If memories are files, you delete the files. If they are vectors, you delete the vectors — but the source text may exist in logs, backups, or training data.
Prove erasure. If memories are files under version control, the git diff is your audit trail. If they are vectors, you have no proof — you can show the delete API call succeeded, but you cannot prove no copy persists.

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 MCP dimension

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.

How to choose

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.

FAQ

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.

Are AI Agent Engrams Open Source or Proprietary?

gregor — Sun, 19 Jul 2026 21:22:44 +0000

Are AI Agent Engrams Open Source or Proprietary?

The short answer: both, and the split matters. The major agent-memory engines — Mem0, Letta, Cognee, Graphiti, LangMem, and PLUR — are all Apache-2.0 or MIT licensed on GitHub. But "open source" and "open format" are not the same thing. A project can ship under Apache-2.0 while storing your memories in opaque vector blobs you cannot read, edit, or export. The real question is not whether the software is open — it usually is — but whether your memories are.

This distinction separates the field into three tiers: fully open (software + format + data you own), open-core (software is open, but the hosted memory is not portable), and fully proprietary (memory baked into a model provider's infrastructure, no export at all).

Why this question exists

AI agents face a brutal constraint: they forget. Every new session starts blank. Every context window overflows. The fix is persistent memory — but persistent where, and in whose format?

The term "engram" comes from neuroscience. Richard Semon coined it in 1904 for the physical trace a memory leaves in biological tissue (Semon, 1904; cited in Wikipedia, "Engram (neuropsychology)"). Applied to AI agents, an engram is one discrete thing an agent has learned — a correction, a preference, a procedure — stored so it survives across sessions.

The question "open source or proprietary?" asks two things at once:

Is the engine that stores and retrieves engrams open source?
Is the format those engrams are stored in open — readable, editable, portable?

Conflating the two is how vendors end up with open-source repos and locked-in data.

Tier 1: Fully open — software, format, and data

These projects ship under permissive licenses (Apache-2.0 or MIT) AND store memory in a format you can inspect, edit, and export.

Project	License	Stars (Jul 2026)	Memory format	Data ownership
PLUR	Apache-2.0	~215	Human-readable YAML engrams	Yours — plain files

PLUR stores each engram as a plain-text YAML entry — an id, a statement, a type, a domain, a scope, a confidence, and provenance — in a file you can open in any editor, put under version control, and carry between machines. The format is published as an open specification, the Engram Specification (plur.ai/spec.html, Apache-2.0), and the implementation is Apache-2.0 on GitHub (github.com/plur-ai/plur).

The tier is small but growing. The "engram" name itself is spreading fast: GitHub now hosts a dozen-plus young projects named engram, most of them early-stage local-first memory experiments. That crowding is the signal — "engram" is becoming the default word for a unit of agent memory. It is also why a published open specification matters: without one, every project that adopts the term defines it differently, and the word stops meaning anything portable.

The common thread of Tier 1: you can read the memory, you can fix it, and you can prove you deleted it. That is only possible when the format is open, not just the engine.

Tier 2: Open-core — software is open, hosted memory is not

These projects have open-source engines on GitHub under permissive licenses, but their hosted/cloud products store memory in formats that are not easily portable, and the commercial tier is where revenue lives.

Project	License	Stars (Jul 2026)	Open format?	Hosted tier
Mem0	Apache-2.0	~60,500	No — vector + graph store	$19–$249/mo
Letta	Apache-2.0	~23,700	Partial — agent state, not portable engrams	$20/mo (Pro)
Cognee	Apache-2.0	~27,400	No — knowledge graph internals	Self-host or cloud
Graphiti	Apache-2.0	~28,500	No — temporal knowledge graph	Via Zep cloud
LangMem	MIT	~1,500	No — LangGraph storage layer	Via LangSmith

Mem0 is the clearest example. The repo (github.com/mem0ai/mem0) is Apache-2.0 with nearly 60,000 stars — you can self-host the engine. But Mem0's commercial product (mem0.ai) charges $19–$249/month for hosted memory with graph memory, audit logs, and on-prem deployment reserved for the Enterprise tier. The memory format under the hood is a vector store with entity linking — not a human-readable file you can diff.

Letta (formerly MemGPT) is similarly split. The Letta SDK is Apache-2.0 on GitHub (github.com/letta-ai/letta, ~23,700 stars). The hosted "Constellation" platform — with managed state, remote environments, and an LLM gateway — requires an account. Free accounts support up to three agents with managed state; Pro is $20/month. Memory is stored as agent state (blocks of text managed by the agent), not as individual portable engrams you can export and edit.

Graphiti (github.com/getzep/graphiti, ~28,500 stars) builds real-time knowledge graphs for agents under Apache-2.0, but its commercial path is through Zep's cloud platform.

Cognee (github.com/topoteretes/cognee, ~27,400 stars) is an open-source AI memory platform using knowledge graphs, also Apache-2.0, with self-host or cloud options.

The pattern: the engine is open, the data format is not. You can run the software, but the memories live in vector embeddings, knowledge graphs, or agent state blocks that are not designed to be read by humans or exported to a different system.

This is not a criticism — open-core is a legitimate model. But it means "open source" answers the wrong question. The right question is: can I take my memories with me?

Tier 3: Fully proprietary — memory baked into the model provider

The third tier is memory that is neither open-source software nor an open format. It lives inside the model provider's infrastructure, and you cannot inspect, export, or port it.

OpenAI's ChatGPT memory is the canonical example. When ChatGPT "remembers" facts about you across conversations, those memories are stored in OpenAI's infrastructure. There is no open-source engine, no documented format, no export API. You can toggle memory on or off, and you can view and delete individual memories in the UI — but you cannot extract them in a structured format, run them locally, or feed them to a different model.

Anthropic's Claude memory tool takes a similar approach. The memory tool is a feature of the Claude platform — agents can store and retrieve context — but the storage format, the retrieval mechanism, and the data itself are proprietary. There is no GitHub repo, no format spec, no portability guarantee. (Note the distinction: Claude Code's CLAUDE.md and auto-memory files are a separate, file-based mechanism — plain markdown on your own disk — and do not belong in this tier.)

Google Gemini's context operates the same way. Long-term context is managed inside Google's infrastructure with no documented open format.

The risk here is not that these features are bad — they are convenient and often work well. The risk is vendor lock-in for your most personal data. When your agent's accumulated knowledge about your preferences, projects, and workflow lives inside a single provider's black box, switching costs become prohibitive. You cannot audit what it knows. You cannot prove what it forgot. You cannot carry it elsewhere.

The real split: open engine vs open format

Three tiers, but the meaningful boundary is between Tier 1 and everything else:

Property	Tier 1 (Fully open)	Tier 2 (Open-core)	Tier 3 (Proprietary)
Engine open source?	Yes	Yes	No
Memory format documented?	Yes	No	No
Data human-readable?	Yes	No (vectors/graphs)	No
Can edit individual memories?	Yes	Via API only	Via UI only
Can prove erasure?	Yes (delete the entry; git diff as proof)	Best-effort	Best-effort
Can export to another system?	Yes (it's a file)	No standard export	No export
Portable across model providers?	Yes	No	No

The agents that need open memory most are the ones operating across multiple tools, models, and providers. An agent that uses Claude for analysis, GPT-4 for coding, and a local model for privacy needs a memory layer that is none of those — it needs a format that belongs to the operator, not the model.

This is where the Model Context Protocol (MCP) enters. MCP (specification version 2025-11-25, modelcontextprotocol.io) is an open protocol — JSON-RPC 2.0 based, inspired by the Language Server Protocol — that standardizes how LLM applications connect to external data sources and tools. It is transport-level: it says how an agent talks to a memory server, not what format the memories are in. But it makes format-level openness newly relevant, because any MCP-compatible agent can now connect to any MCP-compatible memory server. The format question — can I read, edit, and port my memories? — becomes the differentiator.

How to evaluate whether your agent's memory is open

Is the engine on GitHub under a permissive license? (Apache-2.0, MIT — not BSL, not "source-available")
Is the memory format documented? Can you read the spec without signing up?
Can you open a memory file in a text editor and understand it? Or is it an opaque vector?
Can you delete one memory and prove it is gone? GDPR-grade erasure, not best-effort.
Can you export all memories and import them into a different system? True portability.
Does the memory work across model providers? Or is it locked to one vendor's infrastructure?

If the answer to all six is yes, you are in Tier 1. If the engine is open but the format is not (questions 3–6 fail), you are in Tier 2. If there is no open engine at all, you are in Tier 3.

FAQ

Are AI agent engrams open source? The major engines are — Mem0, Letta, Cognee, Graphiti, LangMem, and PLUR all ship under Apache-2.0 or MIT. But the memory format is often not open. Very few projects store memory in a human-readable, documented, portable format you can inspect and export — PLUR publishes its engram format as an open Apache-2.0 specification (plur.ai/spec.html) precisely so that "engram" stays an open, implementable thing rather than a vendor label.

What is the difference between open source and open format for AI memory? Open source means the software engine is on GitHub under a permissive license. Open format means the memory data itself is stored in a documented, human-readable structure you can read, edit, and carry between systems. A project can be open source without being open format — most are.

Can I export my agent's memory from a proprietary system? Generally, no. OpenAI's ChatGPT memory, Anthropic's Claude memory tool, and Google Gemini's context all store memory inside the provider's infrastructure with no structured export. You can view and delete memories in the UI, but you cannot extract them in a portable format.

What license is PLUR's engram format under? Apache-2.0. The engram format is documented in the Engram Specification at plur.ai/spec.html and the implementation is at github.com/plur-ai/plur. Each engram is a YAML entry you can open, edit, and version-control.

Is MCP an open standard for agent memory? MCP is an open transport protocol (JSON-RPC 2.0, specification 2025-11-25) that standardizes how agents connect to external tools and data sources — including memory servers. It does not define a memory format. But it makes format-level openness more valuable, because any MCP-compatible agent can connect to any MCP-compatible memory server regardless of vendor.

Is There an MCP Server for AI Agent Memory?

gregor — Tue, 14 Jul 2026 11:46:01 +0000

Is There an MCP Server for AI Agent Memory?

Yes. The Model Context Protocol (MCP) — an open protocol published by Anthropic in November 2024, specification version 2025-11-25 — standardizes how LLM applications connect to external tools and data sources, and several MCP servers exist specifically for agent memory. The official MCP servers repository includes a knowledge graph-based memory server (@modelcontextprotocol/server-memory), and third-party memory servers — including PLUR, Zep, Mem0's OpenMemory, and community projects — expose persistent agent memory through the same protocol. The practical question is not whether an MCP memory server exists, but which one fits your needs, because "MCP-compatible" tells you the transport, not the memory format.

What MCP is (and what it is not)

MCP is an open protocol built on JSON-RPC 2.0, inspired by the Language Server Protocol (LSP). Just as LSP standardized how editors connect to language servers (so any editor works with any language server), MCP standardizes how AI agents connect to external tools and data sources (so any agent works with any tool server). The protocol defines three things a server can offer: Resources (context and data), Prompts (templated messages), and Tools (functions the AI can execute). A memory MCP server typically exposes tools — store, recall, search, learn, forget — that the agent calls to manage what it remembers (modelcontextprotocol.io/specification/2025-11-25).

What MCP does not define is the memory format. It says how an agent talks to a memory server, not what the memories look like inside. This means two MCP memory servers can be fully protocol-compatible and store memory in completely different ways — one as a vector embedding, one as a human-readable YAML file. The protocol is open; the format is the differentiator.

Memory MCP servers available today

Official MCP memory server (knowledge graph)

The MCP servers repository (github.com/modelcontextprotocol/servers) ships a reference memory server: @modelcontextprotocol/server-memory. It is a knowledge graph-based persistent memory system. You run it locally with:

npx -y @modelcontextprotocol/server-memory

And configure it in your MCP client (Claude Desktop, Cursor, etc.) as:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

It stores entities, observations, and relations as a local knowledge graph. Good for: lightweight, local-only memory for a single agent. Limitation: the knowledge graph format is not human-readable YAML — you inspect it through the tool API, not a text editor — and it is designed for single-agent, single-machine use, not cross-runtime persistence.

PLUR (open engram format via MCP)

PLUR (Apache-2.0, github.com/plur-ai/plur) ships an MCP server that exposes its engram engine. Each memory — an "engram" — is a human-readable YAML entry with an id, statement, type, domain, scope, confidence, and provenance. The MCP tools include plur_learn (create an engram), plur_recall (search by topic), plur_inject (get relevant engrams for a task), plur_forget (delete by id or query), and plur_feedback (rate relevance to improve injection quality).

Because it is MCP-compatible, the same memory follows an agent across Claude Code, Hermes, OpenClaw, Cursor, and any other MCP-compatible runtime. And because the format is plain-text YAML, you can open any engram in a text editor, put the memory store under version control, correct a single fact mid-conversation, and prove erasure by removing the entry — with the store under git, the diff is your audit trail.

Good for: agents that need portable, inspectable, correctable memory across multiple tools and model providers.
Limitation: newer project, less production-tested than the reference server at scale.

OpenMemory (Mem0's local MCP memory server)

OpenMemory (mem0.ai/openmemory) is Mem0's official MCP memory server: a private, local memory layer that runs on your own machine and exposes standardized memory tools — add_memories, search_memory, list_memories, delete_all_memories — to any MCP-compatible client. Memories stay local; the same store is shared across every MCP client you connect to it.

Good for: sharing one local memory store across multiple MCP clients with Mem0's simple CRUD model.
Limitation: storage is vector-based (a local database, inspected through the built-in UI or API) — not human-readable files you can open in a text editor or diff in git.

Zep (enterprise memory via MCP)

Zep (docs.getzep.com) offers an MCP server for connecting coding agents to its agent memory platform. Zep builds a temporal knowledge graph from any input — chat, business data, documents — and serves prompt-ready context with sub-200ms retrieval. The MCP server exposes Zep's memory tools to any MCP-compatible agent.

Good for: production agents that need time-aware, high-throughput memory at enterprise scale.
Limitation: Zep's memory format is a knowledge graph and Context Lake — not a human-readable file you can diff or version-control.

Community MCP memory servers

The awesome-mcp-servers list (github.com/punkpeye/awesome-mcp-servers) catalogs dozens of community MCP servers, several with memory capabilities:

Forage (isaac-levine/forage) — Self-improving tool discovery that persists tool knowledge across sessions.
Unclick (malamut1973/unclick) — 450+ callable endpoints with persistent cross-session memory. npx @unclick/mcp-server.
Memory Vault (scotia1973-bot/api-hub) — 49 MCP tools with persistent agent memory (store/recall/search). pip install gadgethumans-api-hub-mcp.
Cortex (gzoonet/cortex) — Local-first knowledge graph that extracts entities and relationships via LLMs.
pg-mnemosyne (Janadasroor/pg-mnemosyne-mcp) — PostgreSQL-backed persistent super memory and multi-agent coordination hub.

These range from single-purpose utilities to full memory systems. The ecosystem is young and moving fast — verify current status before adopting.

How to choose an MCP memory server

If you need…	Start with
A free, local, single-agent reference implementation	`@modelcontextprotocol/server-memory`
One local vector-based memory store shared across MCP clients	OpenMemory (Mem0)
Enterprise-scale temporal memory with sub-200ms retrieval	Zep's MCP server
Human-readable, portable, correctable memory across runtimes	PLUR's MCP server
Multi-agent shared memory in PostgreSQL	pg-mnemosyne
Quick utility memory without infra	Unclick or Memory Vault

The underlying decision is the same one that runs through all of agent memory: what do you need to own? If you need memory that is portable across agent runtimes, inspectable in a text editor, correctable mid-conversation, and provably erasable — the format matters more than the transport. MCP makes the transport open; the format is the differentiator.

FAQ

Is there an MCP server for AI agent memory? Yes. The official MCP servers repository includes @modelcontextprotocol/server-memory (a knowledge graph memory server). Third-party memory servers — PLUR, Zep, Mem0's OpenMemory, and several community projects — also expose agent memory through MCP. Any MCP-compatible agent (Claude Code, Cursor, Hermes, OpenClaw) can connect to any of them.

What is the MCP memory server? The reference implementation is @modelcontextprotocol/server-memory, a knowledge graph-based persistent memory system. Run it with npx -y @modelcontextprotocol/server-memory and configure it in your MCP client. It stores entities, observations, and relations as a local knowledge graph.

Does MCP define a memory format? No. MCP defines the transport (JSON-RPC 2.0) — how an agent talks to a memory server — but not what the memories look like inside. Two MCP memory servers can be fully protocol-compatible and store memory in completely different formats (vector embeddings vs human-readable YAML, for example). The format is the differentiator.

Can I use MCP memory with Claude Code? Yes. Claude Code supports MCP servers. Add a memory server to your MCP configuration and Claude Code can call its tools — store, recall, search — to persist and retrieve memory across sessions.

What is the difference between MCP memory and CLAUDE.md? CLAUDE.md is a static file of instructions you write, loaded at the start of every Claude Code session. An MCP memory server is a dynamic system the agent can call during a conversation — it stores, searches, updates, and forgets memory items programmatically. CLAUDE.md is the simplest form of persistent context; an MCP memory server is for structured, accumulating, queryable memory.

Is Fine-Tuning or Memory Better for Teaching an AI New Facts?

gregor — Mon, 13 Jul 2026 15:18:58 +0000

Is Fine-Tuning or Memory Better for Teaching an AI New Facts?

Fine-tuning bakes new facts into a model's weights through gradient updates; agent memory stores them in an external layer the model reads at runtime. For teaching an AI agent new facts — user preferences, project decisions, domain knowledge that changes — external memory wins on four dimensions: it is cheaper to update (seconds vs hours of GPU compute), inspectable (you can see what the model "knows"), deletable (you can remove a fact without retraining), and portable (memories transfer across models; fine-tuned weights do not). Fine-tuning excels at changing behavior — tone, format, style — but for storing facts an agent must recall accurately and update on demand, a memory layer is the right tool. The hidden cost of fine-tuning for factual knowledge is what we call the parallel learning tax: every new fact requires retraining the entire model, and every update to one fact risks degrading others through catastrophic forgetting.

The pain: why fine-tuning for facts is expensive

You taught your AI agent a new fact: the database moved from PostgreSQL to MySQL. Three problems follow.

Problem 1: Retraining cost. Fine-tuning is a compute-intensive process. You must prepare training data, run gradient descent on GPU clusters, evaluate the result, and deploy a new model checkpoint. For a single fact, that is absurd. For facts that change weekly — API endpoints, user preferences, project decisions — it is unsustainable. OpenAI's own documentation recommends prompt engineering and retrieval (RAG) as the first approaches for adding knowledge, reserving fine-tuning for cases where you need to customize model behavior — tone, format, response structure — not for injecting facts (developers.openai.com/api/docs/guides/model-optimization).

Problem 2: The unlearning problem. When a fact changes or must be deleted — a user requests erasure under GDPR Article 17, or an API endpoint is deprecated — removing it from fine-tuned weights is notoriously difficult. Bourtoule et al. (arXiv:1912.03817) formalized this as the "machine unlearning" problem: once a data point is baked into model weights through training, it cannot be selectively removed without either retraining from scratch or using specialized training-time techniques (like SISA training) that must be planned before fine-tuning. You cannot look inside the weights, find the fact, and delete it. With an external memory layer, deletion is a single operation: remove the memory item from the store.

Problem 3: Vendor lock-in. Facts baked into GPT-4's fine-tuned weights stay in GPT-4. They do not transfer to Claude, to Llama, to Gemini. When the model is deprecated or you switch providers, the knowledge is lost — you must re-fine-tune the new model from scratch. External memory is model-agnostic: the same memory store works with any LLM, because the knowledge lives outside the model and is injected into the prompt at session start.

What fine-tuning is good at

Fine-tuning is not wrong — it is a tool for a different job. The distinction is between behavior and knowledge:

Fine-tuning is for…	Memory is for…
Changing response tone (more formal, more concise)	Storing user preferences (prefers TypeScript, uses Vitest)
Learning output format (JSON schema, markdown structure)	Remembering project decisions (we chose PostgreSQL)
Acquiring a skill (writing SQL, generating tests in a framework)	Tracking facts that change (API endpoint moved, schema updated)
Style transfer (matching a brand voice)	Correcting mistakes (the agent was wrong about X)
Behavioral patterns that should be consistent across all interactions	Episodic knowledge that accumulates over sessions

Fine-tuning modifies the model's parameters — how it generates. Memory modifies the model's context — what it knows right now. These are complementary layers, not alternatives. A well-designed agent uses fine-tuning for stable behavioral patterns and memory for evolving factual knowledge.

The parallel learning tax

Every time you teach a fine-tuned model a new fact, you pay a tax. The model must be retrained — or at least incrementally fine-tuned — on the new data. But gradient-based learning does not write facts cleanly into isolated slots. New training data interferes with existing weights, and the model may degrade on previously learned tasks. This is called catastrophic forgetting — the model learns the new fact but partially forgets old ones.

The parallel learning tax is the total cost of this cycle:

Compute cost — GPU hours for every fine-tuning run.
Evaluation cost — you must test the model after each update to verify it did not regress on existing capabilities.
Latency cost — the fact is not available until the fine-tuning run completes and the new checkpoint is deployed.
Forgetting cost — the risk that the new fine-tuning degraded previously learned knowledge, requiring further correction runs.

With an external memory layer, the tax is zero. You write the fact to the store (milliseconds, no GPU). It is available immediately at the next session. It does not interfere with existing memories. And if it is wrong or outdated, you delete it — one operation, no retraining. (Full definition: plur.ai/parallel-learning-tax.)

Property	Fine-tuning	Agent memory
Time to teach a new fact	Hours (data prep + GPU training + eval)	Milliseconds (write to store)
Cost per fact	GPU compute per run	Storage cost (negligible)
Inspection	Opaque — cannot see what the model "knows"	Transparent — read the memory store
Deletion	Machine unlearning (notoriously difficult; arXiv:1912.03817)	Delete the memory item (one operation)
Portability	Locked to the fine-tuned model	Model-agnostic (any LLM reads the same store)
Update risk	Catastrophic forgetting (new data degrades old)	No interference (memories are independent)
GDPR compliance	Requires retraining from scratch or SISA training	Delete the memory item, done
Latency to availability	Hours (deploy new checkpoint)	Immediate (available next session)

What the research says

Zhang et al. (arXiv:2404.13501) frame the distinction clearly: agent memory is what enables "self-evolving capability" — the ability of agents to improve through experience rather than retraining. Their survey organizes the field around memory as a separate module from the model, not as modifications to model weights.

Packer et al. (arXiv:2310.08560) demonstrated this empirically with MemGPT: by managing memory externally in tiers (core memory in the context window, archival memory retrieved on demand), agents dramatically outperform models that try to hold everything in the context window or rely on fine-tuning. The OS-inspired insight: agents need managed memory, not more parameters.

Park et al. (arXiv:2304.03442) showed that generative agents — which store experiences as natural-language memory records, synthesize them into reflections, and retrieve them dynamically — produce more believable behavior than agents relying on parametric knowledge alone. The memory architecture, not the model weights, is what made the agents feel like they had continuity and personality.

When fine-tuning is the right answer

Fine-tuning is the right tool when:

You need to change the model's behavior across all interactions (tone, format, style).
You have a stable dataset that does not change frequently.
You need latency-free behavioral changes at inference time (fine-tuning eliminates the need to include style instructions in every prompt).
You are working with a model you will use for a long time, so the lock-in cost is acceptable.

Fine-tuning is the wrong tool when:

You need to teach facts that change (API endpoints, user preferences, project decisions).
You need to inspect what the model knows and correct individual facts.
You need to delete specific knowledge (GDPR right to erasure, compliance, stale information).
You need knowledge to transfer across models or providers.
Facts need to be available immediately (not after a training run).

The landscape: memory layers vs fine-tuning

Approach	What it does	Cost per fact update	Inspectable?	Deletable?	Portable?
Fine-tuning	Bakes facts into model weights	GPU hours	No	No (unlearning)	No
RAG	Retrieves from a fixed document corpus	Add document to index	Yes (documents)	Yes (remove document)	Yes
Mem0 (Apache-2.0, ~60K stars)	External memory layer with CRUD API	Milliseconds	Yes (API)	Yes (delete call)	Yes
Letta (Apache-2.0, ~24K stars)	Stateful agent OS with memory blocks	Milliseconds	Yes (block API)	Yes (replace block)	Yes
Zep/Graphiti (Apache-2.0, ~28K stars)	Temporal knowledge graph	Milliseconds	Yes (graph query)	Yes (remove edge/node)	Yes
PLUR (Apache-2.0, ~215 stars)	Local-first YAML engrams via MCP	Milliseconds	Yes (text editor)	Yes (delete entry)	Yes

RAG and agent memory both avoid the parallel learning tax, but they serve different needs: RAG retrieves documents you already have; agent memory stores what the agent learned from interactions. See RAG vs. Agent Memory for that comparison.

FAQ

Is fine-tuning or memory better for teaching an AI new facts? For factual knowledge that changes or must be inspectable, memory is better. Fine-tuning is designed for changing model behavior (tone, format, style), not for storing facts. Fine-tuning a fact into model weights requires GPU compute, cannot be inspected or selectively deleted, risks catastrophic forgetting, and locks the knowledge into one model. A memory layer writes facts in milliseconds, is fully inspectable, can delete individual facts, and works with any LLM.

What is the parallel learning tax? The parallel learning tax is the total cost of teaching a fine-tuned model a new fact: GPU compute for retraining, evaluation to verify no regression, latency while the training runs, and the risk of catastrophic forgetting — where new training data degrades previously learned knowledge. With an external memory layer, the tax is zero: facts are written in milliseconds with no GPU, no retraining, and no interference with existing memories.

Can fine-tuning and memory be used together? Yes, and they should be. Fine-tune for stable behavioral patterns (tone, format, response structure) and use memory for evolving factual knowledge (preferences, decisions, corrections). These are complementary layers: fine-tuning modifies how the model generates; memory modifies what the model knows right now.

What is catastrophic forgetting? Catastrophic forgetting is a phenomenon in machine learning where training a model on new data causes it to degrade on previously learned tasks. When you fine-tune a model with a new fact, the gradient updates modify the same weights that encode existing knowledge, potentially degrading it. External memory avoids this because each memory item is stored independently — adding a new fact does not modify existing memories.

How does GDPR right to erasure work with fine-tuned models? Poorly. GDPR Article 17 gives individuals the right to have their data deleted. If personal data was baked into model weights through fine-tuning, removing it requires "machine unlearning" — a notoriously difficult problem (Bourtoule et al., arXiv:1912.03817) that typically requires retraining the model from scratch or using specialized training-time techniques. With an external memory layer, deletion is a single operation: remove the memory item from the store. See Editable and Auditable Agent Memory for details.

Does fine-tuning make the model smarter? No. Fine-tuning adjusts the model's weights to produce different output patterns — it does not add general intelligence. It can make the model better at a specific task (by training on task-relevant examples) or change its style, but it cannot add knowledge the model can inspect, correct, or selectively forget. For accumulating factual knowledge over time, a memory layer is the appropriate mechanism.

DEV Community: gregor

Is There an Open Standard for AI Agent Memory Engrams?

Is There an Open Standard for AI Agent Memory Engrams?

The problem standardization is meant to solve

What a standard would need to define

What exists today

Procedural memory: agentskills.io (standardized)

Semantic and episodic memory: no adopted standard yet

The Model Context Protocol gap

Why this matters for developers

FAQ

Mem0 vs PLUR: Which AI Agent Memory Layer Should You Use?

Mem0 vs PLUR: Which AI Agent Memory Layer Should You Use?

How each one works

Mem0

PLUR

Key differences

When Mem0 fits better

When PLUR fits better

Can you use both?

FAQ

Related

Sources

What Memory Layer Works with Cursor or Codex?

What Memory Layer Works with Cursor or Codex?

Why "context window" is not the same as "memory"

Cursor: three-minute setup via MCP

Step 1: Add PLUR to your Cursor MCP config

Step 2 (optional but recommended): Install Cursor hooks

Step 3: Verify

What happens automatically

What Cursor's built-in features already handle

Codex CLI: what's supported

The memory store is shared across tools

Sync across machines

Frequently asked questions

How to Choose a Memory System for Autonomous AI Agents

How to Choose a Memory System for Autonomous AI Agents

Why model-native memory does not work for autonomous agents

The three memory requirements for autonomous agents

1. Crash-safe persistence

2. Cross-session continuity

3. Programmatic read/write at runtime

Comparing the main options

Decision guide

Practical setup: PLUR for an autonomous agent

FAQ

Sources

Is AI Agent Memory GDPR Compliant? A Developer's Guide

Is AI Agent Memory GDPR Compliant? A Developer's Guide

What GDPR Article 17 Actually Requires

Where Common Memory Architectures Fail

Embedding-based storage (Mem0, most RAG systems)

Stateful agent memory (Letta / MemGPT)

Knowledge graph memory (Zep / Graphiti)

Open-Format Memory and Verifiable Deletion

Implementing the Right to Be Forgotten: A Practical Checklist

1. Attribute every memory unit to a data subject

2. Build a search-by-subject function

3. Implement delete-all-for-subject

4. Propagate to sub-processors

5. Create an audit trail

6. Test deletion before you need it

EU AI Act Considerations

Summary Table

FAQ

How to Delete Specific Things an AI Remembers About You

How to Delete Specific Things an AI Remembers About You

Deleting memories from consumer AI assistants

ChatGPT (OpenAI)

Claude Projects (Anthropic)

Microsoft Copilot

Google Gemini

The proof problem: why "deleted" does not always mean gone

Deleting memories in developer agent systems

Memory systems and deletion capability

Implementing deletion in PLUR

GDPR and the right to erasure

For developers: a checklist for deletion-ready agent memory

FAQ