Context Engineering — Swarnim Tiwari

01

How is each tool architected?

Every session with an AI starts from zero. The model carries nothing forward. Context engineering tools exist to solve this — but they make fundamentally different bets about how memory should be stored, organised and retrieved. The architectural decision is not cosmetic. It determines every other property of the system.

View

Apache 2.0 · YC Backed · ~48K GitHub Stars

Mem0

Extraction-First Memory

Architecture

Dual store (vector + graph)

LLM-based extraction at write time

Framework agnostic

SOC 2 Type I + HIPAA

ECAI 2025 peer-reviewed paper

01Apache 2.0, Y Combinator backed, approximately 48K GitHub stars as of August 2026. Dual store architecture: a vector database handles semantic search and an optional knowledge graph captures entity relationships. When a memory is added, Mem0 embeds it into the vector store and extracts entities and relationships for the graph layer simultaneously. The vector store answers "what do I know about X" and the graph layer answers "how does X relate to Y."
02Memory extraction via LLM: raw conversation text does not go directly into storage. Mem0 uses an LLM to extract discrete memory facts from each exchange before storing anything. "My preferred language is Python" gets stored as a clean structured fact. The full conversation turn is discarded after extraction. This approach is architecturally different from RAG systems that chunk and embed raw text verbatim.
03The ECAI 2025 peer-reviewed paper (arXiv:2504.19413) compared Mem0 against full context, RAG, and OpenAI native memory on the LoCoMo benchmark. Selective memory extraction outperformed all three. The finding challenged a widely held assumption: giving the model more context is not always better than giving it less but more carefully curated context. At long history lengths, full-context models performed worse than selective memory models on multi-hop reasoning tasks.
04Framework agnostic: works with OpenAI, Anthropic, LangChain, LangGraph, AWS Bedrock, and any other LLM client. A single SDK (memory.add() and memory.search()) works identically regardless of the underlying model or orchestration layer. SOC 2 Type I and HIPAA certified, making it viable for healthcare and financial services deployments without custom compliance infrastructure.
05Pricing as of August 2026: free tier available for development, Pro at $249/month for production workloads with higher volume, enterprise at custom pricing with additional compliance features. The Apache 2.0 self-hosted path carries full feature parity with the managed cloud version. The approximately 48K GitHub stars reflects the largest open source community of any dedicated agent memory tool in 2026.

Mem0's extraction-first approach solves the problem at the source. Instead of managing a growing pile of conversation history, it converts conversations into facts and discards the rest. The ECAI 2025 finding that selective memory beats full context even when full context is feasible is the most important research result in the context engineering space in 2025 and 2026. It changed how engineers think about context management at long history lengths.

Graphiti Apache 2.0 · Zep Cloud Managed · 28K+ GitHub Stars

Zep

Temporal Knowledge Graph

Architecture

Graphiti temporal graph engine

Three-layer subgraph structure

valid_at / invalid_at timestamps

MCP server native

SOC 2 Type II + HIPAA + GDPR

01Built on Graphiti, an Apache 2.0 temporal knowledge graph engine that reached 28K GitHub stars in 2026 with over 25,000 weekly PyPI downloads. Graphiti is the open source core; Zep Cloud is the managed platform built on top of it. The two are independently usable: teams with data residency requirements can self-host Graphiti on Neo4j or FalkorDB while teams prioritising simplicity use Zep Cloud managed infrastructure.
02Temporal knowledge graph means every fact has a validity window: valid_at and invalid_at timestamps. When new information contradicts existing information, Zep marks the old fact as invalid while preserving it for historical queries. When a customer relationship changes or a user's preferences shift, both the old and new state are queryable — only one is current. This is structurally impossible in a vector-only memory system without custom deletion logic.
03Three-layer architecture: episodic subgraph (raw events and messages, "what did we discuss"), semantic subgraph (extracted entities and relationships, "what do I know about X"), and community subgraph (clusters of related entities, "what related context should I surface"). Each layer serves different retrieval patterns and can be queried independently or in combination via GraphRAG.
04Benchmark results from independent evaluations (WeavAI, May 2026): 63.8% on LongMemEval versus Mem0's 49.0% on the same benchmark. DMR benchmark: 94.8% accuracy with GPT-4 Turbo and 98.2% with GPT-4o Mini. Published production data: up to 90% latency reduction compared to full conversation history injection and 18.5% accuracy improvement on reasoning tasks versus full-context baselines.
05Enterprise positioning: SOC 2 Type II, HIPAA, GDPR certified. Named production customers include AWS, Samsung, PwC, Anduril, and Athena Health. Native MCP server integration means Claude Desktop, Cursor, and any MCP-compatible client can use Zep as a memory tool without custom integration code. Pricing: Free (10K message limit), Pro at $99/month for 500K messages, Enterprise at custom pricing with BYOK and BYOC options.

Zep's temporal graph architecture solves a problem that vector stores cannot: knowing when a fact was true and when it stopped being true. For agents operating in domains where facts change over time — customer state, account balances, project status, medical records — this temporal dimension is not optional. The LongMemEval advantage over Mem0 reflects Zep's strength in extended memory tasks where the accuracy of historical and current facts both matter.

MIT License · LangChain Ecosystem · LangGraph Native

LangMem

Graph-State Memory for LangGraph

Architecture

LangGraph state native

In-context + external + working memory

Backend agnostic (pgvector, Redis, etc.)

LangSmith trace integration

No per-query pricing

01LangMem is LangChain's native memory module designed for LangGraph agents. Unlike Mem0 and Zep which are standalone services, LangMem integrates directly into the LangGraph state management layer. Memory is a first-class component of the graph state rather than an external service call. For teams already using LangGraph, this removes an entire service boundary from the production stack.
02Three memory types with distinct roles. In-context memory lives directly in the LangGraph state, always available to the agent with zero retrieval latency. External memory lives in a configured backend and is retrieved on demand via semantic search. Working memory is ephemeral state for the current agent loop. The developer explicitly designs which memories belong in each tier based on frequency of access and importance.
03Backend agnostic storage: PostgreSQL via pgvector, Redis, Chroma, Pinecone, Weaviate, and any LangChain-compatible vector store can serve as the external memory backend. Teams running a vector database from their existing RAG pipeline can reuse that infrastructure for agent memory without provisioning a new service.
04LangSmith integration is the feature that separates LangMem from standalone alternatives for LangGraph teams. Every memory read and write is traceable in LangSmith alongside LLM calls and tool calls. Engineers can see exactly which memories were injected at each step, which retrieval queries ran, and how memory content influenced agent decisions. This observability is not available when Mem0 or Zep are used outside the LangChain ecosystem.
05Cost model: no per-memory or per-query pricing beyond the underlying vector store and LLM costs for reflection chains. LangMem itself is MIT licensed as part of the LangChain open source ecosystem. Teams already paying for LangSmith do not pay additional fees for memory functionality. This zero-marginal-cost model is the primary reason teams using LangGraph choose LangMem over standalone alternatives at moderate scale.

LangMem is the right answer for one specific condition: you are already using LangGraph and you want memory without adding a new service to manage. The LangSmith trace integration — seeing memory operations alongside inference operations in the same view — is the most underappreciated feature in the comparison. When agent quality degrades, knowing whether the cause is the LLM, the retrieved memory, or the missing memory is what separates a 30-minute debug session from a 3-day one.

Apache 2.0 · UC Berkeley Origin · Self-Hosted + Cloud

Letta

OS-Style Memory Paging

Architecture

Core memory (fixed token budget)

Archival memory (unlimited)

Agent-driven paging

Token-budgeted named blocks

REST API + admin interface

01Emerged from the MemGPT research project at UC Berkeley. The foundational insight: LLM context windows behave like RAM, and there is no reason why an AI agent's memory architecture should not mirror how an operating system manages memory. Letta implements this: a main context (fixed size, always in the window) and archival memory (unlimited, never directly in the window). The agent decides what to page in from archival and what to keep in main context.
02Memory blocks with explicit token budgets. Each block has a type (Human: facts about the user, Persona: the agent's own character, Scratchpad: working notes) and a configured maximum token count. When a block fills, the agent must compress or evict content before new information can enter. This enforced scarcity prevents unbounded context growth structurally rather than through configuration. The architecture makes long-context degradation impossible by construction.
03Agent-driven memory management: Letta agents explicitly call memory functions to read and write. search_archival_memory(query) retrieves relevant past context. insert_archival_memory(content) stores new information outside the main window. The agent makes these calls autonomously as part of its reasoning, deciding what is worth remembering and what to look up. This meta-cognitive memory management layer is Letta's most distinctive architectural feature.
04Apache 2.0 license with a fully complete self-hosted deployment path: Letta Server, multi-agent memory sharing, REST API, and admin interface all run on a single server. For teams with data sovereignty requirements where no conversation data can leave the on-premises environment, Letta offers the most complete self-hosted experience of the four tools compared here.
05Benchmark: 93.4% on the Deep Memory Retrieval benchmark, comparable to Zep's 94.8%. Letta's differentiation is in scenarios requiring extended autonomous operation over days or weeks where the agent manages its own memory across thousands of context updates. The OS paging model was specifically designed for long-running single-agent state, a workload profile that none of the other three tools address as directly.

Letta's OS-paging model is the most intellectually principled answer to the long-context problem. The context window as RAM metaphor is not just conceptually clean — it produces a concrete architectural constraint that prevents degradation by making it structurally impossible for context to grow unboundedly. The cost is that memory management becomes the agent's responsibility. The benefit is that an agent that manages its own memory cannot be surprised by context it did not choose to include.

02

How does each tool integrate with the system prompt?

The system prompt is where retrieved memory meets the model's attention. How memory content enters the prompt — its format, its position, its structure — determines whether the model treats it as authoritative context or as noise. The four tools have very different views on how this integration should work.

View

Apache 2.0 · YC Backed

Mem0

Injection at Query Time

Prompt Pattern

Base prompt stays static

Memory block appended at runtime

Timestamp + relevance per memory

Metadata scoping per user

Category-based selective injection

01Mem0's integration pattern keeps the system prompt clean and stable. Base instructions live in the system prompt and change only when the product changes. Memories are injected at query time as a separate block, typically formatted as "Relevant memories for this user: [list of retrieved memory facts]." The developer writes the system prompt once. Mem0 dynamically populates the memories section before each inference call.
02The injected memory block includes metadata alongside each fact: a timestamp showing when the memory was stored and a relevance score showing how closely it matched the current query. This metadata allows the model to weigh recent versus older memories and to judge confidence. A memory tagged as highly relevant from last week outranks a weakly relevant memory from yesterday.
03User and agent scoping: memories are stored per user and per agent. The system prompt integration automatically scopes retrieval to the correct user before any semantic search runs. In a multi-tenant deployment, this prevents memory leakage between users at the database layer rather than in application code. The scoping is structural, not a post-retrieval filter that could be bypassed.
04Category-based selective injection: retrieve only memories tagged with a specific category. A customer support agent might inject only memories categorised as "product_preference" or "complaint_history" rather than the full memory set. A coding assistant might inject only memories about "preferred_language" and "project_context." Selective injection keeps the system prompt lean even as the total memory bank grows large.
05Framework integration points: OpenAI SDK (inject memories into the messages array before the user message as a System message), Anthropic SDK (inject into the system parameter before task instructions), LangChain (inject as SystemMessage content in the prompt template). The injection point is framework-specific but the API for retrieving memories (memory.search(query, user_id)) is identical across all of them.

Mem0's separation between the static system prompt and the dynamically injected memory block is its most useful operational property. When something goes wrong in production, the developer can check two independent components: the fixed instructions and the variable memories. This separation also makes A/B testing straightforward — test different memory formats without touching the core instructions, or test different instructions without changing the memory retrieval.

Graphiti Apache 2.0 · Zep Cloud Managed

Zep

Pre-Assembled Context Block

Prompt Pattern

Context assembly API

Temporal framing in summaries

MCP-native (no injection needed)

Community summaries as standing context

Session-level context vs query-level

01Zep generates context summaries ready for direct injection. The context object returned from zep.memory.get(session_id) includes a pre-formatted summary of relevant facts, entity relationships, and conversation history compressed into a structured block. The developer injects this block into the system prompt without manually formatting individual facts. Zep handles the assembly and the ordering.
02Temporal framing appears in every injected context block. Zep's summaries include explicit time references: "As of June 2026, Alice holds the position of VP of Engineering." The model receives the fact and the temporal frame, enabling it to reason about whether the information might be outdated. This is qualitatively different from a vector store that returns facts with no indication of when they were true.
03MCP server integration changes the system prompt architecture entirely for MCP-compatible clients. When Claude Desktop, Cursor, or any MCP-compatible agent connects to Zep's MCP server, it can call Zep tools directly during inference rather than requiring pre-injection into the system prompt. The memory appears at the moment the model requests it via a tool call rather than being placed in context before the model runs.
04Community subgraph summaries as standing context: if an agent always works within a specific customer account, the community summary for that account can be part of the base system prompt, refreshed periodically rather than per-query. Individual fact retrieval handles turn-by-turn specifics. This two-layer approach — standing summary plus dynamic retrieval — reduces per-query latency while maintaining semantic depth.
05Session retrieval (zep.memory.get()) versus semantic retrieval (zep.memory.search()) serve different prompt integration needs. Session retrieval assembles the full context for a known ongoing conversation, optimised for continuity. Semantic retrieval searches across all sessions for cross-session knowledge, optimised for comprehensive fact lookup. Choosing the right retrieval mode at the prompt integration layer is the primary architectural decision Zep teams face.

Zep's context assembly API is the most complete pre-built prompt integration in this comparison. Calling one endpoint returns a structured, formatted, temporally-framed context block ready to inject. For teams who do not want to design their own memory-to-prompt format, Zep provides a production-tested default. The trade-off is less control: teams that want to format, re-order, or filter memory content before injection need to use the lower-level Graphiti API rather than the high-level context assembly.

MIT License · LangChain Ecosystem

LangMem

State-Unified Prompt

Prompt Pattern

SystemMessage in LangGraph state

PromptTemplate variable binding

Reflection-driven self-update

LangSmith per-step prompt visibility

In-context vs external distinction

01In LangGraph, the system message is part of the graph state. LangMem's in-context memory lives directly in the SystemMessage object and updates as the graph processes each node. There is no separate injection step — memory and system prompt are unified in the same state object that flows through the graph. The developer defines which memory content goes into the system message and which goes into external storage as two explicit design decisions.
02PromptTemplate variable binding: LangMem memory content binds to PromptTemplate variables. A template like "You know the following about this user: {user_memories}" is populated at prompt assembly time from the in-context memory store. This binding approach is familiar to any team using LangChain's prompt management system and requires no new mental model beyond the existing template pattern.
03Reflection chains enable autonomous system prompt updates: after task completion, a LangGraph reflection node reviews the interaction, extracts important facts, and writes them to the memory store. The system prompt context updates itself based on what the agent learned during the task. This self-updating pattern is orchestrated as a graph node, making it traceable and testable as a first-class graph operation.
04LangSmith trace view shows exactly which memory blocks are included in each SystemMessage at each graph step. For debugging incorrect model behaviour, this visibility lets engineers identify whether the issue lies in the model reasoning, the retrieved memories, or the prompt instructions. No other tool in this comparison provides this level of transparency into the memory-plus-prompt interaction during a live agent run.
05For teams using LangGraph's prebuilt ReAct agent, LangMem integrates without custom graph design. The memory_manager tool is added to the agent's tool list. The agent calls it to read and update memories. System prompt integration is handled internally by LangMem's own prompt templates, which inject memories automatically. Teams that want deeper control over the injection format override the default templates with their own.

LangMem's unified state model is its most significant advantage for LangGraph teams: memory IS the state, and the system prompt IS part of the state. There is no interface between memory management and prompt assembly because both are the same object. This simplicity makes prompt engineering and memory engineering the same concern, which is intellectually cleaner and operationally simpler than systems where the two are explicitly separate service calls.

Apache 2.0 · UC Berkeley Origin

Letta

Structured Block Prompt

Prompt Pattern

Named block sections in system prompt

Agent rewrites its own blocks

Token budget per block

Admin UI for block monitoring

Archival never enters the prompt

01Letta's system prompt is structured around named memory blocks with token-budgeted sections. A typical Letta agent system prompt contains: a PERSONA block (who the agent is), a HUMAN block (what the agent knows about the user), a SYSTEM_INFO block (current time, agent status), and a TASK block (current goal). Each block has a maximum token budget configured at agent creation time. The structure is explicit, not a flat text prompt.
02The agent rewrites its own HUMAN and PERSONA blocks during conversation. When the agent learns something new about the user, it calls core_memory_replace to update the block in-place. The system prompt is mutable: not fixed static text that the developer updates externally, but a living document that the agent maintains as part of its ongoing work. This is the property that makes Letta appropriate for agents running for extended periods without developer intervention.
03When a core memory block reaches its token budget, the agent must compress or evict content before new information can be added. Letta raises an error rather than silently truncating. The agent handles the error by compressing or reorganising the block. This explicit handling of memory pressure prevents the silent context overflow that causes hard-to-diagnose quality degradation in systems that truncate automatically.
04Token counting per block is visible in Letta's admin interface. Developers monitor how much of each block's budget is used, which blocks fill fastest, and whether the configured budgets match actual usage patterns. This per-block observability into memory pressure is not available in Mem0 or Zep. It changes memory capacity planning from guesswork to data-driven configuration.
05Archival memory never appears in the system prompt. Only core memory blocks are in the window. Archival content requires an explicit agent function call to retrieve. This hard separation — what the agent always knows versus what the agent can look up — makes Letta's memory architecture the most transparent about what information lives where at any given moment in the agent's operation.

Letta's mutable, agent-maintained system prompt is the most radical departure from conventional prompt engineering in this comparison. Most systems treat the system prompt as a developer-authored static document that the model reads. Letta treats it as a shared working document that the agent and developer co-maintain. This mental model shift has practical consequences: the prompt reflects the current state of the agent's knowledge rather than the developer's initial assumptions about what the agent would need to know.

03

How does each tool retrieve and order context?

What you retrieve matters. The order in which you present it matters almost as much. Research on LLM attention patterns shows that information at the beginning and end of context windows receives significantly more weight than information in the middle. A retrieval system that returns the right facts in the wrong order is only solving half the problem.

View

Apache 2.0 · YC Backed

Mem0

Relevance Plus Recency Scoring

Retrieval Stack

Semantic search (vector)

Graph traversal (optional)

Relevance + recency combined score

Metadata pre-filter

Importance scoring at write time

01Semantic search over the vector store is the primary retrieval path. memory.search(query, user_id) returns the top-k most semantically relevant memories ranked by cosine similarity to the query embedding. The default returns the top five results but is configurable per call. Both relevance and recency feed into the final score, which means a highly relevant memory from a year ago can outrank a weakly relevant memory from yesterday without any developer intervention.
02Metadata filtering before semantic search: filter by user_id, agent_id, memory category, or custom metadata tags before executing the vector search. In a multi-tenant deployment, the user_id filter ensures retrieval never crosses tenant boundaries. This filter runs at the database layer and cannot be bypassed by semantic query manipulation. It is a structural security guarantee rather than a best-effort application-level check.
03Optional graph layer retrieval: when the knowledge graph is enabled, Mem0 can perform entity-based lookups in addition to semantic search. Query for "all memories related to Alice" traverses the graph rather than using semantic similarity. Hybrid search mode combines both paths and merges results by relevance. Graph-based retrieval is most valuable for entity-specific queries where a proper name, not a semantic concept, is the primary filter.
04Memory importance scoring at write time: Mem0 assigns an importance score when a memory is created, based on the content's specificity and utility. Highly specific facts score higher than generic observations. This importance score combines with semantic similarity and recency at retrieval time to produce the final ranking. Teams can override the automatic importance scoring for programmatically important memories by setting explicit importance values at write time.
05No built-in ordering strategy beyond relevance score. The returned memories are ranked highest-relevance first. The developer decides how to arrange these in the system prompt. Mem0's documentation recommends placing the highest-relevance memory first and closest to the user query, based on the primacy effect that positions information at the start of a context section as receiving the most model attention during generation.

Mem0's combined relevance-plus-recency score is a practical improvement over pure semantic similarity for production memory retrieval. Pure semantic similarity returns the most similar memories regardless of age, which means stale preferences and outdated facts surface alongside current ones. The recency component gently demotes older memories without eliminating them, preserving the ability to retrieve distant but relevant memories when current context has no good match.

Graphiti Apache 2.0 · Zep Cloud Managed

Zep

GraphRAG with Temporal Ordering

Retrieval Stack

GraphRAG (graph then vector)

Temporal validity filtering

Community subgraph retrieval

Historical timestamp queries

Session vs semantic retrieval modes

01GraphRAG retrieval: Zep first traverses the knowledge graph for entity relationships relevant to the query, then applies vector search within the identified subgraph. This two-pass approach returns facts that are both semantically related to the query AND structurally connected to the relevant entities. Pure vector search returns semantically similar text regardless of structural relevance. GraphRAG returns text that is both.
02Temporal ordering is the most distinctive retrieval feature in this comparison. When multiple facts about the same entity exist, Zep retrieves them ordered by temporal validity: the most recently valid fact appears first. Historical facts are retrievable by specifying a reference timestamp. "What was Alice's role as of Q3 2025?" returns the fact valid at that time period rather than the current one. No other tool in this comparison supports temporal point-in-time queries natively.
03Community subgraph retrieval expands the scope of context in a principled way. Retrieving context for a specific customer account returns not just facts about that account but also the related entities that form its community: contacts, active deals, product subscriptions, and recent support tickets. This relationship-aware expansion surfaces context that pure semantic similarity would miss because it is structurally adjacent rather than semantically adjacent.
04Session retrieval versus semantic retrieval serve different needs. zep.memory.get(session_id) assembles the complete context for an ongoing conversation, optimised for continuity within a session. zep.memory.search(query, user_id) searches across all sessions for a user, optimised for cross-session knowledge recall. The API design reflects the observation that within-session retrieval and cross-session retrieval are fundamentally different operations with different performance requirements.
05Published latency: 90% reduction compared to full conversation history injection. The GraphRAG traversal plus vector search adds overhead versus pure vector search, but the reduction in total tokens injected more than compensates for that overhead in overall inference time. Fewer tokens in context means faster model generation, and the reduction in generation latency is larger than the addition in retrieval latency for typical production query lengths.

Zep's temporal point-in-time query capability is the retrieval feature with the fewest alternatives in the AI memory ecosystem. Teams building in domains where the question "what was true at this moment in time" is relevant — legal AI, financial AI, healthcare AI, customer relationship AI — get this capability structurally from Zep's graph architecture without custom implementation. Building equivalent temporal query capability on top of a vector-only memory system requires significant custom engineering.

MIT License · LangChain Ecosystem

LangMem

Agent-Initiated with MMR Ordering

Retrieval Stack

Zero-latency in-context access

Agent-initiated external retrieval

MMR for diversity ordering

Scheduled vs triggered modes

Relevance threshold filtering

01In-context memory retrieval is zero-latency: the content is already in the LangGraph state, no external call required. External memory retrieval is a tool call that the agent initiates when it judges retrieval is necessary. The distinction between always-available in-context memory and on-demand external memory is the core retrieval architecture decision in LangMem, and it must be designed explicitly by the developer rather than inferred from usage patterns.
02Retrieval is agent-initiated for external memory: the agent calls the search_tool at the moment it judges context is needed. This means retrieval timing is part of the agent's own reasoning. A complex multi-step agent can retrieve background context at task start, specific facts during execution, and precedents during decision points — each retrieval call targeting a different aspect of the task rather than running one broad retrieval at the start of every turn.
03Maximal Marginal Relevance ordering: LangMem supports MMR for external memory retrieval, which balances similarity to the current query with diversity among the returned results. Without MMR, a retrieval call for "user preferences" might return five nearly identical memories about the same preference stated in different phrasings. With MMR, the returned set covers different aspects of user preferences even when multiple memories are highly similar to each other.
04Scheduled versus triggered retrieval: LangMem supports both patterns. Scheduled retrieval runs every N turns regardless of query content, ensuring long-running agents do not drift from established context as sessions progress. Triggered retrieval runs when the agent's confidence falls below a threshold or when the query explicitly references past interactions. Teams choose based on their agent's task profile and how frequently memory context changes relative to task context.
05Relevance threshold filtering: configure a minimum similarity score below which results are not returned even if they fall within the top-k range. This prevents low-quality memories from entering the context window when the query has no strong match in the memory store. LangMem returns an empty list rather than forcing low-quality matches into the prompt. This zero-result-is-better-than-noise behaviour is the correct default for production agents where incorrect context is worse than no context.

LangMem's agent-initiated retrieval model reflects a specific philosophical stance: the agent should decide when it needs additional context rather than having the framework decide on its behalf. This stance increases the intelligence requirement for the agent (it must know when it does not know something) but decreases the risk of retrieving irrelevant context that misleads the agent. For agents operating on tasks with highly variable context requirements, agent-initiated retrieval avoids the overhead of unnecessary context injection on every turn.

Apache 2.0 · UC Berkeley Origin

Letta

Explicit Agent-Controlled Paging

Retrieval Stack

Agent-called search_archival_memory

FIFO history eviction to archival

Semantic search over archival

Cross-agent shared block access

Recency as tiebreaker

01All archival retrieval in Letta is explicit and agent-initiated. The agent calls search_archival_memory(query) when it needs to recall something from outside the main context window. There is no automatic background retrieval running on the developer's behalf. Retrieval timing, query formulation, and result integration are all part of the agent's visible reasoning process rather than happening in invisible framework infrastructure.
02Conversation history uses FIFO eviction when the main context approaches its limit. The oldest messages page out to archival memory rather than being deleted. The agent can retrieve them later via search_archival_memory. Letta never permanently loses conversation history — it moves content out of the active window where it was causing degradation and into archival where it is retrievable on demand. This eviction-to-archival model is what makes Letta memory loss-free.
03Retrieval ordering within archival search: results are ordered by semantic similarity with recency as a tiebreaker for equal similarity scores. The agent receives retrieved text and integrates it into its reasoning. There is no structured result format beyond the text content and basic metadata. The agent reads retrieved text the same way a human reads search results — determining what is relevant to the current task rather than relying on a pre-computed ranking.
04Cross-agent shared memory blocks: Letta supports memory blocks that are accessible to multiple agents in the same application. A shared HUMAN block means different agents serving the same user share the same user facts without duplicating storage or risking inconsistency. When one agent updates a shared block, the update is immediately reflected for other agents reading the same block. Cross-agent retrieval consistency is structural rather than requiring synchronisation logic.
05Archival memory grows without a hard limit beyond the underlying vector store capacity. The practical limit is search quality: a very large archival store with redundant or low-quality content produces noisier retrieval results than a carefully maintained one. Teams running Letta agents over months should periodically review archival content quality, a maintenance task that the other three tools handle through extraction and deduplication at write time rather than leaving it as a post-hoc concern.

Letta's explicit agent-controlled retrieval makes the agent responsible for its own knowledge management in a way that the other three tools do not. The agent that calls search_archival_memory is the same agent whose quality the developer cares about. If the agent retrieves wrong context, that failure is visible in the agent's function call log. If the agent fails to retrieve necessary context, that gap is also visible. The explicitness of Letta's retrieval model is its primary debugging advantage over approaches where retrieval happens implicitly in framework infrastructure.

04

How does each tool compress context?

Every conversation adds tokens. Every stored memory adds storage. Left unmanaged, both grow until they degrade performance or exceed limits. Context compression is what keeps production AI systems lean over time: the techniques for reducing token footprint without losing the signal that matters.

View

Apache 2.0 · YC Backed

Mem0

Compression at Source

Compression Stack

Extraction as compression

Conflict resolution and update

Entity deduplication

Bounded memory bank growth

5-10x compression ratio typical

01Compression happens at the source: the extracted memory IS the compressed representation. Mem0 never stores raw conversation turns. The LLM extraction pass converts conversations into discrete, structured facts before storage. A 500-token conversation typically produces three to five memory facts averaging 30 to 50 tokens each. The compression ratio is roughly five to ten times depending on conversation content density and how much of the conversation consists of navigational dialogue versus substantive information exchange.
02Conflict resolution compresses over time: when new facts contradict stored facts, Mem0 updates or replaces rather than appending. "User prefers Python" stored in January is updated to "user switched to TypeScript" when that arrives in March. The memory bank reflects the current state of knowledge rather than a historical log of every stated preference. Accumulated contradictions do not pile up as parallel facts that confuse retrieval.
03Entity deduplication: when the same entity appears in multiple memory facts, Mem0's graph layer groups them by entity node. "Alice is the project manager" and "Alice joined the team in 2024" share the Alice node. Retrieval for Alice returns both facts without storing redundant entity metadata for each one separately. This implicit deduplication reduces storage overhead in information-dense domains where the same entities appear repeatedly.
04Memory bank size in Mem0 is bounded by the number of extractable facts, not by the volume of conversations. An agent with 1,000 conversation sessions might have 200 to 500 distinct memories because many sessions update or confirm existing facts rather than generating new ones. This bounded growth is a property of the extraction approach rather than a configured storage limit. Teams do not need to manage memory bank size manually.
05The cost of Mem0's compression approach is one additional LLM call per memory write: the extraction LLM reads the conversation and produces structured facts. For high-volume applications, this write-time LLM cost is real and should be budgeted. For most production use cases, the reduction in inference latency from smaller injected context more than compensates for the extraction cost at write time on a per-session basis.

Mem0's extraction-as-compression approach produces the most complete compression solution in this comparison because it compresses at write time rather than at read time. By the time any memory is retrieved, it is already in its minimum viable form. There is no compression step at retrieval time that could degrade the signal. The risk is that the extraction quality determines the compression quality: an extraction LLM that misses important facts or produces hallucinated facts is compressing incorrectly, and incorrect compression is worse than no compression.

Graphiti Apache 2.0 · Zep Cloud Managed

Zep

Graph Summarisation

Compression Stack

Entity-relationship as compression

Community summaries (hierarchical)

Invalid fact retention without cost

Session summary generation

3-8x compression typical

01Conversations compress into entity nodes and relationship edges rather than text summaries. The graph representation stores information in its minimum necessary form — relationships are edges, facts are node properties, entities are nodes. A ten-turn conversation about a customer typically compresses into three entity nodes, five edges, and six fact properties. The total serialised token count of this graph representation is typically three to eight times smaller than the original conversation text.
02Community summaries provide hierarchical compression: Zep's community detection groups related entities and generates summaries at the community level via an internal LLM call. A community summary for a large enterprise account might be 200 tokens, replacing 5,000 tokens of detailed individual facts and relationship traversals. Teams control the granularity at which Zep context is injected — community summary for general queries, individual fact retrieval for specific ones.
03Invalid fact retention without meaningful storage cost: when a fact becomes invalid because new information contradicts it, Zep marks it with an invalid_at timestamp rather than deleting it. The invalid fact does not appear in current-state retrieval results. Its storage cost in the knowledge graph is a boolean flag on an existing node, not a new storage entry. Historical access is preserved without inflating the current context returned to the model.
04Session summary generation: at the end of a long session, Zep generates a structured text summary of the session's key facts and stores it as a special memory type. This summary serves as the context anchor for the next session, preventing the next session from needing to traverse the full session fact graph. Teams that prefer text-based session handoffs over graph-based retrieval use session summaries alongside or instead of structured fact retrieval.
05The primary compression risk in Zep: extraction errors compound in the graph. An incorrectly extracted entity relationship becomes a structural error that propagates to all future retrieval involving those entities. In a vector-only system, a single incorrect embedding has limited scope. In a graph system, a single incorrect edge can mislead every query that traverses through it. Monitoring graph extraction quality with periodic audits is more critical in Zep than in vector-only or extraction-into-flat-store approaches.

Zep's graph-based compression has a property that text-based compression cannot replicate: the compressed form (entity nodes and relationship edges) is queryable in ways that text summaries are not. A text summary of a customer account answers "what is the general situation with this customer." A graph representation of the same account answers "what was the deal status on this date," "who are all the contacts at this account," and "which products does this account use" — all as structured queries rather than semantic guesses.

MIT License · LangChain Ecosystem

LangMem

Pipeline-Level Compression

Compression Stack

Compression nodes in LangGraph

Progressive summarisation

Token budget via template variables

External memory threshold compression

LangSmith compression audit trail

01LangMem compression happens at the state management layer in LangGraph. A compression node can be inserted at any graph edge to summarise the growing state before it passes to the next node. This makes compression a first-class graph operation rather than a side process running outside the main execution. The developer can observe and test compression behaviour as part of the overall agent pipeline rather than as a separate memory management subsystem.
02Progressive summarisation: a common production pattern with LangMem is converting episodic memories (specific interaction records with full context) into procedural memories (general patterns and preferences extracted from multiple episodes) over time. A reflection chain compares recent episodic memories, identifies recurring patterns, and writes a procedural memory summarising the pattern. The episodic memories remain available in external storage but the procedural memory provides efficient retrieval for the most common query patterns.
03PromptTemplate variable slots enforce implicit compression: if a template variable for user memories is limited to 500 tokens, only the top memories within that budget are injected. The template enforces the compression budget without requiring explicit compression code. This implicit enforcement is the simplest form of compression and the one most LangMem teams implement first before adding more sophisticated compression chains.
04External memory compression threshold: configure a maximum entry count or token limit for the external memory store. When the store approaches the limit, a compression chain runs automatically, consolidating related memories and archiving low-relevance ones. This managed compression prevents unbounded store growth without requiring developer attention at runtime, while remaining fully configurable when teams want custom compression logic.
05Compression evaluation via LangSmith: after each compression chain executes, the compressed output is logged as a trace in LangSmith. Teams compare pre-compression and post-compression memory content side by side to verify that important facts were preserved and low-relevance memories were correctly removed. This per-compression-run observability makes LangMem's compression behaviour auditable in production without custom logging infrastructure.

LangMem's pipeline-level compression is the most developer-controlled of the four approaches. Every compression decision is an explicit graph node that the developer designed, configured, and can observe in LangSmith. This control is valuable for teams with specific compression quality requirements or teams building in regulated domains where every data transformation needs an audit trail. The trade-off is that the developer owns the compression logic entirely — there is no default compression that works without configuration.

Apache 2.0 · UC Berkeley Origin

Letta

Agent-Authored Compression

Compression Stack

Agent rewrites blocks when full

FIFO eviction to archival

No auto-summarisation

Admin UI for budget monitoring

Periodic maintenance runs

01Core memory compression is entirely agent-controlled and explicit. When a memory block approaches its token budget, the agent calls core_memory_replace with a compressed version it wrote itself. No automatic summarisation runs. No framework-level compression logic executes. The agent performs the compression as part of its active reasoning. This means compression quality reflects the underlying model's ability to summarise, which is a direct function of model capability rather than framework implementation.
02FIFO eviction from in-context conversation history is the primary compression mechanism for conversation turns. The oldest messages page out to archival memory when the conversation context approaches the configured limit. Eviction is automatic and requires no LLM call — it is a structural operation based on token count. The agent can retrieve evicted turns from archival later if needed. Letta never discards conversation history, it only relocates it.
03Archival storage has no built-in compression: content written to archival is stored as-is without transformation. The archival store functions as long-term memory that is never in the active context window, so its token count does not affect inference cost. The concern is retrieval quality — a large archival store with redundant content produces noisier semantic search results. Periodic archival review is a developer responsibility rather than a framework-managed process.
04Multi-pass compression for long-running agents: in production deployments running Letta agents over days or weeks, a scheduled maintenance run can be triggered where the agent reviews its own core memory blocks, identifies outdated or redundant content, and compresses it into more efficient representations. This deliberate self-maintenance is a capability unique to Letta's OS-inspired architecture, where the agent is an active participant in its own memory management.
05Token budget configuration is the primary compression tuning lever in Letta. Smaller budgets force more aggressive compression by the agent. Larger budgets allow more information in core memory without compression pressure. Teams typically discover the right configuration through production observation: watch which blocks fill fastest, whether important information is being compressed away too aggressively, and whether the agent's behaviour degrades as blocks approach their limits.

Letta's agent-authored compression produces a qualitatively different result from automated compression in the other three tools: the compressed content reflects the agent's judgment about what matters, which should be aligned with what the agent actually uses in its reasoning. Automated compression algorithms produce summaries based on general salience heuristics. Agent-authored compression produces summaries that preserve what this specific agent with this specific task profile judges to be most important. For specialised domain agents, that distinction can be significant.

05

How does each tool handle few-shot and example management?

Few-shot examples are among the most powerful tools in context engineering. The right example changes what the model produces more reliably than additional instructions. The question is not whether to use examples but how to store them, how to select the right ones for each query, and how to prevent example banks from becoming stale or biased toward the most recent interactions.

View

Apache 2.0 · YC Backed

Mem0

Emergent Procedural Memory

Few-Shot Pattern

Procedural memories at write time

Interaction pattern storage

Category-based example retrieval

Importance-scored example ranking

No native structured example bank

01Procedural memories: Mem0 can store not just facts about users but also patterns of successful interaction. "When the user asks for code examples, they prefer TypeScript with explicit type annotations" is a procedural memory that functions as implicit few-shot guidance when retrieved alongside factual context. These procedural memories modify how the agent responds without requiring explicit input-output examples in the prompt.
02Storing successful interaction patterns: after a user responds positively to a particular response style or format, the developer can store that interaction pattern as a memory using memory.add() with a category tag like "style_preference" or "successful_pattern." Retrieved at inference time alongside factual memories, these style memories guide the agent's output format without consuming the token budget that structured few-shot examples require.
03Category-based example retrieval: tag memories by category at write time and filter by category at retrieval time. A category for "communication_preferences" stores stylistic guidance. A category for "task_patterns" stores procedural guidance. A category for "domain_knowledge" stores factual context. Selective category retrieval at inference time allows the developer to control which type of memory influences the current call.
04The extraction LLM quality determines whether behavioural patterns are correctly captured. Good extraction produces a reusable procedural memory from a successful interaction. Poor extraction might miss the behavioural signal entirely and store only the factual content. Teams that need reliable procedural memory extraction often provide custom extraction prompts that specifically direct the extraction LLM to identify and preserve interaction patterns alongside factual content.
05Mem0 does not natively manage a structured few-shot example bank with explicit input-output pairs and reasoning traces. The few-shot function in Mem0 is emergent from stored interaction memories. For applications that need highly structured few-shot examples with specific format demonstrations, using Mem0's memory.add() with consistent formatting discipline at write time works but requires the developer to maintain that formatting consistency without framework-level enforcement.

Mem0's emergent few-shot approach works well for style and tone guidance but is less suited for demonstrating complex structured task formats. When the goal is "remember that this user likes concise responses," Mem0 handles it naturally as a procedural memory. When the goal is "demonstrate exactly how to format a SQL query analysis with headers and code blocks," Mem0 can store such examples but requires the developer to ensure consistent formatting at write time. Purpose-built example banks with structured schemas serve the latter use case better.

Graphiti Apache 2.0 · Zep Cloud Managed

Zep

Temporal Episodes as Examples

Few-Shot Pattern

Episode-level retrieval

Temporal example selection

Relationship-aware example matching

Pattern detection across sessions

No native structured example schema

01Temporal episodic memory as a few-shot source: Zep stores past interaction episodes with full temporal context. Retrieving "successful interactions on task type X in Q1 2026" returns episodes that inform the current approach as temporally grounded examples. The temporal dimension adds the capability to retrieve seasonally relevant examples or to exclude examples from periods when the system was producing incorrect outputs.
02Episode-level retrieval: beyond individual facts, Zep can retrieve entire conversation episodes as structured objects. An episode includes the original messages, extracted entities, temporal metadata, and a summary. A retrieved episode injected into the system prompt provides richer few-shot context than a single extracted fact because it includes the full input-output exchange in its original form with temporal framing.
03Relationship-aware example selection: Zep's knowledge graph captures entity relationships, enabling retrieval of examples involving the same entities as the current query. A new query about a specific customer retrieves past successful interactions involving that customer, providing customer-specific few-shot context rather than generic examples from unrelated interactions. For customer-facing agents, this personalised example retrieval is a meaningful quality improvement over generic bank retrieval.
04Pattern detection across sessions through community subgraph analysis: the community summary for a customer segment includes patterns that emerged from multiple successful interactions over time. This emergent pattern documentation functions as learned few-shot guidance at the segment level without requiring the developer to manually curate which interactions were representative enough to serve as examples.
05Zep is optimised for factual and relational memory, not for maintaining a structured few-shot example bank with explicit input-reasoning-output format. Teams that need rigorously formatted examples with visible reasoning chains are better served by a dedicated example vector store alongside Zep, with Zep handling the factual context layer and the example store handling the structured demonstration layer separately.

Zep's temporal episode retrieval produces the most contextually-rich few-shot source in this comparison for customer-facing applications. Retrieving "how did we handle this successfully last quarter with this specific customer" is a more powerful few-shot signal than retrieving "here is a generic example of handling this task type." The trade-off is that episode-level retrieval is noisier than structured example bank retrieval — episodes contain navigational dialogue, corrections, and context that is not relevant to the current task alongside the useful demonstration content.

MIT License · LangChain Ecosystem

LangMem

Structured Example Bank with Reflection

Few-Shot Pattern

Reflection chain example extraction

LangSmith production tagging

MMR diversity for example sets

Recency window filtering

Cross-session example accumulation

01Reflection chains explicitly support converting successful interactions into stored structured examples. After task completion, a LangGraph reflection node generates a structured example with input, reasoning trace, and output, then writes it to the external memory store. The next time a similar task is encountered, the stored example surfaces as a retrieved few-shot demonstration with explicit structure rather than as an unformatted episode.
02LangSmith example collection: any LangGraph run logged in LangSmith can be tagged as a canonical example and exported to the LangMem external memory store. Teams curate good examples directly from production traces rather than constructing them manually from scratch. This production-to-example pipeline reduces the gap between synthetic examples and real task complexity, which is the primary quality failure mode in manually curated example banks.
03MMR ordering for example selection: when retrieving from the example bank, LangMem uses Maximal Marginal Relevance to balance relevance to the current query with diversity among the returned example set. Without MMR, the example bank returns three nearly identical examples for queries that would benefit from demonstrations covering different edge cases. With MMR, the example set covers the full range of relevant variations.
04Recency window for example freshness: configure a maximum age for examples returned from the bank. If the task domain is rapidly evolving — an agent assisting with a codebase that changes weekly — examples older than 30 days might be excluded to prevent outdated behavioural guidance from influencing current generation. The freshness filter is a parameter on the search call rather than a global store configuration.
05Cross-session example accumulation: examples written to the external memory store persist across sessions. An agent that handles 1,000 tasks over three months accumulates up to 1,000 examples in its external store. The retrieval mechanism surfaces only the most relevant few at each inference call. The bank improves over time as more successful interactions are captured and made retrievable, without the developer curating every new addition manually.

LangMem's reflection-chain approach to few-shot management is the most principled path from production traces to structured examples. The developer designs a reflection node that decides what counts as a good example and how to format it for storage. Over time, the example bank fills with production-derived demonstrations that are more representative of real task difficulty than manually authored ones. The quality ceiling for this approach is the quality of the reflection node design, not the volume of examples collected.

Apache 2.0 · UC Berkeley Origin

Letta

Archival as Example Bank

Few-Shot Pattern

Pre-populated archival examples

Agent-selected retrieval timing

Persona block for implicit guidance

Agent-authored quality notes

Manual or pipeline-fed accumulation

01Archival memory functions as the few-shot example bank in Letta. Canonical examples are stored in archival at agent initialisation with descriptive content that makes them retrievable by semantic search during task execution. The agent retrieves relevant examples via search_archival_memory when it encounters a task type for which examples would be useful, and integrates them into its reasoning before generating output.
02Agent-selected few-shot usage: the agent decides when to look for examples and when to skip retrieval. For unfamiliar task types, a Letta agent learns to retrieve examples before attempting the task. For familiar tasks within its established competency, it skips the retrieval step and works from core memory alone. This selective retrieval avoids injecting unnecessary few-shot context on turns where the agent already has sufficient guidance, which is the majority of turns in a well-functioning long-running agent.
03Persona block for implicit few-shot guidance: the Persona core memory block can include compressed best-practice guidance and behavioural patterns that function as standing implicit few-shot direction. This is different from explicit stored examples — it is behavioural guidance compressed into the agent's always-available working memory. The advantage is zero retrieval latency. The constraint is the Persona block's token budget, which limits how much guidance can live there permanently.
04Quality notes from experience: Letta agents can store notes about their own performance in archival memory. After a task that went poorly, the agent stores a note about the failure mode. Future retrievals for similar tasks surface both success examples and failure notes, providing a balanced few-shot context that includes what to avoid alongside what to replicate. This self-generated quality feedback loop is unique to Letta's agent-driven memory model.
05Letta's example management requires the most direct developer involvement of the four tools. There is no automatic example extraction from production interactions and no reflection chain that identifies which interactions are worth storing. Pre-populating archival with good examples at initialisation is straightforward. Building an ongoing pipeline that evaluates production interactions and adds good ones to archival requires custom work outside of Letta's built-in functionality.

Letta's agent-selected few-shot retrieval is the most token-efficient approach in this comparison because examples only enter the context window when the agent actively calls for them. The other three tools inject examples alongside every retrieval result or at fixed prompt positions. Letta's agent decides whether the current task needs examples. For agents with high task diversity, this selective injection avoids polluting simple-task responses with complex-task examples. The cost is that the agent must reliably know when it needs help — a capability that depends on the quality of the underlying model.

06

How does each tool address long-context degradation?

LLM attention is not uniform across context. Research consistently shows that models attend more strongly to content at the beginning and end of context windows than to content in the middle — the "lost in the middle" effect. Add to this the accumulation of stale facts, contradictory information, and low-relevance historical content, and long-running AI applications degrade in ways that are difficult to diagnose and expensive to fix after launch.

View

Apache 2.0 · YC Backed

Mem0

Structural Prevention

Degradation Defense

Clean session start every time

Selective injection prevents bloat

Conflict resolution removes staleness

ECAI 2025 validation

Session isolation by design

01Mem0's architecture structurally prevents the classic long-context degradation pattern. Every conversation starts with a clean context window. Memories are retrieved selectively based on the current query. There is no growing conversation history living in the window across sessions. The degradation problem assumes an accumulating context; Mem0 removes the accumulation. The ECAI 2025 paper validated this approach against the assumption that bigger windows eliminate the need for selective memory — they do not.
02The ECAI 2025 benchmark result challenged the most common intuition about context engineering. Models with access to the full conversation history at very long session lengths performed worse on multi-hop reasoning tasks than models using Mem0's selective memory injection. The finding is specific: more context is not better past a certain length. Curated context of the right facts outperforms exhaustive context containing those facts plus everything else.
03Conflict resolution removes staleness automatically. When a user's preference changes, Mem0 updates the stored fact rather than appending the new preference alongside the old one. The agent never receives both "user prefers Python" and "user switched to TypeScript" in the same retrieval result. Stale facts do not accumulate because Mem0's write logic resolves conflicts at ingestion rather than leaving resolution to the model at inference time.
04Session isolation prevents cross-session contamination. Each new session retrieves only the memories semantically relevant to the current query. Old memories from unrelated prior interactions do not pollute the current context window. A customer support agent serving the same user for three years does not start each session with three years of context — it starts with the facts relevant to today's issue. Session quality is consistent across the user's lifetime.
05Mem0's most significant limitation for degradation in single-session contexts: very long conversations where the extraction mechanism processes interactions in real time may experience latency if the extraction LLM cannot keep pace with rapid-fire exchanges. For sessions with thousands of turns in a short period, configuring explicit session break points with memory flush operations is the recommended pattern rather than relying on continuous real-time extraction throughout.

Mem0's defence against long-context degradation is fundamentally architectural rather than operational. There is no remediation step after context grows too long because the architecture prevents unbounded context growth from happening in the first place. The ECAI 2025 paper provides the strongest published evidence that this approach is not just operationally simpler but actually produces better outputs than alternatives. That combination — simpler to operate AND better performing — is rare in engineering decisions.

Graphiti Apache 2.0 · Zep Cloud Managed

Zep

Temporal Graph as Staleness Prevention

Degradation Defense

Automatic fact invalidation

Community clustering limits scope

Session summaries for handoffs

LongMemEval 63.8% benchmark

GraphRAG scope control

01Temporal graph architecture provides the most principled defence against staleness accumulation. In vector-only memory systems, an outdated fact remains in the retrieval pool unless explicitly deleted. Zep marks it as invalid when a contradicting fact arrives, automatically excluding it from current-state retrieval while preserving it for historical queries. For domains where facts change frequently — customer relationship state, project status, medical records — this automatic staleness management prevents the most common source of degradation in long-running agents.
02LongMemEval benchmark results reflect Zep's architectural strength on extended memory evaluation: 63.8% accuracy versus Mem0's 49.0% on the same benchmark in independent evaluations published in May 2026. LongMemEval specifically tests factual accuracy, temporal reasoning, and consistency across very long interaction histories. Zep's superior performance on this benchmark reflects the graph architecture's advantage for maintaining accurate long-term context at extended history lengths.
03Community clustering bounds the retrieval scope as the knowledge graph grows. Without community detection, retrieving context for any entity in a large graph would eventually traverse an unmanageable subgraph. Community clustering groups related entities and provides summary-level access to communities rather than requiring exhaustive traversal. As the graph grows over months of production use, retrieval quality remains stable rather than degrading with graph size.
04Session summary generation at the end of long sessions: Zep generates a structured summary of the session's key facts and stores it as a special memory type. This summary serves as the context anchor for the next session rather than requiring traversal of the full session history. Long-running agents that use session summaries start each new session with a compact, relevant context rather than with the full weight of their interaction history.
05The primary degradation risk specific to Zep: extraction errors compound in the graph structure. An incorrectly extracted entity relationship becomes a structural error that influences every future retrieval involving those entities. In a vector-only memory system, a single incorrect embedding has limited scope — it affects only queries close to that embedding in the semantic space. In a graph system, a single incorrect edge affects every graph traversal that passes through it. Monitoring graph extraction quality through periodic audits is more important in Zep than in alternatives and should be treated as a production maintenance requirement rather than an optional quality improvement.

Zep's LongMemEval advantage over Mem0 reveals where the temporal graph architecture earns its complexity. At short to medium history lengths, Mem0's simpler approach performs comparably. At very long history lengths where temporal reasoning — understanding how facts evolved over time rather than just what is currently true — becomes important, Zep's graph architecture pulls ahead. For applications with months or years of interaction history per user, this difference becomes the deciding architectural factor.

MIT License · LangChain Ecosystem

LangMem

Developer-Controlled Compression Gates

Degradation Defense

Compression nodes at graph edges

Rolling memory strategy

LangSmith token utilisation monitoring

Episodic to procedural memory shift

Configurable retention windows

01LangGraph checkpointing creates natural compression points at every node transition. When context grows too large, a compression node inserted at any graph edge produces a smaller state snapshot that becomes the input for the next node. The developer explicitly designs where compression occurs in the graph, making degradation prevention a deliberate architectural decision rather than an emergent result of the memory system's defaults.
02Rolling memory strategy: periodic replacement of episodic memories (specific interaction records with full context) with procedural summaries (general patterns extracted from multiple episodes) prevents storage growth while preserving the behavioural learning those episodes represent. Over time a LangMem agent's external memory store shifts from detailed episode records to compact procedural summaries, reducing retrieval overhead while maintaining the accumulated knowledge.
03LangSmith token monitoring: LangSmith tracks the token count of every message in every graph step. Teams observe context window utilisation trending upward across sessions and configure automated alerts before degradation becomes visible in output quality. This proactive monitoring transforms degradation prevention from a reactive firefighting task into a planned maintenance activity with measurable leading indicators.
04External memory as overflow for in-context content: when in-context memory approaches the configured state size, memories move to the external store and become retrieval-dependent rather than always-available. This graceful demotion preserves the most critical context in the zero-latency in-context path while maintaining full access to complete history via semantic retrieval when needed.
05Compression quality evaluation after every compression run: the compressed output logs as a trace in LangSmith. Teams compare pre-compression and post-compression memory content side by side to verify that important facts were preserved. This per-run compression audit catches cases where important facts were lost before those losses propagate into agent behaviour degradation in production. The audit step requires configuration but the infrastructure for it is built into LangSmith without additional tooling.

LangMem's degradation defence strategy requires the most deliberate design work upfront but produces the most observable system in operation. The developer who designs compression nodes, rolling memory strategies, and retention windows understands exactly how their agent manages context over time. When degradation occurs despite these measures, LangSmith's per-step token monitoring and compression audit logs provide clear evidence of where the failure happened. Observability-first degradation prevention is more maintainable than architecturally-enforced prevention because it remains tunable as production patterns change.

Apache 2.0 · UC Berkeley Origin

Letta

Structurally Impossible to Degrade

Degradation Defense

Fixed core memory budget enforced

FIFO eviction prevents overflow

No "lost in the middle" possible

Consistent context size across sessions

93.4% DMR benchmark

01The OS-paging model is Letta's fundamental architectural answer to long-context degradation. Core memory has a fixed token budget. Conversation history evicts when the limit is reached. Archival memory is unlimited but never directly in the context window. The agent physically cannot accumulate unbounded context because the architecture makes it structurally impossible. This is the same class of guarantee that Mem0 provides — not a mitigation strategy but a structural prevention.
02The "lost in the middle" attention degradation problem does not apply to Letta in the same way it applies to systems with long flat context windows. Core memory is small, structured into named blocks, and the agent always knows exactly where relevant information lives. Information in the Human block is user facts. Information in the Persona block is behavioural guidance. The structured layout prevents the attention diffusion that causes quality loss when important information is buried somewhere in undifferentiated long context.
03Agent quality is consistent across the entire deployment period for long-running Letta agents. The same core memory size at week one is the same core memory size at week twenty. The agent does not accumulate context weight over time. For deployments where consistent quality over extended periods is a requirement, Letta's fixed-budget core memory is the strongest architectural guarantee in this comparison. The consistency is not aspirational — it is enforced by the token budget configuration.
04DMR benchmark validation at 93.4%: the Deep Memory Retrieval benchmark specifically evaluates the ability to accurately recall specific facts from memory stores in long-running scenarios. Letta's strong performance reflects the archival memory's semantic search quality at scale. The competing challenge is retrieval precision as archival grows larger over a multi-week deployment. Teams should monitor retrieval precision alongside core memory utilisation to ensure the paging model remains effective as the archival store accumulates months of interaction history.
05Self-maintenance for archival quality: in production deployments running for weeks, a periodic maintenance run where the agent reviews its archival memory, identifies redundant or low-quality content, and removes it prevents the gradual quality degradation of semantic search over noisy archival stores. This deliberate self-maintenance is a capability unique to Letta's architecture where the agent is an active participant in its own memory management. Scheduling these maintenance runs is a production deployment consideration that documentation recommends but does not automate.

Letta's structural impossibility of context overflow is the strongest form of degradation prevention in this comparison. Mem0 achieves similar structural prevention through extraction-as-compression. Zep achieves it through temporal graph management. LangMem achieves it through developer-designed compression gates. Letta achieves it through the OS paging model that enforces fixed budgets. Each approach works; the meaningful difference is failure mode. If Letta's paging model fails, the agent stops accepting new information. If LangMem's compression gates fail, context silently grows. The failure modes that are visible and loud are preferable to those that are silent and gradual.

M

Methodology

What counts as fact in this study, what counts as the author's interpretation, and what to verify before making decisions based on this research.

📄

Official Documentation

SDK docs, GitHub READMEs, release notes, and API references for Mem0, Zep (Graphiti), LangMem, and Letta. Verified against source URLs in August 2026. Product features and pricing subject to change.

📊

Published Benchmarks

ECAI 2025 paper (arXiv:2504.19413) for Mem0. Zep arXiv paper (January 2025) and WeavAI May 2026 review for Zep LongMemEval and DMR scores. All benchmark numbers are directional. Run your own evaluations on your specific task and history length.

🔍

Independent Reviews

RockB May 2026 Zep review, Vectorize March 2026 Mem0 vs Zep comparison, Atlan April 2026 analysis, TheAIAgentIndex July 2026 Zep review. Used for pricing verification and production deployment pattern validation.

💭

Author Synthesis

Comparative tradeoff assessments and architectural interpretations appear under the insight label. These are reasoned conclusions from primary and secondary sources. Disagreement with an insight is disagreement with reasoning, not with a factual source.

What this study covers and what it does not

This volume covers four tools specifically designed for AI memory and context management. It does not cover building a custom context management system without a specialised tool. It does not cover pure RAG pipelines where retrieval serves document lookup rather than persistent memory. It does not cover AWS AgentCore Memory, Vertex AI Memory Bank, or Cognee, which are emerging alternatives that were not mature enough for production comparison as of the research date.

The benchmark dispute between Zep and Mem0 regarding LOCOMO scores (Zep originally claimed 84%, Mem0 corrected this to 58.44% alleging adversarial category inclusion errors, Zep counter-claimed 75.14%) is documented in GitHub Issue getzep/zep-papers/issues/5. Neither vendor's numbers are used uncritically. The LongMemEval and DMR benchmarks cited in this volume are from independent evaluation sources.

Research timeline

Researched August 2026. Primary sources: official documentation for all four tools. Secondary sources: RockB Zep review (May 2026), Vectorize Mem0 vs Zep comparison (March 2026), WeavAI Zep review (May 2026), TheAIAgentIndex Zep profile (July 2026), Atlan analysis (April 2026), Zep blog (updated June 2026). Research material provided by the author as supplementary input.

Last Updated: August 15, 2026

Swarnim
Tiwari

AI Systems Researcher

Every conversation with an AI starts from zero. The model has no memory of what you explained last week, what it learned about your preferences, or what happened in the session before this one. This is not a bug. It is how transformers work.

Context engineering is the practice that grew up around solving this. Not by changing the architecture of the model but by building systems around it that manage what enters the window, in what form, and when to remove it.

This volume compares four tools specifically built for the memory layer of AI applications. Mem0, Zep, LangMem, and Letta each solve the same underlying problem from a genuinely different angle. Understanding which angle fits your workload is the real engineering decision.

I am a student in India. This volume took longer to understand than any previous one. Memory in AI involves temporal graphs, OS-style paging concepts, semantic deduplication strategies, and compression tradeoffs that each have real production consequences.

LinkedIn GitHub

AI Systems Studies — Publication Series

Vol. 01Production AI Architecture — OpenAI, Anthropic, Palantir, NVIDIAPublished

Vol. 02AI Agent Frameworks — OpenAI SDK, LangGraph, CrewAI, MastraPublished

Vol. 03Vector Databases — Pinecone, Weaviate, Milvus, QdrantPublished

Vol. 04AI Observability — LangSmith, Langfuse, Helicone, W&B WeavePublished

Vol. 05Inference Infrastructure — vLLM, SGLang, TensorRT-LLM, TGIPublished

Vol. 06Context Engineering — Mem0, Zep, LangMem, LettaThis Study

Vol. 07Memory SystemsPlanned

Vol. 08RAG ArchitecturesPlanned