DEV Community: gregor

What's the Difference Between Open Engrams and Model-Native Memory?

gregor — Sat, 29 Aug 2026 06:11:58 +0000

What's the Difference Between Open Engrams and Model-Native Memory?

Model-native memory is locked to the vendor that created it. Open engrams are a portable, developer-controlled memory format that any model in your stack can read. ChatGPT, Claude, and Gemini each have their own built-in memory systems — useful within their own interfaces, but siloed: what ChatGPT learns about you never reaches Claude, and vice versa. Open engrams (the format used by PLUR) are structured memory units stored locally in a format you own, so any model, tool, or agent workflow can read and write the same memory store without crossing a vendor boundary.

The Problem: Your Memory Is Fragmented Across Vendors

If you use multiple AI tools — and most developers do — your context is split across closed silos:

ChatGPT Memory stores up to ~1,500 words of extracted facts tied to your OpenAI account. When you open Claude or Cursor to continue the same project, it knows nothing about you (source).
Gemini's memory doesn't sync to ChatGPT or Claude (source).
Claude's memory for managed agents is in public beta — cross-session recall within Claude, not portable outside it (source).

This is a structural problem: every vendor solves memory for their own surface, not for your workflow. When you run a multi-agent pipeline that touches Claude Code, a Hermes agent, and a custom CLI tool, there is no shared memory layer unless you build one.

What Is Model-Native Memory?

Model-native memory is memory managed and controlled by the model vendor:

Feature	Typical model-native memory
Storage location	Vendor cloud
Who controls what's stored	The model (implicit extraction)
Portability	Locked to one vendor
Auditability	Limited — you can view some, rarely edit raw data
API access	Proprietary or none
Works across models	No

ChatGPT Memory uses implicit extraction: the model decides what to save from your conversations. You can view and delete memories, but you can't query them programmatically or export them to another tool in a structured format (source). Claude's managed-agent memory is similar: optimized for recall within Claude, not designed to be read by a Cursor plugin or a Python script.

This is appropriate for consumer chat use cases. It is not appropriate for agent workflows where memory needs to cross tool and model boundaries.

What Are Open Engrams?

An engram is a single, structured unit of memory: a statement, a type, a confidence score, and metadata — stored in a format you own.

{
  "statement": "Use snake_case for all database column names in this project.",
  "type": "architectural",
  "domain": "conventions",
  "confidence": 0.95
}

The open engram format (used by PLUR) is:

Feature	Open engrams
Storage location	Local SQLite on your machine
Who controls what's stored	You or your agent, explicitly
Portability	Any MCP-compatible model or tool
Auditability	Full — inspect, edit, or delete any engram
API access	MCP tools: `plur_learn`, `plur_recall`, `plur_recall_hybrid`
Works across models	Yes — Claude, Cursor, Hermes, custom agents

Because engrams are stored in a local SQLite file and accessed via the Model Context Protocol, any model in your stack can read the same memory. Claude Code, a Hermes agent, and a custom Python script all see the same engram store.

Side-by-Side Comparison

Dimension	Model-native memory	Open engrams (PLUR)
Portability	Vendor-locked	Any MCP client
Transparency	Opaque synthesis	Every engram readable
Control	Implicit background extraction	Explicit, developer-driven
Auditability	View + delete (limited)	Full CRUD on every record
Staleness handling	Contradictions accumulate silently	Confidence decay + retirement
Infrastructure	Vendor cloud	Local-first, you own the data
Cross-model	No	Yes
Works for agent workflows	Limited	Designed for it

They Do Different Jobs — Use Both

Model-native memory and open engrams are not in competition. They target different jobs:

Model-native memory is best for conversational continuity within one vendor's surface — remembering your name, your preferences for that product, the last project you discussed.
Open engrams are best for programmable, portable recall across agent workflows — conventions, corrections, project context, facts that need to survive across models, tools, and sessions.

The question to ask is: who needs to read this memory? If the answer is "just ChatGPT," model-native memory is fine. If the answer is "my Claude Code session, my Hermes agent, and my custom script," you need open engrams.

Getting Started

PLUR is an open-source memory layer that implements the open engram format. Install the MCP server and your memory is instantly available to any MCP-compatible client:

npx @plur-ai/mcp init

After setup, call plur_learn to write an engram and plur_recall or plur_recall_hybrid to retrieve it — from any model in your stack.

FAQ

Can I use open engrams alongside ChatGPT or Claude memory?
Yes. They operate at different layers. Model-native memory handles session context within a vendor's product; open engrams handle portable, cross-model recall. Running both is the recommended setup for developers who use multiple AI tools.

Is the open engram format a specification or a product?
Both. The open engram format is a specification for how memory units are structured. PLUR is an open-source implementation of that specification. The goal is to prevent vendor lock-in at the memory layer the same way SQLite prevents vendor lock-in at the storage layer.

Do I have to choose one model to use PLUR?
No. PLUR connects to any MCP-compatible client — Claude Code, Cursor, Hermes agents, and custom applications. You write to one engram store; every tool reads from it.

mem0, Letta, and PLUR: Three Memory Architectures, Three Different Bets

gregor — Sat, 22 Aug 2026 02:16:19 +0000

The short answer: mem0 solves memory as a storage problem — extract facts
from conversations, deduplicate them with an LLM, store them in a vector
database. Letta solves memory as an agent OS problem — build a runtime where
memory is natively managed in a persistent process. PLUR solves memory as an
exchange problem — make engrams portable across every tool the agent touches,
decay stale knowledge, and let agents share what they learn. The architectures
are not competing for the same user. They make different bets about where the
constraint is.

What the memory problem actually is

AI agents are stateless by default. The context window resets between sessions.
A correction made on Monday is gone on Tuesday. A convention established in one
tool is invisible to another.

Every memory system answers this the same way at the surface: attach persistent
storage, store what was learned, retrieve it next time. The architectural question
is not whether to store it, but where, what format, how to retrieve it, and what
happens when facts age or conflict.

Three projects have built serious answers to these questions. Each chose a
different layer to optimize for.

mem0: memory as a storage service

mem0 ($24M raised, 52,000 GitHub stars as of mid-2026) frames memory as a
managed API. Your agent makes calls to m.add() and m.search(). mem0 handles
extraction, deduplication, and retrieval. The internal architecture follows a
layered pipeline:

Extraction: an LLM pass identifies "memory-worthy" content from the conversation (user facts, preferences, stated goals)
Deduplication: a second LLM pass checks the candidate against existing memories and resolves conflicts
Storage: deduplicated memories land in a vector database (25+ supported backends, including Qdrant, Pinecone, Weaviate, pgvector)
Retrieval: similarity search returns the top-N memories for a given query

This is clean. The API surface is minimal. Dropping it into an existing agent
requires fewer than ten lines of code. The graph memory extension (mem0 v0.2+)
adds relationship storage: "user likes Python" becomes an edge in a property
graph, enabling richer associative recall.

Where the tradeoffs live:

The LLM extraction step is also the cost step. Every conversation turn that
might generate new memory triggers an LLM call to decide what to keep. At
scale, that adds up — and the extraction quality depends on the model you route
it through. Cheaper models miss nuanced corrections. Better models are expensive
per extraction pass.

Memory in mem0 also doesn't decay. A preference stored twelve months ago has
the same retrieval weight as one stored yesterday. For long-running agents with
months of accumulated context, this means increasingly noisy retrieval: the
agent surfaces old preferences that no longer apply alongside current ones. The
deduplication pass catches direct contradictions ("user prefers Python" vs "user
now prefers Go") but misses obsolescence. The gradual drift where old facts
become irrelevant without being explicitly contradicted is invisible to it.

mem0 is a single-agent silo. The memory accumulated in your Claude Code
integration does not propagate to your Cursor integration or your Slack bot.
Each agent instance has its own memory store.

Letta: memory as agent operating system

Letta ($10M raised) takes a different approach. Rather than attaching memory to
an agent as a service, Letta builds the agent runtime itself so that memory is
natively managed in a persistent process. The key abstraction is the MemGPT
architecture (from the 2023 paper by Packer et al.,
arXiv:2310.08560): a hierarchical memory
system where an LLM manages its own context window, explicitly paging information
in and out of different memory tiers.

The Letta runtime maintains four memory regions:

Core memory: always-in-context, persona and user facts (bounded, ~2K tokens)
Recall memory: searchable conversation history (vector store, queried on demand)
Archival memory: unbounded long-term storage (queried via explicit function calls)
Working context: current task state

The agent itself, running as a Letta server process, decides when to search
archival memory, when to page content into core memory, and when to write new
facts. Memory management is not a side channel: it's a first-class capability
the agent exercises as part of its reasoning loop.

Where the tradeoffs live:

Letta's strength is coherence. Because the agent controls its own memory, there
is no lossy extraction step — the agent decides what matters. Corrections are
explicit. Contradictions are resolved in the reasoning loop, not in a
post-hoc LLM deduplication pass.

The cost is infrastructure. Running Letta means running a persistent agent
server. The stateful process model makes Letta well-suited for long-running
autonomous agents but poorly suited for tools where you want memory to follow
the user across different surfaces. A correction made in a Letta agent does not
carry over to your IDE's code assistant, your email client's AI assistant, or
any other tool outside the Letta runtime.

Like mem0, Letta does not implement confidence decay. Memories are managed by
the agent's reasoning, not by a time-weighted retrieval system. An agent that
hasn't been asked about a topic in six months has no mechanism to let that
knowledge age out. It stays in archival memory at full retrieval weight.

PLUR: memory as exchange layer

PLUR takes a structurally different position. Rather than building a better
storage service or a smarter agent runtime, PLUR builds the layer that makes
memory portable and tradeable across tools.

The core unit is the engram — an atomic, typed assertion stored as a
human-readable YAML file in ~/.plur/. An engram looks like this:

id: ENG-2026-0412-001
statement: "Deploy target for the trading module is nightshift.internal:8080 — use rsync, not scp"
type: procedural
domain: infrastructure.deploy
confidence: 0.85
created: 2026-04-12
last_verified: 2026-07-01

Every engram carries a confidence score. The retrieval system is
feedback-trained: when an injected engram helps, its score rises. When it
doesn't surface anything useful, it decays. Engrams that haven't been confirmed
useful in a long time are candidates for retirement — the system forgets them,
exactly as human long-term memory culls information that hasn't been reinforced.
The activation model is derived from ACT-R (Anderson et al., "An Integrated
Theory of the Mind," Psychological Review, 2004), where memory strength is a
function of recency and frequency of use.

Retrieval: three modes, one local stack

PLUR's retrieval stack is fully local — no API calls required:

BM25 only: 15ms synchronous, zero dependencies. Used in hot path when latency matters
Hybrid BM25 + embeddings: ~2s on first run, ~200ms cached, uses all-MiniLM-L6-v2 via @huggingface/transformers. Doubles Hit@K retrieval accuracy vs BM25 alone
Agentic search: ~1s async, LLM-assisted multi-step retrieval for complex queries

Merging is via Reciprocal Rank Fusion (RRF), which combines ranked lists from
sparse and dense search without requiring score normalization. On the LoCoMo
benchmark (Maharana et al., 2024 — a 300-dialog dataset testing long-term
conversation memory), agentic PLUR achieves 60% accuracy at 100% retrieval rate
and 1.0 MRR. Single-hop fact recall is 100% in agentic mode. The known weakness
is multi-hop reasoning (33%), where the system needs to chain multiple engrams
to answer a question — an area being addressed by meta-engram aggregation.

For context on the benchmark landscape: Zep with GPT-4o achieves 71.2% on
LongMemEval. Supermemory claims 98.6% using an 8-variant ensemble with
majority-vote answering. These numbers are on different benchmarks with different
setups — not directly comparable — but they situate PLUR's retrieval accuracy
in the range where it performs well on straightforward recall and lags on the
multi-hop edge.

What the exchange layer enables

The architectural difference that mem0 and Letta do not address is cross-tool
portability. Because engrams are files on disk at a standard path (~/.plur/),
every tool that integrates the PLUR MCP server reads and writes the same
engrams. A correction made in Claude Code is immediately available in Cursor,
Hermes, and OpenClaw — no sync step, no API call, no data export. The
~/.plur/ directory is the memory.

This is the "one more thing" that changes the unit of analysis. The question is
no longer "does this agent have memory?" It becomes "does the memory follow the
user, or is it trapped in one tool's silo?"

Cross-device sync is handled by the same mechanism as any file sync — git,
Syncthing, Dropbox — because the engrams are files. No proprietary sync
protocol is required.

Knowledge packs: memory as a first data product

The second capability that mem0 and Letta do not implement is the exchange
itself. PLUR ships knowledge packs — curated, versioned bundles of engrams
published to the PLUR registry. A pack might encode a project's deployment
conventions, a company's API quirks, or a hard-won debugging workflow. An agent
that installs a pack gains the knowledge immediately, without the token cost of
learning it from scratch.

The unit economics follow a simple test: is the pack price less than the token
cost of having each new agent instance re-learn the same knowledge from scratch?
For a team running ten agent instances against the same codebase, that learning
cost multiplies by ten. The pack pays it once.

This is distinct from model weights. A knowledge pack is inspectable: every
engram is readable, correctable, and deletable. You can audit what an installed
pack knows. You cannot do that with fine-tuning.

Comparing the architectures

Dimension	mem0	Letta	PLUR
Memory model	LLM extraction → vector store	Agent-managed hierarchical tiers	Atomic engrams with typed structure
Retrieval	Similarity search	Agent-initiated archival search	BM25 + embeddings + agentic (local)
Confidence decay	None	None	Feedback-trained, ACT-R activation
Forgetting	None	None (agent-managed retention)	Engram retirement on low activation
Cross-tool sharing	No	No	Yes (shared `~/.plur/` files)
Cross-device sync	Proprietary/API	Proprietary/API	File-based (git, Syncthing)
Memory portability	API-bound	Runtime-bound	Open YAML, Apache-2.0
Knowledge packs	No	No	Yes (published, versioned)
Memory exchange	No	No	Yes
Infrastructure	Managed API or self-hosted server	Persistent agent server	Local files + optional MCP server
Token cost to add memory	LLM extraction pass per addition	Included in agent reasoning	plur_learn call, no LLM pass

The token economics question

Injecting memory has a cost. The question is whether selective injection is
cheaper than full context dumps — and by how much.

A team sending a 3,000-token CLAUDE.md system prompt on every turn at $15/M
tokens (Opus pricing as of mid-2026) pays $0.045 per turn for context. At 200
turns/day per developer across a five-person team, that's $45/day for
background context most turns don't use.

PLUR's hybrid retrieval injects 5–10 engrams per turn — typically 200–400
tokens of targeted memory. At the same pricing, that's $0.003–$0.006 per turn,
a 87–93% reduction per turn before accounting for the fact that smaller context
also means shorter inference. On the Datacore benchmark (internal, n=218 tasks),
Haiku with PLUR injection outperformed Opus without memory on navigation and
discoverability tasks. Weaker models benefit most from targeted injection because
they lack the capacity to filter noise from a large, undifferentiated context
block.

mem0 adds an LLM extraction cost on top of the storage cost. Every turn that
might generate a new memory triggers an LLM call for extraction and potentially
a second call for deduplication. Letta folds the memory management cost into the
agent's reasoning budget — it pays for memory in model tokens rather than API
calls, which makes it harder to isolate but not cheaper.

Choosing between them

mem0 fits agents that need memory with minimal integration work and don't
require cross-tool sharing. If you have one agent, one integration, and want to
drop in memory without building infrastructure, mem0 is the fastest path. The
cost is the extraction overhead and the absence of decay — a tradeoff that
matters more as the memory store ages.

Letta fits long-running autonomous agents where memory coherence is critical
and the agent controls its own context. If you're building a persistent agent
that runs over weeks and needs to reason about what it knows, the MemGPT
architecture gives you that. The cost is the stateful server requirement and
the inability to share memory across different agent surfaces.

PLUR fits teams or users running agents across multiple tools, where the
same knowledge needs to follow the agent everywhere it goes. If your workflow
touches Claude Code and Cursor and a custom agent, and you want corrections to
propagate without manual re-entry, PLUR's file-based portability is the
architectural answer. The cost is a different kind of infrastructure assumption:
the engram store works best when it's maintained (reviewed, pruned) like any
accumulating knowledge base.

The architectural bet

The three architectures make different bets about where the constraint is.

mem0 bets on integration friction: developers won't build memory if it's hard
to add. The API surface is the answer. Letta bets on coherence: memory without
a reasoner managing it degrades. The stateful runtime is the answer. PLUR bets
on portability: memory trapped in one tool's silo doesn't follow the user.
The open file format and exchange are the answer.

A team could use all three simultaneously. mem0 for an isolated service agent,
Letta for a long-running autonomous planner, PLUR as the cross-tool memory layer
that connects the user's knowledge across both. The architectures compose rather
than compete.

What doesn't compose is the exchange. Memory that can only be consumed by the
system that produced it cannot be shared, curated, or priced. The knowledge a
senior engineer accumulates through six months of agent corrections stays trapped
in their instance — unusable by teammates, invisible to new hires, gone when the
tool changes.

The engram format is open. The packs are publishable. The ~/.plur/ directory
belongs to the user, not the tool vendor. Not your files, not your memory.

Benchmarks: plur.ai/benchmark · Engram specification: plur.ai/spec · Install: npx @plur-ai/mcp init

What does your agent stack look like? If you're running agents across multiple
tools, we'd like to know how you're handling memory today — open an issue or
find us on GitHub.

GTD Content Writer - Created: 2026-07-06
Status: DRAFT - Requires human review before publication

How PLUR Cut Our Agent Context Costs by 90%

gregor — Sat, 22 Aug 2026 02:16:17 +0000

The short answer: The bottleneck isn't model intelligence — it's context.
You're paying to send the same 3,000 tokens of background facts on every
turn, 90% of which the agent doesn't need. PLUR injects only what's
relevant. Haiku + PLUR now outperforms Opus without memory at 1/10th the
cost.

The problem: context is expensive and mostly irrelevant

Every AI team eventually hits the same wall. Your agent knows how to code,
write, and reason. But it doesn't know your things: your deployment servers,
your tag conventions, which of your hundred tools handles which task, the
decision you made six months ago and why.

The instinct is to put all of it in the system prompt. A CLAUDE.md or
AGENTS.md file that grows to 3,000 words. You send it on every turn — most
of it irrelevant to what the agent is doing right now.

At $15 per million tokens for Opus, that's $0.045 per turn just for the system
prompt. Multiply by a team of 5 developers, 200 turns a day each, and you're
spending $45/day on context the agent mostly ignores.

The deeper problem: it doesn't even work. An agent asked to "deploy the trading
module" doesn't need the 400-word section on Zettelkasten conventions. It needs
the 5 lines about your deploy target. Burying those 5 lines in 3,000 tokens of
noise is how you get agents that apply the wrong server or skip the smoke test.

The insight: inject, don't dump

Human experts don't memorize everything before starting a task. They pull from
memory on demand, surfacing only what's relevant to right now. An agent
should work the same way.

PLUR stores knowledge as engrams — small, typed assertions that strengthen
with use and decay when irrelevant, modeled on human memory (ACT-R activation).
Each turn, a fast local search (BM25 + BGE embeddings, no API calls) selects
the 5–10 most relevant engrams for the current task and injects only those into
context.

Instead of 3,000 tokens of background, you send 200–400 tokens of targeted
memory. The agent has exactly what it needs. Nothing it doesn't.

What this looks like in practice

# Task: "deploy the trading module to production"
# Injected automatically (5 engrams, ~280 tokens):

deploy target: nightshift (not prod) — SSH alias: nightshift
trading module lives in 0-personal/trading/
deployment: git pull + systemctl restart plur-trading
never push to main directly — PR required
smoke test: python test/smoke.py --env nightshift

No Zettelkasten conventions. No email conventions. No 40 other things that
aren't relevant right now.

The numbers

We ran head-to-head tests: the same task, the same agent, with and without
PLUR memory. 28 scenarios across Haiku 4.5, Sonnet 4.6, and Opus 4.5. The
question was whether PLUR memory changes which model wins.

Result: 31 wins, 4 losses — 89% win rate across all models.

The clearest result was house rules — tasks that require applying
organization-specific knowledge (tag conventions, file routing, deployment
procedures). Without PLUR, agents got these right 10–38% of the time depending
on model:

Config	House rules	Win rate
Opus (no memory)	38%	baseline
Sonnet (no memory)	22%	—
Haiku (no memory)	10%	—
Haiku + PLUR	12–0	89%

Haiku with PLUR memory beat Opus without memory in 89% of decisive contests.
The model didn't get smarter — it got the right context instead of noise.

On LongMemEval (retrieval
benchmark), PLUR scores 97.6% Hit@5 on the 500-question suite using hybrid
BM25 + embedding search. Zero API calls. All local.

The cost math

	Config	Cost per turn	Quality
Before	Opus + 3k-token system prompt	~$0.045	House rules: 38%
After	Haiku + PLUR injection (~300 tokens)	~$0.002	House rules: 100%

That's a 95% cost reduction with a 2.6× improvement in the tasks that
actually require knowing how your organization works.

The math holds at any scale. At 1,000 turns/day (a small team), the before/after
is ~$45/day vs ~$2/day — $43/day saved while the agent performs better.

How memory is captured

PLUR hooks into your session lifecycle. When you correct your agent, it learns:

# You say: "no, deploy goes to nightshift, not prod"
# PLUR captures automatically:
plur_learn("deploy target: nightshift (not prod) — SSH alias: nightshift")

When the agent discovers a convention or makes a decision, same thing. Over
time, it accumulates a model of how your world works — not as a static document,
but as a searchable, weighted knowledge graph.

Engrams decay. A convention from a codebase you refactored six months ago
stops appearing in context on its own. No manual curation needed.

Why not just use a smaller CLAUDE.md?

You could. But "smaller" has a ceiling — you'll always need more context than a
curated static file can hold without growing unwieldy again. And a static file
can't learn. It can't prioritize. It sends the same facts regardless of what
task the agent is doing.

PLUR's injection is task-aware. The same knowledge base surfaces different
engrams for "deploy trading module" vs "write a blog post" vs "review this PR."
The agent sees its world through the lens of what it's doing right now.

One-command install

npx @plur-ai/mcp init

Sets up storage (~/.plur/), MCP config, and Claude Code hooks in one step.
Restart your editor. Memory works from the next session.

For Cursor, Windsurf, or any MCP-compatible client:

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

Memory lives in ~/.plur/ — plain YAML files, human-readable, zero cloud
dependency. Sync across machines with plur_sync (git-based).

Open source. Apache 2.0. Works with Claude Code, Cursor, Windsurf, and any MCP
client. Python agents: pip install plur-hermes.

GitHub → · Benchmark → · Engram spec →

OpenClaw has built-in memory now. Do you still need PLUR?

gregor — Sat, 15 Aug 2026 23:22:48 +0000

OpenClaw has built-in memory now. Do you still need PLUR?

OpenClaw has had built-in cross-session memory since mid-2026 — per-session notes indexed in a local SQLite database, keyword and vector search, and one-way imports from Codex and Claude Code. For basic session continuity inside OpenClaw, you no longer need a memory plugin. But OpenClaw's memory stays inside OpenClaw. If you use more than one AI tool, if you want memory that improves with feedback rather than just accumulates, or if you ever want to share or sell what your agent has learned, PLUR is still the layer you need.

What OpenClaw's built-in memory covers

OpenClaw's native memory stores observations from your sessions — what the agent did, what you asked for, project-level context — and makes them available in future conversations within OpenClaw. This is a genuine improvement: you no longer have to re-explain your codebase conventions to an OpenClaw agent at the start of every session.

What it does not do:

Cross-tool sync — OpenClaw memory is scoped to OpenClaw. Your Claude Code agent, Cursor, Codex, and Hermes agents each start from scratch unless you run PLUR alongside.
Learning over time — OpenClaw stores what happened; it does not improve the signal. PLUR's ACT-R-inspired activation and decay model strengthens frequently-confirmed facts and quietly fades outdated ones. The memory gets better with use.
Structured, queryable format — OpenClaw memory is plain Markdown in ~/.openclaw/workspace, so it is readable and editable in any editor; its SQLite index, however, is opaque. PLUR engrams are structured YAML in ~/.plur/ — individually addressable, version-controllable, and portable across tools, with the index rebuildable from the files themselves.
Pack marketplace — PLUR's exchange layer lets you install pre-trained context packs (for a framework, a domain, a methodology) and, eventually, sell your own. OpenClaw has no equivalent.

The architecture difference

OpenClaw's native memory and PLUR solve adjacent but different problems:

	OpenClaw native memory	PLUR
Scope	Inside OpenClaw	Shared across Claude Code, Cursor, Codex, Hermes, OpenClaw
Format	Platform-managed	`~/.plur/` YAML, open spec
Learning	Accumulates	ACT-R activation + decay — improves with feedback
Inspectable	Yes — Markdown files (MEMORY.md, memory/*.md); SQLite index is opaque	Yes — edit or delete any engram
Exchange	No	Pack marketplace (Phase 3)
Enterprise governance	No	Team scopes, provenance, org-level isolation

PLUR and OpenClaw native memory are not mutually exclusive. Developers who install PLUR alongside OpenClaw get both: OpenClaw's fast in-platform recall, plus engrams that carry institutional knowledge across every tool they use.

When you only need OpenClaw memory

If you work exclusively in OpenClaw, your context is simple, and you have no interest in sharing knowledge across tools or agents, OpenClaw's built-in memory is likely enough. It is free, requires no setup, and covers the most common case: not re-explaining yourself at the start of a new conversation.

When PLUR adds the most value

You use Claude Code, Cursor, Codex, or Hermes alongside OpenClaw and want a unified memory layer.
Your team has hard-won conventions, decisions, or domain knowledge you want every agent to know — regardless of which tool they run in.
You want memory that improves: confirmed facts activate, stale facts fade.
You want to inspect, edit, or selectively forget what the AI remembers — with full auditability.
You want to install a pre-trained context pack for a framework or domain instead of bootstrapping from scratch.

Getting started

npx @plur-ai/mcp init

This installs PLUR's MCP server, creates ~/.plur/, and wires the session hooks for your configured tools. Engrams written by one tool are readable by all of them. Full install guide →

If you're using OpenClaw specifically, you can also install PLUR as a native OpenClaw plugin: openclaw plugins install @plur-ai/claw — this wires PLUR's engram layer directly into OpenClaw's Context Engine.

Sources: OpenClaw memory concepts; OpenClaw built-in memory; PLUR engram spec; github.com/plur-ai/plur

How Do I Use Memory in Long-Running Agent Loops?

gregor — Thu, 13 Aug 2026 16:11:05 +0000

How Do I Use Memory in Long-Running Agent Loops?

Long-running agent loops — autonomous workflows where an AI agent operates for hours or days, making decisions, calling tools, and accumulating state — hit a wall that short interactions do not: the context window fills up. Once it does, one of three things happens: the agent drops early context and forgets decisions it made (context drift), the agent re-does work it already completed because it lost the memory of doing it (redundant work), or the agent errors out when the context window overflows. The fix is external memory: a persistent store the agent reads from and writes to throughout the loop, so accumulated knowledge survives context window eviction. Research from MemGPT (tiered memory management, arXiv:2310.08560), Voyager (lifelong learning via skill libraries, arXiv:2305.16291), and Reflexion (verbal reinforcement via episodic memory, arXiv:2303.11366) converges on the same architecture: agents need managed external memory — not bigger context windows — to operate coherently over long horizons.

The pain: what breaks when an agent runs too long

An agent starts a long-running task: refactor a codebase, research a market, process a dataset, or manage a multi-step deployment. It makes decisions, calls tools, reads results, and generates next steps. Each interaction adds tokens to the context window. After enough turns, the context window is full — and the agent's behavior degrades in three ways.

Context drift. As the context window fills, earlier context is evicted (or compressed, or simply lost in attention). The agent forgets the decision it made at step 3 — "we chose PostgreSQL" — and may contradict it at step 40. Packer et al. (arXiv:2310.08560) identified this as the core limitation of LLMs in extended interactions: "limited context windows, hindering their utility in tasks like extended conversations and document analysis." The solution they proposed — MemGPT's virtual context management — is essentially an external memory tier the agent manages itself, moving information between fast (in-context) and slow (external) memory as needed.

Redundant work. Without persistent memory, the agent cannot recall that it already tried an approach and failed. It re-attempts the same API call, re-reads the same file, re-runs the same analysis. Shinn et al. (arXiv:2303.11366) demonstrated this with Reflexion: agents that maintain an "episodic memory buffer" of past attempts — what worked, what failed, why — make better decisions on subsequent trials. The memory buffer is not a context window; it is a separate, persistent store of distilled lessons the agent reads before acting.

Decision amnesia. In a long loop, the agent makes a sequence of decisions: which approach to take, which file to edit, which API to call. Without memory, it cannot reconstruct why it made an earlier decision — it only sees the current context window. This leads to inconsistent behavior: the agent may undo its own earlier work, or take an approach that contradicts a constraint it established ten steps ago. Wang et al. (arXiv:2305.16291) showed that Voyager, a lifelong learning agent, solves this with an "ever-growing skill library" — a persistent store of executable skills the agent builds up over time. The skills are "temporally extended, interpretable, and compositional," which "compounds the agent's abilities rapidly and alleviates catastrophic forgetting." The skill library is external memory; the model's weights never change.

The architecture: memory as a separate module

The research literature on agent memory converges on a single architectural principle: memory should be a separate module from the model, not stuffed into the context window.

Zhang et al. (arXiv:2404.13501) organize the field around memory as "the key component to support agent-environment interactions" — the basis for "self-evolving capability." Their survey identifies multiple memory types (short-term, long-term, episodic, semantic) and multiple operations (read, write, reflect, forget), all operating on a store external to the model.

Sumers et al. (arXiv:2309.02427) proposed CoALA (Cognitive Architectures for Language Agents), a framework that describes agents with "modular memory components, a structured action space to interact with internal memory and external environments, and a generalized decision-making process." The memory is modular — it has its own structure, its own operations, and its own lifecycle — separate from the model's parameters or the context window.

Park et al. (arXiv:2304.03442) demonstrated this with generative agents that "store a complete record of the agent's experiences using natural language, synthesize those memories over time into higher-level reflections, and retrieve them dynamically to plan behavior." The architecture has three layers: observation (what happened), reflection (what it means), and retrieval (what is relevant right now). Memory is not just storage — it is an active process of consolidation and recall that makes the agent more coherent over time.

Practical approaches to memory in long-running loops

1. Tiered memory (MemGPT pattern)

The agent manages memory in tiers: a small "core memory" in the context window (the current task, key facts), and a larger "archival memory" outside the context window (historical context, past decisions, learned lessons). The agent moves information between tiers as needed — promoting relevant archival memories to core when they become pertinent, and demoting stale core memories to archival when they are no longer active.

This is the approach Packer et al. (arXiv:2310.08560) demonstrated with MemGPT. The agent "intelligently manages different memory tiers in order to effectively provide extended context within the LLM's limited context window." The OS metaphor is apt: just as an operating system pages data between RAM and disk, the agent pages knowledge between context and external storage.

2. Episodic memory with reflection (Reflexion pattern)

The agent maintains an episodic memory buffer — a log of past attempts, outcomes, and verbal reflections. Before each new attempt, the agent reads the relevant reflections to avoid repeating mistakes and to build on past successes.

Shinn et al. (arXiv:2303.11366) showed that this "verbal reinforcement learning" — reinforcing the agent through linguistic feedback stored in memory, not through weight updates — produces significant improvements across coding, decision-making, and reasoning tasks. The key insight: the agent learns from its own experience without retraining.

3. Skill libraries (Voyager pattern)

The agent builds a library of reusable skills — executable code, procedures, or strategies — as it works. Each skill is stored externally and indexed for retrieval. When the agent encounters a similar task, it retrieves and composes existing skills rather than starting from scratch.

Wang et al. (arXiv:2305.16291) demonstrated that this approach enables "lifelong learning" — the agent "continuously explores the world, acquires diverse skills, and makes novel discoveries without human intervention." The skill library "compounds the agent's abilities rapidly and alleviates catastrophic forgetting" because skills are stored externally, not in weights.

4. External memory via MCP (the open-standard pattern)

The Model Context Protocol (MCP, specification 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. An MCP-compatible memory server gives any MCP-compatible agent runtime access to a persistent memory store.

The agent calls memory tools (recall, learn, forget, feedback) as part of its normal loop. Memory is not stuffed into the context window — it is retrieved on demand, like a database query. The memory store persists across sessions, across agent restarts, and across model switches. Open engram implementations like PLUR expose memory over MCP, so any agent runtime — Claude Code, Hermes, OpenClaw, Cursor — can read from and write to the same memory store.

Approach	Memory type	Persistence	How it works	Best for
Tiered memory (MemGPT)	Core + archival	Session	Agent manages memory tiers, paging between context and external storage	Extended conversations, document analysis
Episodic + reflection (Reflexion)	Episodic buffer	Trial-based	Agent reflects on past attempts, stores verbal lessons, reads before next attempt	Iterative tasks, coding, reasoning
Skill library (Voyager)	Procedural	Lifelong	Agent builds reusable skills, indexes for retrieval, composes for new tasks	Open-ended exploration, skill acquisition
MCP memory server	External store	Cross-session	Agent calls memory tools (recall/learn/forget) over standard protocol	Cross-tool, cross-model persistent memory

What to store in long-running loop memory

Not everything belongs in the memory store. The signal-to-noise ratio matters — a memory full of irrelevant observations is as useless as no memory at all. The research suggests storing:

Decisions and rationale — what the agent decided, and why. This prevents contradiction and enables the agent to reconstruct its reasoning later.
Failed approaches — what was tried, what went wrong, what was learned. Reflexion (arXiv:2303.11366) showed this is the highest-value memory type for iterative improvement.
Skills and procedures — reusable code, validated workflows, successful strategies. Voyager (arXiv:2305.16291) showed this compounds agent capabilities over time.
Key facts — project context, user preferences, environment state that the agent needs to reference repeatedly but that does not fit in the context window.
Reflections — higher-level abstractions synthesized from observations. Park et al. (arXiv:2304.03442) showed that reflection — "synthesizing memories over time into higher-level reflections" — is what gives agents continuity and personality.

When to forget

Memory that grows without bound is its own problem. An agent that has accumulated 10,000 memory entries will retrieve noise alongside signal. The research points to several forgetting strategies:

Temporal decay — memories that have not been accessed recently lose activation. This mirrors biological memory consolidation: frequently recalled memories are reinforced; unused ones fade.
Feedback-driven relevance — memories that were useful (the agent acted on them and the outcome was positive) are promoted; memories that were not useful are demoted.
Consolidation — multiple related observations are synthesized into a single higher-level reflection, and the raw observations are discarded. Park et al. (arXiv:2304.03442) demonstrated this: observations accumulate, then reflections are synthesized, then the agent retrieves reflections (not raw observations) for planning.

These forgetting strategies are not optional — they are what keep the memory store useful over long horizons. A memory system without forgetting is a log file, not a memory.

FAQ

How do I use memory in long-running agent loops? Use an external memory store that the agent reads from and writes to throughout the loop. The agent should store decisions and rationale, failed approaches, reusable skills, key facts, and synthesized reflections. Before each step, the agent retrieves relevant memories to avoid repeating mistakes, contradicting earlier decisions, or re-doing completed work. The memory store persists across context window evictions and across sessions. Research from MemGPT (tiered memory, arXiv:2310.08560), Reflexion (episodic memory, arXiv:2303.11366), and Voyager (skill libraries, arXiv:2305.16291) converges on managed external memory — not bigger context windows — as the solution.

What is context drift in AI agents? Context drift occurs when an agent's context window fills up and earlier context is evicted or compressed, causing the agent to forget decisions, constraints, or facts it established earlier in the task. This leads to inconsistent behavior, contradiction of earlier decisions, and redundant work. External memory prevents context drift by persisting key information outside the context window and retrieving it on demand.

How does MemGPT manage memory? MemGPT (arXiv:2310.08560) uses a tiered memory architecture inspired by operating systems: a small "core memory" in the context window for active information, and a larger "archival memory" outside the context window for historical context. The agent pages information between tiers — promoting relevant archival memories to core when needed, and demoting stale core memories to archival. This provides "virtual context management" that extends the effective context window.

Can AI agents learn from their mistakes during a long task? Yes — if they have memory. Reflexion (arXiv:2303.11366) demonstrated that agents which maintain an episodic memory buffer of past attempts (what was tried, what failed, why) and read from it before each new attempt produce significantly better results than agents without memory. The agent "verbally reflects on task feedback signals" and stores the reflection in memory — learning from experience without weight updates.

What is lifelong learning in AI agents? Lifelong learning is the ability of an agent to continuously acquire new skills and knowledge over time without forgetting what it already learned. Voyager (arXiv:2305.16291) demonstrated this with an "ever-growing skill library" — a persistent store of executable skills that "compounds the agent's abilities rapidly and alleviates catastrophic forgetting." The key: skills are stored externally, not in model weights, so new learning does not degrade existing capabilities.

How does MCP help with agent memory? The Model Context Protocol (MCP, modelcontextprotocol.io) is an open protocol that standardizes how agents connect to external tools and data sources — including memory servers. An MCP-compatible memory server gives any agent runtime access to persistent memory (recall, learn, forget, feedback) over a standard protocol. The memory store persists across sessions, agent restarts, and model switches. This means memory is not tied to one agent framework — it follows the agent across tools.

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

DEV Community: gregor

What's the Difference Between Open Engrams and Model-Native Memory?

What's the Difference Between Open Engrams and Model-Native Memory?

The Problem: Your Memory Is Fragmented Across Vendors

What Is Model-Native Memory?

What Are Open Engrams?

Side-by-Side Comparison

They Do Different Jobs — Use Both

Getting Started

FAQ

mem0, Letta, and PLUR: Three Memory Architectures, Three Different Bets

What the memory problem actually is

mem0: memory as a storage service

Letta: memory as agent operating system

PLUR: memory as exchange layer

Comparing the architectures

The token economics question

Choosing between them

The architectural bet

How PLUR Cut Our Agent Context Costs by 90%

The problem: context is expensive and mostly irrelevant

The insight: inject, don't dump

What this looks like in practice

The numbers

The cost math

How memory is captured

Why not just use a smaller CLAUDE.md?

One-command install

OpenClaw has built-in memory now. Do you still need PLUR?

OpenClaw has built-in memory now. Do you still need PLUR?

What OpenClaw's built-in memory covers

The architecture difference

When you only need OpenClaw memory

When PLUR adds the most value

Getting started

How Do I Use Memory in Long-Running Agent Loops?

How Do I Use Memory in Long-Running Agent Loops?

The pain: what breaks when an agent runs too long

The architecture: memory as a separate module

Practical approaches to memory in long-running loops

1. Tiered memory (MemGPT pattern)

2. Episodic memory with reflection (Reflexion pattern)

3. Skill libraries (Voyager pattern)

4. External memory via MCP (the open-standard pattern)

What to store in long-running loop memory

When to forget

FAQ

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