Long-Term Memory for AI Agents: Patterns and Frameworks (Mem0, Zep, LangMem)

Ask a large language model the same question in two separate sessions and it answers like it has never met you. That is not a bug. It is the default. A model only knows what fits inside its context window for the current turn, and when the session ends, that context is gone. For a chatbot demo this is fine. For an agent that is supposed to act like a coworker, remember your preferences, and pick up where it left off last week, it is a dealbreaker.

Long-term memory for AI agents is the layer that fixes this. It is the set of patterns and infrastructure that let an agent store facts, experiences, and learned behavior outside the context window, then pull the right pieces back in when they matter. Teams sometimes call this persistent AI memory, and getting AI long term memory right is what separates a slick demo from a product people actually rely on. This guide walks through how long term memory AI systems actually work, the core patterns you need regardless of stack, and how the leading frameworks (LangGraph persistence, LangMem, Mem0, and Zep) implement them. If you want the conceptual foundation first, our AI agent memory developer's guide covers the ground-level model before you commit to a framework.

Short-term memory versus long-term memory

The single most useful distinction to internalize is the split between short-term and long-term memory, because most framework confusion comes from mixing them up.

Short-term memory is thread-scoped. It is the running conversation, the working state of the current task, the scratchpad the agent uses within one session. In practice this lives in the context window and in whatever state object your framework passes between steps. It is fast, it is cheap to access, and it disappears (or should) when the task ends.

Long-term memory is cross-session. It survives across different conversations, different tasks, and different days. When a user returns next week in a brand new session, their preferences, constraints, and the facts they told you should still be available. That persistence across separate sessions is the entire point, and it is the thing a raw context window cannot give you no matter how large it gets. Even a two-million-token window does not help if you never wrote anything down before the session closed.

A helpful mental model: short-term memory is what the agent is thinking about right now, and long-term memory is what the agent knows in general. You need both, and you need a clean boundary between them.

The three types of long-term memory

Borrowing from cognitive science, most modern memory frameworks organize long-term memory into three types. Getting these categories right shapes how you store and retrieve.

Semantic memory holds facts. "The user prefers dark mode." "The company's fiscal year starts in April." "This customer is on the enterprise plan." Semantic memory is the knowledge base of stable truths the agent can rely on.

Episodic memory holds experiences. It records what happened: past interactions, the sequence of steps taken to solve a problem, the outcome of a previous run. Episodic memory is what lets an agent say "last time you asked for X, we did Y and it worked."

Procedural memory holds learned behavior. It is the accumulated how-to: the refined system prompt, the tool-use patterns that succeeded, the workflow shortcuts an agent picks up over time. If episodic memory is the diary, procedural memory is the muscle memory. Our deep dive on agent workflow memory shows how reusing successful step sequences turns episodic records into procedural skill.

Not every application needs all three. A support agent leans heavily on semantic and episodic memory. A coding agent that improves its own strategies over time cares a lot about procedural memory. Decide which types matter for your use case before you pick infrastructure, because the choice drives everything downstream.

The core patterns every memory system implements

Underneath the framework branding, long-term memory comes down to four operations. Learn these and you can read any memory library's source and know what it is doing.

Writing memories: extraction

You rarely want to store raw conversation transcripts. They are noisy, they balloon in size, and they make retrieval worse. Instead, good systems run an extraction step: an LLM reads the new conversation and pulls out the salient facts worth keeping. "My name is Priya and I manage the payments team" becomes a compact structured memory rather than a wall of chat logs. This extraction is where a lot of quality lives, because what you fail to extract, you can never recall.

Retrieving memories

At the start of a turn, the agent needs to fetch the memories relevant to what the user just said. The dominant approach is semantic search over embeddings: embed the query, find the nearest stored memories by vector similarity, and inject them into the prompt. More advanced systems combine vector search with keyword filters and graph traversal so that "who did I meet at the conference" can follow relationship edges rather than hoping for a lucky cosine match.

Updating and forgetting

Memory that only grows is memory that rots. When a user says "actually, I switched teams," the old fact is now wrong. Mature systems do not just append; they reconcile. Mem0, for example, frames every incoming fact as one of four actions against existing memory: ADD, UPDATE, DELETE, or NOOP. The update path is what keeps stored knowledge consistent instead of accumulating contradictions. Forgetting, whether through explicit deletion or decay, is a feature, not an oversight.

Consolidation

Over many sessions, raw memories pile up. Consolidation compresses and organizes them: merging duplicate facts, summarizing clusters of episodic records, and promoting stable patterns into higher-level knowledge. This is the background housekeeping that keeps retrieval fast and relevant as the store grows into the thousands of entries.

Storage backends: where the memories actually live

The patterns above sit on top of a storage layer, and the backend choice has real consequences.

Vector databases store embeddings and power semantic similarity search. They are the workhorse of memory retrieval and handle "find things like this" queries well, but they struggle with precise relationships and time.

Graph stores model entities and the relationships between them. They shine when memory needs to answer relational and temporal questions: who is connected to whom, what happened before what. The cost is added complexity.

Key-value stores handle direct lookups: fetch this user's preferences by ID. Simple, fast, and unglamorous.

The trend in production systems is hybrid storage that combines all three, using vectors for fuzzy recall, a graph for relationships, and key-value for exact fetches. That hybrid approach is exactly what the strongest frameworks now ship by default.

Framework 1: LangGraph persistence

If you build on LangGraph, memory is not a bolt-on. It is baked into the persistence layer, and the framework draws the short-term versus long-term line cleanly for you.

Checkpointers provide short-term, thread-scoped memory. A checkpointer writes the graph's state to a backend after every node execution, keyed by a thread_id. That gives you conversation continuity within a session, plus human-in-the-loop pauses, time travel through past states, and crash recovery. PostgresSaver is the common production choice because it survives restarts and scales horizontally.

Stores provide long-term, cross-thread memory. A store persists application-defined data outside the graph state, namespaced so it is not tied to any single thread_id. This is where user preferences, extracted facts, and shared knowledge go, so they are available when the same user starts a fresh conversation next week.

Here is the shape of it in practice:

from langgraph.store.memory import InMemoryStore
from langgraph.checkpoint.postgres import PostgresSaver

# Short-term: thread-scoped state, one conversation
checkpointer = PostgresSaver.from_conn_string("postgresql://...")

# Long-term: cross-thread facts, survives new sessions
store = InMemoryStore(index={"embed": embeddings, "dims": 1536})

# Write a memory under a (user_id, namespace) key
store.put(("user-123", "preferences"), "theme", {"value": "dark mode"})

# Later, in a different thread, retrieve by semantic search
hits = store.search(("user-123", "preferences"), query="ui settings")

The mental model to keep: checkpointer for "this conversation," store for "this user, forever." Swap InMemoryStore for a Postgres-backed store in production.

Framework 2: LangMem

LangMem is the memory layer designed to sit natively on top of LangGraph. If your stack is already LangGraph, it slots in without a fight and gives you higher-level memory management than raw stores.

LangMem supports all three memory types out of the box: semantic, episodic, and procedural. It handles both fact extraction (pulling structured memories from conversation) and behavior-level memory (refining how the agent acts over time). That makes it a natural fit for agents meant to improve with use rather than just remember facts.

The tradeoff shows up in latency. Public benchmark numbers on the LOCOMO long-conversation dataset put LangMem around 58 percent overall accuracy, with a p95 search latency near 60 seconds. That tail latency makes it a poor fit for snappy, interactive chat, though it is more tolerable for background or asynchronous agents. As always, benchmark against your own traffic before committing.

Framework 3: Mem0

Mem0 is a memory layer built specifically to give agents scalable long-term memory without dragging the entire history into context. Its architecture centers on two stages: extraction and update. An LLM extracts key facts from each new exchange, then the update stage decides, per fact, whether to ADD, UPDATE, DELETE, or NOOP against what is already stored. That reconciliation loop is Mem0's defining feature, and it is what keeps the store internally consistent over long relationships.

Mem0 organizes memory into three scopes (user, session, and agent) and backs them with a hybrid store that combines vector, graph, and key-value representations. The headline efficiency claim from the Mem0 paper is stark: where a full-graph competitor's memory footprint can exceed 600,000 tokens per conversation, Mem0's extraction-first design keeps a comparable conversation near 1,764 tokens. Fewer tokens injected means lower cost and lower latency per turn, which is the whole reason to extract rather than dump.

Mem0 is a strong default when you want production-grade long term memory for AI agents, you care about token cost, and you are comfortable letting an LLM decide what is worth remembering.

Framework 4: Zep

Zep takes a different bet: it treats memory as a temporal knowledge graph, powered by its Graphiti engine. Rather than a flat pile of facts, Zep builds a three-tiered graph of episodic data, semantic entities, and higher-level communities, and it uses bi-temporal modeling to track both when something happened and when the system learned about it.

That temporal structure is Zep's real advantage. It can answer questions that depend on ordering and change over time, like "what was the user's shipping address before they moved," which flat vector stores handle poorly. Retrieval blends hybrid search with multi-strategy reranking to surface the most relevant subgraph.

The cost is footprint. In the Mem0 team's comparison, Zep's richer graph representation consumed far more tokens per conversation, and immediate post-ingestion retrieval was not always reliable in their tests. Zep is the pick when relationships and time are first-class to your domain and you are willing to pay for that expressiveness. For agents where memory is mostly a flat set of user facts, it can be more machinery than you need.

Choosing a framework

There is no universally correct answer, only a fit for your constraints. A rough decision guide: start with LangGraph persistence if you are already on LangGraph and your needs are straightforward, add LangMem when you want managed memory types on top, reach for Mem0 when token cost and scalability dominate, and choose Zep when your domain is genuinely relational and temporal. Here is the tradeoff at a glance:

• LangGraph persistence: checkpointers plus stores. Strength is a clean short versus long split that is native to LangGraph. The tradeoff is that you assemble the higher-level memory logic yourself.
• LangMem: semantic, episodic, and procedural memory. Strength is managed memory types and behavior learning. The tradeoff is high p95 retrieval latency.
• Mem0: an extraction plus update pipeline over a hybrid store. Strength is a low token footprint and consistent updates. The tradeoff is that quality relies on LLM extraction.
• Zep: a temporal knowledge graph. Strength is relationships and time with bi-temporal recall. The tradeoff is a larger footprint and more complexity.

A note on evaluation

Whatever you pick, do not trust vendor benchmarks blindly. Long-term memory quality is notoriously workload-dependent, and datasets like LOCOMO measure long-conversation recall in ways that may not match your traffic. Measure retrieval precision, end-to-end latency at p95, and token cost per turn on your own conversations before you standardize. The same rigor you would apply to any AI system belongs here too.

Bringing it together

Long-term memory is what turns a stateless model into an agent that feels like it knows you. The mechanics are consistent no matter the logo on the library: extract the facts worth keeping, retrieve the right ones at the right time, reconcile updates so the store stays true, and consolidate as it grows. The frameworks differ mostly in how much of that they manage for you and what they optimize for, whether that is token cost, temporal reasoning, or native LangGraph integration.

If you are building agents and want the full picture of how memory fits alongside planning, tools, and orchestration, start with the AI agent memory developer's guide and browse more engineering deep dives on the Levelop blog. And if you are hiring or preparing for agent-focused roles, Levelop has practice built around exactly these systems.

Where to go next

These ideas connect across the AI agent memory cluster. Start with the AI agent memory developer's guide, see how agents remember with agentic memory across sessions, and learn how they reuse past steps with agent workflow memory. For more, visit the Levelop blog or the Levelop home page.