Agent Memory Frameworks in Production: Comparing Mem0, Letta, Zep Graphiti, and Cognee — Architecture, Entity Extraction, Temporal Graph Indexing, and Serving Economics

Large language model agents deployed in production environments face a fundamental architectural bottleneck: LLM context windows are stateless, ephemeral, and computationally expensive. While context window capacities have expanded to 1M+ tokens in modern frontier models, naive context stuffing (re-injecting unpruned conversational history on every turn) creates severe operational failure modes: quadratic attention compute overhead, high latency, rapid KV cache invalidation, and severe context degradation.

More critically, flat context injection and basic RAG architectures fail at temporal consistency. When a user states a preference or fact in session 1 and contradicts or updates it in session 5, traditional vector stores retrieve conflicting chunks simultaneously, inducing model hallucination.

To address these constraints, a new category of dedicated agent memory frameworks has emerged. Rather than treating memory as unstructured text chunks, modern frameworks implement structured memory lifecycles spanning extraction, temporal indexing, consolidation, and targeted retrieval.

This technical analysis examines the architectures, data models, retrieval mechanics, benchmark performance, and serving economics of the four primary open-source agent memory frameworks: Mem0, Letta (formerly MemGPT), Zep Graphiti, and Cognee.

Agent Memory Framework Architectures: Tiered Memory, Temporal Knowledge Graphs, and Dynamic Vector Stores

The Agent Memory Taxonomy

Production agent architectures delineate memory into four distinct functional tiers:

Working Memory (Active Context): The immediate prompt window containing system instructions, tool definitions, active scratchpads, and the latest conversation turns.
Episodic Memory (Event Stream): A chronological, immutable log of raw user interactions, agent thoughts, tool execution inputs, and tool outputs across past sessions.
Semantic Memory (Consolidated World & User Model): Extracted, deduplicated atomic facts, entities, user preferences, and relational knowledge distilled from raw episodes.
Procedural Memory (Behavioral & Tool Policies): Static or iteratively refined execution routines, workflow recipes, and domain heuristics that dictate how the agent performs multi-step tasks.

The core differentiator across memory frameworks lies in how they transform raw episodic streams into structured semantic memory, how they handle state mutation over time, and how retrieval is triggered.

1. Mem0: Dynamic Fact Extraction and Vector-Centric CRUD

Mem0 operates as a lightweight, modular memory layer designed for low-friction integration into existing agent runtimes. Rather than requiring developers to adopt a specialized agent execution engine, Mem0 acts as an intelligent intermediary between dialogue turns and underlying storage engines.

Architecture and Extraction Pipeline

Mem0 processes incoming dialogue turns through a two-phase LLM-driven extraction and reconciliation loop:

Phase 1: Atomic Fact Extraction: When a conversation turn is ingested via Memory.add(), an extraction prompt instructs an LLM to parse the message pair into discrete, self-contained atomic facts. For example, the sentence "I switched from VS Code to Cursor last week and I deploy on GCP" is split into two atomic facts: {"fact": "User uses Cursor IDE"} and {"fact": "User deploys infrastructure on GCP"}.
Phase 2: Semantic Similarity Gating & CRUD Decision: For each extracted candidate fact, Mem0 performs a vector similarity search across existing memories indexed under the corresponding user_id, agent_id, or run_id. The candidate fact and the top-k retrieved existing memories are passed to a second LLM classification prompt. The model evaluates whether the new fact requires:
ADD: A genuinely novel fact to be embedded and persisted.
UPDATE: A refinement or direct contradiction of an existing memory (replacing the previous vector entry).
DELETE: An explicit invalidation of a prior memory.
NOOP: A duplicate fact that provides no new information.

Storage and Retrieval Characteristics

Mem0 OSS relies on a hybrid storage backend pairing vector databases (such as Qdrant, Chroma, Pgvector, or Milvus) with relational or key-value stores (such as SQLite or PostgreSQL) for metadata tracking and audit logging.

Ingestion Latency: High per turn. Each memory write triggers two synchronous or asynchronous LLM calls and multiple vector search queries.
Retrieval Latency: Fast (sub-50ms). Retrieval uses standard dense embedding vector search filtered by entity IDs.
Limitation: In its open-source version, Mem0 stores facts as independent text vectors. Because relationships between entities are not represented as first-class graph edges with temporal validity intervals, Mem0 struggles with complex multi-hop relational queries and historical state reconstruction.

2. Letta (MemGPT): OS-Inspired Hierarchical Virtual Memory

Originally developed as the research project MemGPT at UC Berkeley, Letta treats memory management not as an external retrieval database, but as a core operating system service inside an autonomous stateful agent runtime.

The Virtual Memory Paradigm

Letta explicitly borrows architectural concepts from operating system virtual memory management, dividing agent memory into hierarchical tiers:

Core Memory (SRAM / Primary Context): Fixed-size text blocks that are permanently mapped into the LLM system prompt on every inference call. Standard blocks include persona (the agent identity and operational guidelines) and human (critical details about the user).
Recall Memory (Main Memory / RAM): A complete, searchable relational database (PostgreSQL/SQLite) containing the chronological sequence of all raw conversation messages, tool executions, and event timestamps.
Archival Memory (Disk / Swap Space): An out-of-context vector database containing arbitrary unstructured text, document uploads, and overflow conversation data.

Self-Editing Context Control Loops

Unlike passive frameworks where external application code fetches memories before calling the LLM, Letta gives the LLM explicit control over its own memory allocations via tool execution:

core_memory_append(key, string) and core_memory_replace(key, old_str, new_str): Allow the agent to dynamically rewrite its own in-context persona and user knowledge blocks during execution.
archival_memory_insert(content) and archival_memory_search(query, page): Allow the agent to page information out of its active prompt into long-term storage, or query its archival database when relevant.
conversation_search(query): Enables paginated keyword and semantic search across the recall message database.

When the LLM context window reaches a configurable token threshold (for example, 70% capacity), Letta triggers a memory pressure interrupt. The agent is forced to execute a summarization and archival routine, flushing older context turns into recall and archival storage before continuing execution.

3. Zep & Graphiti: Bi-Temporal Knowledge Graph Memory

Zep centers its memory engine around Graphiti, an open-source framework specifically built to solve temporal reasoning and fact invalidation using bi-temporal knowledge graphs.

The Problem of Temporal Contradiction

Traditional vector-based memory systems suffer from a critical failure mode: they treat time as a static metadata filter rather than a graph dimension. Consider the following sequence:

Day 1: "I am working as a backend engineer at Stripe."
Day 180: "I just accepted a new role as VP of Engineering at Datadog."

In a vector database, a similarity search for "Where does the user work and what is their role?" yields high cosine similarity scores for both chunks. The LLM receives contradictory context and frequently merges them into a hallucinated response ("The user is a VP of Backend Engineering at Stripe and Datadog").

The Bi-Temporal Data Model

Graphiti addresses this by modeling information as a dynamic property graph where entities are nodes and relationships are bi-temporal edges. Every edge maintains two distinct temporal dimensions:

Valid Time ( $t_{valid}$ ): The time interval $[t_{start}, t_{end})$ during which the asserted relationship is true in the real world.
Transaction Time ( $t_{ingest}$ ): The timestamp when the fact was ingested and recorded by the system.

When new dialogue is ingested:

Graphiti extracts entity nodes (e.g., User, Stripe, Datadog) and directed relationship edges (e.g., WORKS_AT).
The system executes a hybrid search (combining BM25 text search and vector similarity) across existing edges connected to those entities.
If a semantic contradiction or state transition is detected, Graphiti does not delete the old edge. Instead, it sets $t_{end}$ on the existing WORKS_AT(User -> Stripe) edge to the transition timestamp and creates a new active edge WORKS_AT(User -> Datadog) with $t_{start}$ set to the current date and $t_{end} = \infty$ .

Retrieval Mechanics and Graph Traversal

Zep and Graphiti execute hybrid retrieval across graph structures:

Search Execution: Combines BM25 keyword matching, vector similarity against node/edge embeddings, and graph traversal algorithms (such as breadth-first neighbor expansion and community detection).
Temporal Filtering: Queries can resolve point-in-time state ("Who was the team lead in March 2025?") or restrict context strictly to currently valid assertions ( $t_{end} = \infty$ ).
Storage Backends: Graphiti runs natively on top of graph databases including Neo4j (version 5.26+) and FalkorDB.

4. Cognee: Extract-Cognify-Load (ECL) Pipelines

Cognee takes an architectural approach inspired by data engineering ETL pipelines, framing agent memory as an Extract, Cognify, Load (ECL) lifecycle.

Architecture and Data Pipelines

Cognee structures memory processing into three sequential stages:

Extract: Ingests raw data from varied multimodal sources (dialogue transcripts, audio logs, PDF documentation, database tables) into standard text chunks.
Cognify: An orchestrated LLM pipeline extracts semantic entities, relationships, and document graph hierarchies, resolving entity aliases and mapping extracted assertions against a predefined or dynamically generated domain ontology.
Load: Persists the resulting representations simultaneously across three distinct database layers:
A graph database (NetworkX, Neo4j, or FalkorDB) for structural and topological relationships.
A vector store (LanceDB, Qdrant, or Weaviate) for dense semantic vector search.
A relational database (PostgreSQL or SQLite) for tabular structured attributes and metadata.

Deterministic Memory Pipelines

Where Mem0 relies on unstructured text vectors and Letta relies on autonomous agent decisions, Cognee prioritizes deterministic data pipelines. By enforcing schema validation on extracted nodes and edges, Cognee reduces non-deterministic hallucination during the memory ingestion phase.

Empirical Benchmarks: LongMemEval and LOCOMO

To objectively evaluate how memory frameworks handle real-world agent interactions, the research community utilizes standardized long-context benchmarks:

LongMemEval Breakdown

LongMemEval (arXiv:2410.10813) evaluates 500 challenging multi-session dialogue tasks across five core memory capabilities:

Information Extraction: Extracting specific fine-grained details mentioned across scattered sessions.
Multi-Session Reasoning: Synthesizing facts across multiple non-consecutive conversational sessions.
Temporal Reasoning: Answering questions that depend on understanding the relative chronological sequence of events.
Knowledge Updates: Correctly retrieving the latest valid state when previously stated facts have been updated or contradicted.
Abstention: Appropriately stating that information is unknown when the dialogue history does not contain the answer, avoiding false-positive retrieval.

Benchmark Results and Behavioral Insights

On the LongMemEval benchmark using GPT-4o:

Zep (Graphiti Backend): Achieves 63.8% overall accuracy. Its native bi-temporal edge model delivers superior performance on temporal reasoning and knowledge update categories, preventing outdated facts from polluting the prompt context.
Mem0: Scores 49.0% in independent third-party evaluations. While highly effective at static preference retrieval and entity extraction, flat vector similarity search struggles when resolving chronological conflicts and temporal ordering without explicit graph validity windows.
LOCOMO Benchmark: On the LOCOMO multi-session evaluation dataset (arXiv:2402.17753), systems that combine temporal graph traversal with semantic vector search consistently outperform pure vector retrieval by 12 to 22 percentage points on multi-hop question answering.

Production Decision Matrix and Serving Economics

Choosing an agent memory architecture requires balancing ingestion compute overhead, retrieval latency, and operational complexity.

Architectural Comparison

Mem0
Memory Paradigm: Dynamic Vector Store + Extraction Layer
Primary Storage: Qdrant / Chroma / Pgvector + SQLite
Temporal Handling: Timestamp metadata (no native graph invalidation in OSS)
Query Latency (p95): 20 - 50 ms
Ingestion Cost: Moderate (2 LLM calls per memory write)
Best Fit: User personalization, chatbot preference tracking, quick integration into existing LangChain/LlamaIndex pipelines.
Letta (MemGPT)
Memory Paradigm: OS-Style Hierarchical Virtual Memory
Primary Storage: In-context System Blocks + PostgreSQL + Pgvector
Temporal Handling: Chronological message log paging
Query Latency (p95): 100 - 300 ms (agent-driven tool call)
Ingestion Cost: Low to High (governed by context window eviction frequency)
Best Fit: Long-running autonomous agents, multi-agent workspaces, continuous stateful agent runtimes.
Zep (Graphiti)
Memory Paradigm: Bi-Temporal Knowledge Graph
Primary Storage: Neo4j / FalkorDB + Vector Indexes
Temporal Handling: Explicit $[t_{start}, t_{end})$ edge validity windows
Query Latency (p95): 80 - 180 ms (hybrid graph + vector search)
Ingestion Cost: High (entity extraction, edge resolution, graph updates)
Best Fit: Enterprise domain agents, customer relationship assistants, scenarios where user facts change frequently over time.
Cognee
Memory Paradigm: Extract-Cognify-Load (ECL) Tri-Store
Primary Storage: Neo4j / NetworkX + LanceDB / Qdrant + PostgreSQL
Temporal Handling: Structured relational and graph constraints
Query Latency (p95): 50 - 150 ms
Ingestion Cost: High (batch graph extraction and schema mapping)
Best Fit: Document-heavy RAG pipelines, enterprise knowledge networks, deterministic data extraction.

Serving Economics

Ingestion Token Tax: Dynamic memory frameworks shift compute costs to the ingestion phase. Running an LLM extraction pipeline on every user turn adds 300 to 1,200 tokens of prompt and completion overhead per interaction. In high-throughput deployments, asynchronous background workers must be used to decouple memory consolidation from user-facing response paths.
Context Window Savings: In long-running conversational applications (100+ turns), injecting 5 to 10 targeted semantic memories consumes 250 to 500 tokens, compared to 20,000 to 60,000 tokens for unpruned context stuffing. For frontier models costing $2.50 to $10.00 per million tokens, structured memory systems reduce aggregate token consumption by 70% to 90% across extended user lifecycles.
Operational Overhead: Pure vector memory architectures (Mem0) are straightforward to maintain using managed vector databases. Bi-temporal knowledge graph architectures (Zep/Graphiti) require managing dedicated graph infrastructure (such as Neo4j or FalkorDB clusters), but eliminate the engineering overhead of building custom temporal deduplication heuristics.