Agent Memory Deep Dive #2: The Memory Landscape — 10 Approaches, No Winner

Everyone has a memory library. Nobody has a memory system.

TLDR: I evaluated 10 open-source memory projects across 7 capability dimensions. They cluster into 5 archetypes: append-only stores, agent-managed virtual memory, graph-based systems, self-organizing networks, and biomimetic architectures. Each made a different bet on what matters most — integration simplicity, agent control, relationships, biological fidelity. Every bet is defensible. But there’s one capability nobody invested in: decay/forgetting. The field is in a pre-convergence state — like databases in the 1960s before the relational model won.

The Evaluation Framework

Before looking at projects, let’s define what “complete” memory looks like. Seven dimensions, derived from neuroscience (how human memory works) and production pain (what actually breaks):

#	Dimension	What it means	Why it matters
1	Episodic storage	Raw conversation log, timestamped, sequential	Source of truth. Without it, you can’t trace back to where a fact came from.
2	Semantic extraction	Structured facts pulled from conversations	Searchable knowledge. Raw transcripts are too verbose to retrieve against.
3	Graph relationships	Entities connected by typed edges	“User → prefers → TypeScript → because → type-safety.” Associations enable spreading activation.
4	Vector search	Embedding-based semantic similarity	Fuzzy recall. You don’t always know the exact words.
5	Decay / forgetting	Strength-based fade over time	Without it: stale pollution. With it: retrieval quality stays high as memory grows.
6	Multi-cue retrieval	Combines keyword + vector + graph + time + decay	No single retrieval mode covers all access patterns. Multi-cue is what makes recall feel “smart.”
7	Consolidation	Episodes → distilled knowledge (background, async)	The bridge between raw history and usable facts. Like sleep consolidation in the brain.

A system covering all seven would: capture raw conversations → extract structured knowledge in the background → link entities into a graph → search via multiple signals simultaneously → let unused memories naturally fade → all while maintaining provenance from any fact back to its source conversation.

Nothing does this today. Every project chose a subset — and most chose the same subset to skip.

5 Memory Archetypes

Archetype 1: Append-Only Stores

Mem0 (25k+ stars)

The “just add memory to your agent” solution. Three API calls: add(), search(), get_all().

How it actually works (8-phase pipeline):

Retrieve last 10 messages from session scope
Embed new messages, search for semantically similar existing memories
LLM extraction — single call produces structured facts with attributed_to and linked_memory_ids
Batch embed all extracted memory texts
MD5 deduplication (skip exact matches)
Persist to vector store (27 backend options)
Entity linking — extract named entities, store separately with back-links
Save messages for session continuity

The dedup trick: Mem0 maps memory UUIDs to integer IDs when presenting to the LLM. Models handle “0”, “1”, “2” better than UUIDs when deciding whether new facts conflict with existing ones. Small detail, big quality impact.

What it covers: Semantic extraction, vector search, hybrid retrieval (BM25 + semantic + entity boost), entity linking.

What it doesn’t: No episodic storage, no decay, no consolidation. It’s a memory layer, not a memory system. It stores facts. It doesn’t manage the lifecycle of those facts. Once something is in Mem0, it lives forever at full strength — or until you manually delete it.

SuperMemory (27k stars)

Marketed as “memory API with temporal awareness.” Interesting technical differentiator: contradiction resolution. When a new fact conflicts with an existing one, it attempts to resolve which is current.

What it covers: Vector search, semantic extraction, contradiction detection.

What it doesn’t: No episodic storage, no graph, no decay, no consolidation. Contradiction resolution is a step toward decay, but it’s binary (keep/replace) not graduated (strengthen/weaken). Real memory strength is continuous, not boolean.

Archetype 2: Agent-Managed Virtual Memory

Letta / MemGPT (23k stars)

The most intellectually sophisticated approach. Core insight from the original Berkeley paper: treat the context window like RAM and let the agent manage what’s “paged in.”

The three-tier model:

Core Memory (RAM)     — Always in context. Agent explicitly edits.
                        "human" block: what you know about the user
                        "persona" block: who you are as an agent
                        
Recall Storage (Disk) — Searchable conversation history.
                        Agent queries: conversation_search(query)
                        
Archival Storage (SAN) — Unlimited long-term knowledge.
                         Agent inserts: archival_memory_insert(content)
                         Agent queries: archival_memory_search(query)

What makes it different: The agent has tools for memory management. It can:

core_memory_append("human", "prefers TypeScript for backends")
core_memory_replace("human", "lives in SF", "lives in NYC")
archival_memory_search("database decisions")

This means memory management is an action the agent takes, not something the system does passively. The agent decides what’s worth remembering and what to evict from working memory.

What it covers: Episodic storage (recall tier), semantic extraction (agent-driven), vector search (archival).

What it doesn’t: No graph, no decay, no multi-cue retrieval (single vector similarity), no consolidation. And the cost: you need a strong model. Weaker models spend more tokens managing memory than doing actual work. You’re locked into the Letta platform — there’s no “use the memory model without the server.”

Archetype 3: Graph-Based Memory

Graphiti / Zep (production-focused)

Built by the Zep team. Uses Neo4j or FalkorDB under the hood. The key insight: memory isn’t just facts — it’s relationships between facts over time.

What it stores:

Episodic nodes (conversation events with timestamps)
Entity nodes (people, tools, concepts)
Community nodes (clusters of related entities)
Typed edges with temporal validity (“User → worked-at → Company A [2020-2024]”)

Temporal awareness: Edges have valid_from and valid_to timestamps. “Uses Express” from January doesn’t override “Uses Fastify” from March — they coexist with different temporal scopes. Queries can specify “as of now” or “as of date.”

What it covers: Episodic storage, semantic extraction, graph relationships (strongest of any system), vector search, multi-cue retrieval (graph + vector + temporal).

What it doesn’t: No native decay (temporal validity is manual, not automatic strength-based fade). Consolidation is partial (community detection clusters but doesn’t distill). And the operational tradeoff: requires Neo4j or FalkorDB running. Not embeddable. You’re running a graph database for memory.

Cognee

Similar philosophy to Graphiti but with pluggable backends. Can run on Neo4j, FalkorDB, or even NetworkX for lightweight deployments. Adds a “data processing pipeline” concept — you define how raw input gets transformed into graph nodes.

Coverage: Similar to Graphiti but with pluggable backends (less operational lock-in). Slightly less mature on temporal handling. Has configurable retention rules — closer to TTL than true strength-based decay.

Archetype 4: Self-Organizing Networks

A-MEM (1k stars)

The Zettelkasten-for-AI approach. Memory management itself is an agentic process — the system doesn’t just store and retrieve, it actively reorganizes.

How adding a new memory works:

Generate a structured note (content, tags, context, keywords, category)
Analyze against ALL existing historical memories
Establish links (semantic relationships to existing memories)
Update existing memories (adding new context, tags, links)
The knowledge network self-improves over time

The key property: Memories get richer when you add new ones. Adding “user is migrating to Fastify” doesn’t just create a new node — it updates the existing “uses Express” memory with context about the transition, links both to a “web framework” category, and adjusts tags on related memories.

What it covers: Semantic extraction (strong, auto-structured), graph relationships (auto-linking), vector search (ChromaDB).

What it doesn’t: No episodic storage, no decay, no multi-cue retrieval (vector-only query), no consolidation (enrichment ≠ distillation). And the scaling concern: every new memory is analyzed against all existing memories. At 100 memories, this is fine. At 10,000, it’s an O(n) LLM call per insertion. The cost grows linearly with knowledge.

The error propagation risk: If the LLM misjudges a relationship and corrupts a link, that corruption can spread as subsequent operations build on it. There’s no mechanism to detect or repair bad links.

Archetype 5: Biomimetic Architectures

Hindsight (16.5k stars)

The most biologically-inspired production system. Organizes memories into three structures mirroring human cognition:

World — Factual knowledge about the environment (semantic memory analog)
Experiences — Agent’s own lived interactions (episodic memory analog)
Mental Models — Higher-order understanding formed by reflection (prefrontal cortex analog)

Three operations instead of two:

Retain — Ingest and structure new information (LLM extraction → entities + relationships + temporal metadata)
Recall — 4 parallel retrieval strategies merged via reciprocal rank fusion + cross-encoder reranking
Reflect — Form new knowledge from existing memories without new input

The third operation is unique. Most systems only have write and read. Hindsight adds think — analyze existing memories to discover connections, assess risks, or identify gaps. This mirrors how humans form insights during idle time.

What it covers: Episodic storage (Experiences), semantic extraction (LLM-driven Retain), graph relationships (entities + causal/temporal links), vector search (dense + sparse), multi-cue retrieval (4-strategy fusion).

What it doesn’t: No decay (append-only). Consolidation is manual (Reflect must be triggered explicitly, not background/automatic). And the cost issue: Retain requires LLM extraction on every ingest. Reflect requires LLM reasoning over existing memories. At scale, the LLM compute cost of maintaining memory is substantial.

TencentDB Agent Memory (5.8k stars)

A progressive pyramid approach from Tencent Cloud. Available as an optional plugin for agent frameworks (including OpenClaw and Hermes), not a native component of either:

L3 — Persona      Every 50 new memories, regenerate high-level user profile
L2 — Scenario     Every 900 seconds, cluster related atoms into scenes
L1 — Atom         Every 5 conversation turns, extract atomic facts
L0 — Conversation Raw dialogue stored as-is, full fidelity

The lossless traceability property: Any L3 persona claim traces back through L2 scenes → L1 atoms → L0 raw conversation. Upper layers carry judgment; lower layers carry evidence. You can always answer “why does the system believe X?” by walking down the chain.

Working memory compression trick: Instead of keeping verbose tool outputs in context, offload them to external files (refs/*.md) and replace them with a compact Mermaid state diagram. Each node carries an ID linking back to the full text. 61% token reduction while maintaining recoverability.

What it covers: Episodic storage (L0), semantic extraction (L1), vector search (sqlite-vec), multi-cue retrieval (BM25 + vector + RRF), consolidation (L0→L1→L2→L3 pipeline — the strongest consolidation story in this list).

What it doesn’t: No graph relationships, no decay. And the practical constraint: primarily integrates with OpenClaw/Hermes via plugin adapters. No standalone generic SDK for arbitrary frameworks. If you’re not in that ecosystem, the integration cost is high.

Other Notable Approaches

Memorix (514 stars) — Cross-Agent MCP Layer

The only system designed for cross-tool memory. Works across Claude Code, Cursor, Windsurf, Copilot, and Codex via MCP protocol.

Unique: observation/reasoning split. Stores “what happened” separately from “why it happened.” Plus a third substrate: Git Memory — immutable facts derived from version history (commit messages, diffs).

What it covers: Semantic extraction, partial graph (entity linking), vector search, multi-cue (source-aware boosting). Basic exponential decay on retrieval scores.

What it doesn’t: No episodic storage, no full consolidation. Decay is rudimentary (exponential weight, not access-frequency-driven).

Memoir (579 stars) — Git-Like Version Control

Version control primitives applied to memory: branch, commit, merge, rollback, blame. Memories have hierarchical semantic paths (profile.professional.skills.python) instead of opaque vector IDs.

The token rent insight: Flat files like CLAUDE.md invalidate prefix cache on every update. Hierarchical memory enables surgical updates without cache invalidation.

What it covers: Hierarchical semantic paths, version control primitives (branch, merge, rollback, blame).

What it doesn’t: No vector search, no graph, no decay. Early-stage. But it solves a real problem (auditability, context branching) that nobody else addresses.

The Capability Coverage Map

This covers dedicated memory libraries and systems. Full agents (OpenClaw, Hermes) have native memory mechanisms covered in Post #0 but aren’t separable libraries you can adopt independently.

System	What it bet on	Episodic	Extraction	Graph	Vector	Decay	Multi-Cue	Consolidation
Mem0	Integration simplicity	-	✓	Partial	✓	-	✓	-
SuperMemory	Contradiction resolution	-	✓	-	✓	-	Partial	-
Letta/MemGPT	Agent control over memory	✓	✓	-	✓	-	Partial	-
Graphiti	Relationships over time	✓	✓	✓	✓	-	✓	Partial
Cognee	Pluggable graph backends	✓	✓	✓	✓	Partial	✓	-
A-MEM	Self-organizing knowledge	-	✓	✓	✓	-	Partial	-
Hindsight	Biological fidelity	✓	✓	✓	✓	-	✓	Manual
TencentDB	Progressive distillation	✓	✓	-	✓	-	✓	✓
Memorix	Cross-tool sharing	-	✓	Partial	✓	Partial	✓	-
Memoir	Auditability (git-like)	-	Partial	-	-	-	Partial	-

What the Coverage Map Reveals

Pattern 1: Nobody bet on decay. Every system chose a primary strength — integration simplicity, agent control, graph relationships, biological fidelity, cross-tool sharing. Reasonable bets, each defensible. But scan the Decay column: it’s nearly empty across the board. OpenClaw (a full agent, not a library) has 30-day half-life — the strongest in production, but purely time-based. Ebbinghaus-style “unused memories weaken while accessed memories strengthen” — nobody implements the full model. This is the industry’s collective blind spot.

Pattern 2: Graph and multi-cue are the highest-scoring differentiators. Systems that model relationships (Graphiti, Hindsight) consistently outscore those that don’t. The jump from vector-only retrieval to multi-cue (vector + keyword + graph + time) is where “memory search” starts feeling like actual recall.

Pattern 3: Consolidation requires architecture commitment. Only TencentDB fully implements it (L0→L1→L2→L3). Everyone else either does extraction-on-ingest (no background distillation) or requires manual “reflect” operations. Background consolidation — the equivalent of sleep — needs to be an architectural decision, not a bolt-on.

Pattern 4: Cross-tool is treated as someone else’s problem. Only Memorix even attempts it, and only for coding agents. The “index everything from everywhere” requirement — the thing users actually want — is outside every project’s scope.

The Pre-Convergence State

We’re where databases were in the 1960s. Multiple models (hierarchical, network, flat-file) competing. Each works for specific access patterns. No unified theory.

The relational model won because it provided a complete, composable abstraction. You could express any query over any structure.

Agent memory needs its equivalent moment. A model that unifies:

Time-ordered events (episodic)
Structured knowledge (semantic)
Entity relationships (graph)
Fuzzy matching (vector)
Lifecycle management (decay + consolidation)

Under one query interface. With one storage engine.

That engine doesn’t exist yet. But the shape is becoming clear — and the Rust ecosystem is where the early experiments are happening (YantrikDB, Vestige, Engram-AI, DriftDB). More on that in Post #5.

Previous: Agent Memory Deep Dive #1: Why Your Agent Forgets Next: Agent Memory Deep Dive #3: The Forgetting Problem