How Agent Persistent Memory Graphs Actually Work

Agent persistent memory is a store of facts, wired together as a graph, that survives the end of a conversation. Because an LLM forgets everything once its context window ends, you write key facts outside it in four steps: extract, store, retrieve, and forget/verify. We run such a memory graph (curator); by read-only stats it currently holds 8,880 facts (8,665 active), with an average confidence of 0.735, organized across 266 hierarchical projects (measured on our pool). By type it splits into semantic 5,207, episodic 2,886, and procedural 787.

In one line: persistent memory is the agent's notebook and its relationship map. Beyond plain notes (vector search), wiring "who connects to whom and to what" lets it answer relational questions like "what should I watch out for when changing this function?"

What stages does a memory pass through?#

Extract, store, retrieve, verify. (1) Extract entities (functions, files, concepts) and relations from conversations and work. (2) Store each fact as a node with its type (semantic/episodic/procedural), project scope, confidence, and timestamp, and create labeled edges between entities. (3) Retrieve, at the start of new work, a relevant subgraph via a hybrid of semantic + BM25 + 1-hop graph expansion, injected into context. (4) Verify: a fact that gets used rises in confidence via confirm, and a wrong one is retired via invalidate while keeping its lineage. Our pool's verify queue alone holds about eight thousand items, showing that memory is not "piling up" but "managing".

Does adding a graph always help?#

No - it is strong on relational and temporal questions but not free. In one public benchmark (measured in the Mem0 paper), the graph variant scored about 68.44 overall, edging plain vector's 66.88 and winning temporal, but it lost single- and multi-hop, ran search about 3x slower, and used about 2x the tokens. Conversely, on LongMemEval, where tracking time matters, a graph-based system (Zep) measured 63.8% versus the vector approach (Mem0 49.0%). The conclusion is that the question type decides: vector for personalization and fast recall, graph for "what was true then, and what is it connected to." So production converges on a hybrid that layers both.

Why are verify and forget the crux?#

Because memories go wrong as they age. Code and facts change, and a stale memory makes the agent act on old information. So you attach confidence and last_verified, strengthen with confirm on each use, and demote with invalidate when wrong. Our pool's average confidence of 0.735 and roughly eight thousand pending verifications show this lifecycle actually runs. Note that benchmark scores are sensitive to the harness (judge model and prompt) - swapping only the model can move scores about 10 points - so read them as directional, not absolute.

How can you explore it yourself?#

Build it small.

• Store facts with their type (semantic/episodic/procedural), project, and confidence, and start retrieval with semantic plus keyword.
• As relational questions ("what should I watch out for here?") grow, add a graph 1-hop only for those (a full graph is over-engineering).
• Build the invalidate path for wrong memories first - memory without forgetting soon becomes a lie.

Reference links

• Mem0 (memory layer repo)
• Graphiti (Zep, temporal graph repo)
• Graphiti/Zep (paper)
• Mem0 (paper, LOCOMO measurements)
• Agent memory techniques (repo)

Note: fact counts, confidence, and types come from 2026 read-only stats of our pool and public benchmarks (project names, paths, and accounts are private), and benchmark scores are harness-sensitive, so read them as directional. Measure real effect on your own data. Memory benchmarks shift fast, so this is reviewed quarterly.