Choosing an Agent Memory Layer: 7 Critical Decision Points from Write Timing to Forgetting

Four Roles of Agent Memory

Before selecting a memory layer, the article distinguishes four roles that a memory system must play:

Raw event store — immutable original inputs (user messages, system responses) kept as evidence and raw material. Graphiti calls this Episode, Mnemovela Episode, Cognee document and chunk.

Fact extractor — who turns events into structured facts. Mem0 uses system-driven extraction (LLM proposes candidate facts after each conversation). Letta uses agent self-editing (the agent decides what to write to core, recall, or archival memory during its reasoning loop). System extraction is stable and token-efficient; self-editing adds judgment but burns inference tokens and can forget to store.

Context assembler — who retrieves and assembles memories within the token budget. Graphiti's Construct step formats edges (time-bounded facts) and nodes (entity/community summaries) into a context string, compressing 115,000 tokens to ~1,600 tokens. Mnemovela isolates this as a separate Context Assembly step driven by task, budget, memory type, and relevance.

Runtime loop owner — Mem0 is a pluggable memory layer; Letta is the agent runtime itself. Cognee's blog advises: light preferences → Mem0; document-to-graph pipelines → Cognee; agent-edited in-context memory → Letta.

Background: Long context ≠ good memory. Chroma's Context Rot experiment shows accuracy dropping from 98% to 64% solely by changing information placement in the prompt. You still need archival, retrieval, and reuse.

Mem0: Four-Operation Reconciliation, Fastest Onboarding

Mem0 runs a two-stage extract–compare–decide pipeline:

Extraction : after each conversation, an LLM proposes candidate facts (e.g., "user moved to Shanghai") using recent messages and existing memory summaries.

Update : for each candidate, vector search finds semantically similar existing memories; an LLM then chooses one of four operations:

Mem0's four-operation reconciliation: conflicts resolved at write time, not at retrieval
Candidate fact → Vector search top-S similar memories → LLM compares & decides (not a similarity threshold)
ADD    – brand-new information → direct insert
UPDATE – supplements or corrects existing memory → overwrite old
DELETE – new info negates old memory → remove old
NOOP   – duplicate → no operation
Example: existing "user lives in Beijing" + new "I moved to Shanghai" → UPDATE → old becomes "user lives in Shanghai"

Key: conflicts are resolved at write time, avoiding "stacked contradictions" at retrieval.

Engineering details: embedding and storage are decoupled; multiple vector backends supported; add() runs an 8-stage pipeline with batch embed/write fallbacks; entity linking failures warn but don't abort. Retrieval fuses three signals (semantic similarity, BM25 keywords, entity boost), normalizes scores, discards low-semantic-score hits even if keywords match.

Forgetting: Two Independent Tools

Hard delete — three levels: by ID, batch, by filter (user/agent/run/metadata). Filter delete requires a filter argument (safety gate against accidental full wipe).

Memory Decay — not an eviction policy; nothing is deleted. Instead, a re-ranking layer at retrieval: recently accessed memories get up to 1.5× score boost; long-unused decay to 0.3×. Decayed memories still surface if they are the best match. Implements Bjork's storage-strength vs. retrieval-strength distinction; opt-in per project; each memory tracks up to 20 access timestamps.

Lifecycle layers: Conversation (single response), Session (minutes/hours, explicit clear), User/Organization (long-term). Short-term episodic context "promotes" into long-term semantic memory instead of piling up.

Trade-offs: extraction is passive (system decides what to store); developers only control input. Stable and token-efficient but cannot make context-aware judgments like "this detail matters now." Graph retrieval only in Pro tier; free/standard tiers have only semantic similarity.

Graphiti: Temporal Edge Management, Strong Consistency First Choice

Best when "was true" and "is true" must be separated (contract status, subscription tier, employment, preference drift). Organizes memory into three subgraphs:

Episode subgraph — raw inputs (messages, text, JSON), lossless, each with a reference timestamp; parses relative times like "two weeks ago" into exact instants.

Semantic entity & fact subgraph — intermediate layer: extracts named entities on ingestion, deduplicates via cosine similarity + full-text search; facts are edges between entities, same deduplication flow.

Community subgraph — top layer: label propagation clusters strongly connected entities, generates summary nodes per cluster; new entities join dynamically without full recomputation.

Core innovation: bitemporal data model . Every entity edge tracks four timestamps: valid_at — when the fact became true in the world invalid_at — when it was superseded created_at — when Graphiti ingested it expired_at — when the record was logically replaced

These enable: point-in-time queries ("what did we know about X on date Y"), historical reasoning about fact evolution, full audit trails (hard requirement for enterprise compliance).

Graphiti's temporal edge invalidation: old fact not deleted, only marked invalid
Contradiction occurs
Old edge: Alice works at Acme
valid_at = 2025.03, invalid_at = 2025.06
New edge: Alice works at Beta Corp
valid_at = 2025.06, invalid_at = present
History fully preserved · current fact accurate · point-in-time queries & audit trails both hold
Cost: requires graph DB (Neo4j/FalkorDB/Kuzu/Neptune) + multi-round LLM calls per episode; entity resolution must be evaluated separately

Retrieval: search–rerank–assemble. Search runs three strategies concurrently: cosine semantic similarity, BM25 full-text, breadth-first graph traversal from seed nodes. Rerank options: reciprocal rank fusion, maximal marginal relevance, episode mention frequency, graph distance scoring, cross-encoder. Assemble formats top edges (with validity intervals) and nodes into context strings. No LLM calls during retrieval — all precomputed via vector, BM25, graph indexes. Zep cloud P95 latency ~300 ms.

LongMemEval numbers (115k-token dialogues, temporally complex questions):

Full-context GPT-4o-mini: 55.4% accuracy, 31.3 s latency

Zep (Graphiti): 63.8%, 3.20 s

Full-context GPT-4o: 60.2%, 28.9 s

Zep + GPT-4o: 71.2%, 2.58 s

Biggest gains on hardest categories: single-session preference 20.0% → 56.7%, temporal reasoning 45.1% → 62.4%, multi-session 44.3% → 57.9%.

Operational cost: requires graph DB + LLM + embedding service. Ingesting one episode involves extraction, entity resolution, relation updates — multiple model calls, rate limits, retries, failure modes. Entity resolution must be evaluated separately : same-name merging, alias splitting, negation mis-extraction. Suggested smoke test: write "A works at Alpha", then "A moves to Beta next month"; query current/previous employer, transition time; verify old edge has invalid_at, new edge has valid_at, both retain episode provenance; introduce same-name person, check entity resolution.

Letta: OS-Style Paging + Self-Editing, Check Repo Status First

Productized continuation of MemGPT ("LLM as OS, context as RAM, external storage as disk"). Three memory tiers:

Core Memory — small resident region in context window (like RAM); agent reads/writes directly each turn; holds persona and most important user facts.

Recall Memory — searchable conversation history outside context (like disk cache); accessed via tool calls.

Archival Memory — long-term cold storage, vector-indexed; also via tool calls.

When context nears overflow, agent receives a system message ("you're running out of context") and must decide what to evict to recall, summarize into core, or archive. The OS metaphor is literally implemented.

Value: judgment — agent uses its own reasoning to curate memory, enabling context-aware trade-offs. Cost: symmetric — what the model fails to store is gone forever; every memory operation burns inference tokens.

2026 critical change: Apache-2.0 letta-ai/letta repo (~24.4k stars) is now a landing page; V1 server moved to archive branch; active development shifted to letta-ai/letta-code . If your docs still say "spin up a server," the path is wrong. Current path: hosted platform + Agent SDK.

Current SDK uses MemFS — a git-backed memory filesystem agents can inspect and edit, persisting across sessions. Notable commands: /init — agent inspects your repo and asks about work style to bootstrap /remember — explicitly teach it a fact /doctor — audits memory placement, duplicates, system-prompt token usage

Unique capability: Dreaming — background sub-agent reviews recent conversations, consolidates lessons, updates memory without interrupting current work; optional second-pass verification before committing. Different from ChatGPT's Dreaming (offline consolidation vs. continuous re-synthesis).

Lock-in: Mem0 locks at API level (swap a few calls); Letta locks at architecture level (adopting it = adopting a full agent lifecycle model). Conversely, if you're building agent-native apps, that model comes free.

Cognee & Supermemory: Graph-Backed Semantics & External Source Sync

Cognee: ETL → ECL (Extract, Cognify, Load)

Upgrades traditional ETL: Cognify replaces Transform — "make the machine truly understand data."

Extract from 30+ sources (PDF, Notion, Slack, audio, images, SQL, etc.)

Cognify six stages: document classification, permission check, text chunking, LLM entity/relation extraction, summary generation, vector embedding + graph edge commit. Only new/updated files are processed ; existing results reused.

Load writes to both vector and graph stores simultaneously.

Most underestimated step: ontology entity validation . Same entity may have 5–10 names across documents ("ChatGPT-4", "GPT-4 turbo", "OpenAI gpt-4"). Ontology validation unifies them into a single URI via fuzzy match → URI standardization → BFS injection of rdfs:subClassOf hierarchies and owl:ObjectProperty edges; each node tagged ontology_valid. Graceful degradation when no ontology provided (all tagged False, pipeline continues).

API: four verbs — remember (write), recall (retrieve, auto-routes best strategy), improve (optimize graph edge weights from feedback), forget (precise dataset deletion). improve() is the most important — "frequently used & correct" connections rise, "outdated & wrong" sink; this is its self-evolution mechanism.

Deployment: Cognee 1.0 runs full memory layer on single PostgreSQL instance — relations via Postgres graph backend, embeddings via pgvector, session cache via SQL, metadata in same Postgres. CI benchmarks show Postgres setup ~10% faster than separate graph+vector. Local dev: SQLite + LanceDB + Kuzu zero-config. Benchmarks: HotPotQA human-like correctness 0.93; BEAM long-context memory benchmark 100K tokens 0.79 (previous best 0.735, RAG baseline ~0.33).

Limitations: heavy reliance on structured output; 14B–24B local models struggle to emit valid JSON consistently; production needs commercial APIs with reliable structured output. Default 4k chunk size may be tight for larger-context models.

Supermemory: MIT-licensed, Vector-First, Hosted Memory API

Positions as external-data memory hub. If agents must digest non-conversation sources (Google Drive docs, Gmail, Notion, GitHub PR descriptions), it auto-syncs from these sources, collapsing "memory" and "RAG" into one layer. Hybrid of personal knowledge base + memory; popular for super-assistants around user's entire digital life and coding agents integrated with Claude Code.

One-sentence distinction: Cognee solves "how to express relationships between documents"; Supermemory solves "how to continuously sync external data sources in."

Mnemovela: Git-Style Branching for Counterfactual Reasoning, Append-Only Auditable

Self-described as Cognition Runtime — sits beside the LLM, handles long-term memory, context assembly, knowledge representation. Two core tenets:

Types must be distinct — defines 12+ cognitive memory types: Episode (raw events), Fact (subject-predicate-object with expiry), Knowledge (structured entity relations/taxonomies), Experience (post-action reflections), Simulation (hypothetical scenarios for outcome rehearsal), plus Belief, Intention, Procedure, Mission, Preference (internal states/behavioral tendencies). Each type has different trust levels, validity periods, usage rules. An Episode shouldn't auto-upgrade to Fact just because it was retrieved; a Simulation shouldn't be treated as real memory; Experience is reflection, not action.

Git-style branching — agents can branch from a memory state, run simulations/experiments/revisions without polluting the main cognitive line. Coding agent comparing two refactors: branch A records "lessons from approach 1", branch B records "outcome of approach 2", only best conclusion merges back to main.

Paired with append-only immutable records : every record immutable, carries branch, timestamp, retention level, tenant, project scope. When a Fact is corrected, history isn't overwritten; a new version or relation is appended, preserving full cognitive evolution. Makes "what did we think back then" queryable instead of erased.

Retrieval: multi-dimensional hybrid — lexical match, vector semantic similarity, entity/relation match, time window/validity, branch/identity scope. Post-retrieval, independent Context Assembly reassembles candidates by current task, token budget, memory type, relevance — producing context the model can actually consume, not just high-scoring text chunks.

Core thesis worth copying: "Memory is not a storage location; it is a set of semantic constraints about type, time, provenance, identity, branch, and purpose. A vector store can be a storage or retrieval mechanism, but it is not equivalent to Agent Memory."

Decision Tree: Seven Judgment Points

Selection order isn't "which has most stars" but answering these seven sequentially:

Agent Memory Layer Seven Judgment Points: from write timing to forgetting strategy
① Write timing
   Sync or async background? Async saves budget but introduces "just said it, not yet in memory" window
② Write authority
   System extraction (Mem0: stable, token-efficient) vs. agent self-edit (Letta: judgment but miss = permanent loss)
③ Conflict handling
   Overwrite (Mem0 DELETE), mark invalid (Graphiti invalid_at), append new version (Mnemovela)
④ Forgetting strategy
   Hard delete, decay, or never delete? Decay safer than delete — irreversible delete can't be undone
⑤ Retrieval paths
   How many parallel routes? Vector + BM25 + graph traversal + time window + branch scope → more recall, more cost
⑥ Scope isolation
   How fine-grained? User / session / project / tenant / branch; multi-tenant products retrofit painfully
⑦ Context assembly
   Who decides what fits in token budget? Graphiti's Construct compresses 115K → 1.6K

Deep Dive on Judgment Point 4

Mem0's combined "evict + decay" approach is worth copying directly: eviction = hard delete (by ID, batch, filter; filter required to prevent accidental full wipe); Memory Decay = only down-weight (recent access up to 1.5×, long-unused down to 0.3×, but still surfaces if best match). Decay is safer than deletion because deletion is irreversible; decayed facts can return.

Mapping Judgment Points to Choices

Few stable preferences, fastest launch → Mem0

State changes, need to answer "what was it like then" → Graphiti

Agent self-curates memory, runs across weeks → Letta

Heavy external docs, multi-hop reasoning → Cognee

Sync Drive, email, Notion, etc. → Supermemory

Counterfactual simulation, full audit trail → Mnemovela

First, run a time-travel test before talking selection. Write a fact, wait, write its opposite, then query "what is it now" and "what was it three months ago." Only solutions answering both correctly deserve further evaluation. Graphiti's official version is stricter: query current employer, previous employer, transition time — all three must pass; then introduce a same-name person to test entity resolution. Second, treat forgetting as a feature, not a patch. Many teams only care about remembering at launch; six months later they're bitten by stale facts. Decide upfront: what is noise (use eviction), what is temporarily unused (use decay). Third, calculate extraction cost before storage cost. Graph memory costs 3–5 extra LLM calls per record. Industry scale reference: 3 years, 1M conversations — pure vector RAG 15–30 GB, fact accuracy <60%; structured facts 500 MB–2 GB, accuracy 75–85%; graph+vector hybrid 2–5 GB, accuracy 85–95%. Third generation isn't storing more; it's storing more expensively.

The memory-layer competition will ultimately be decided not by who remembers the most, but by who forgets the right things.