Agent Persistent Memory Graph: How We Actually Operate It

After running agent persistent memory in our own operations, the verdict is one line: "memory is not 'storage' but 'operation.'" Our memory graph now holds 8,941 facts, but the real work was not adding - it was sorting, verifying, and pruning. Measured, our discipline is: (1) split facts into three types (semantic, episodic, procedural) and use each differently, (2) verify at write time, distinguishing validated from speculative via confidence, and (3) the hardest part is forgetting - even now about 76% of facts are unverified stale (8,135 awaiting verification). The core lesson: memory's value is not accumulation but "verified freshness."

In one line: memory is operation, not storage - we split 8,941 facts into three types (semantic, episodic, procedural), verify by confidence at write time, and prune as much as we add (about 76% stale now), because that is what keeps "verified freshness."

In plain terms: operating memory is managing a fridge. Filling it is easy; the real work is sorting into shelves (types), watching expiry (verification), and throwing out the spoiled (pruning). Skip that and the more you add, the more spoiled food you have.

How do we use memory?#

We use the three fact types differently by purpose. Semantic (5,243) is "what" (facts, relations), episodic (2,907) is "when and what happened" (events, decisions), and procedural (791) is "how" (reproducible methods). The ratio is telling - semantic is 59%, while procedural is only 9%, so the most valuable know-how is the thinnest. So we deliberately try to promote episodes into semantic facts and repeated solutions into procedures (the consolidation the 2026 research describes). We keep recall precise by re-ranking with project scope (266) plus confidence and recency.

Below is the mix of the three types. It shows at a glance that the most valuable one, procedures, is the thinnest.

What do we store, and what not?#

Verify at write time, and do not store what code and git already know. A good memory system must distinguish validated from speculative facts - because once wrongly stored, they propagate through multiple steps. So each fact carries confidence (avg 0.730), a verification time, and provenance. And one rule: do not keep what the repo and commit log already record (duplication, noise). For stable domain knowledge, the 2026 research concludes a file-based approach is actually better, and we do that too - one fact per file, with type/confidence frontmatter, links to related memories, and a dedup check before saving. We run the extraction pipeline and the file memory side by side.

How do you handle the hardest part, forgetting?#

We treat decay and staleness as different problems. The key 2026 insight: the decay of low-relevance facts and the "quiet becoming-wrong" (staleness) of high-relevance facts are different. A file path or flag is true when written but wrong next month, and if verification lags, the graph confidently believes the old fact. Our 76% stale is exactly that face. So the rule is prune as much as you add - periodic re-verification, invalidating to the latest on contradiction, and recording temporal validity (true until when). Recalled memories are "what was true when written," so re-check before use.

Decay and staleness live on different axes - viewing them on relevance vs accuracy, as below, shows why they need different treatments.

So what is our operating discipline?#

The key is investing in verification and tidying, not storage.

• Sort: split facts into semantic, episodic, and procedural, store and retrieve each differently, and deliberately keep procedures (know-how).
• Verify: attach confidence and provenance at write time, and do not store what code already knows.
• Tidy: separate decay from staleness for re-verification and invalidation, and re-rank recall by scope and confidence. Measure the effect with recurrence and false-positive rates.

Related reading: 오픈 음성 클로닝, 우리는 이렇게 운영한다 — 파이프라인 회고, 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계

Related reading: 에이전트 영속 기억(메모리그래프), 직접 써본 실측·한계, 에이전트 영속 기억(메모리그래프), 어떻게 동작하나

Reference links

• Mem0 (agent memory, extraction)
• Graphiti (temporal knowledge graph, validity)
• Letta (procedural memory, self-editing)
• Cognee (self-improving curation)
• CoALA (agent memory types paper)

Note: the 8,941, 76% stale, and type ratios are a read-only snapshot of our graph in 2026 and shift every moment with operation and pruning cadence (not permanent numbers). Staleness is still an open problem, so full automation is hard. Memory operations succeed not by volume but by verification, tidying, and retrieval design, so measure on your own metrics (these numbers are only a start). Memory frameworks move fast, so this is reviewed quarterly.