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

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:

1. Extraction: an LLM pass identifies "memory-worthy" content from the conversation (user facts, preferences, stated goals)
2. Deduplication: a second LLM pass checks the candidate against existing memories and resolves conflicts
3. Storage: deduplicated memories land in a vector database (25+ supported backends, including Qdrant, Pinecone, Weaviate, pgvector)
4. 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