Langmem

Also known as: LangMem SDK, LangChain memory, langmem

Langmem
LangMem is a Python SDK from LangChain that adds long-term memory to AI agents by exposing memory operations as agent-callable tools and running a background manager that consolidates memories asynchronously, with native integration into LangGraph’s long-term memory store.

LangMem is a Python SDK from LangChain that adds long-term memory to AI agents through callable tools and a background manager that consolidates memories asynchronously across conversations.

What It Is

When AI agents forget everything between sessions, every conversation starts from zero. The user re-explains preferences, the agent re-asks for context, and the relationship feels mechanical. LangMem fixes this by giving agents long-term memory they can read from and write to across conversations — turning stateless chatbots into assistants that retain context the way a colleague would.

According to LangChain Blog, LangMem exposes memory as tools the agent can call directly during a conversation. Two main tools — one for storing memories, one for searching them — let the agent decide when something is worth remembering. This is the “hot path” approach: the agent reasons about memory the same way it reasons about any other action it can take, instead of memory being a hidden side effect of the runtime.

A second component runs in the background. According to LangChain Blog, the memory manager consolidates and updates stored memories asynchronously, so the agent does not pay the latency cost during user-facing turns. According to LangMem Docs, the core memory API is storage-agnostic, and the SDK integrates natively with LangGraph’s long-term memory store. That two-part design — synchronous tools for the agent, asynchronous manager for cleanup — is what distinguishes LangMem from a plain vector store with a “memory” label slapped on it.

How It’s Used in Practice

Most teams encounter LangMem when they already have a working LangGraph agent that keeps “forgetting” the user — a coding assistant that re-asks framework preferences every session, a support bot that loses context between tickets, a personal assistant that never internalizes a routine. They reach for LangMem to add a persistence layer without rewriting the agent loop from scratch.

The typical setup: import the memory tools, attach them to the agent, point the SDK at a storage backend (the LangGraph store, Postgres, or whatever the team already runs), and let the agent call the tools when context warrants it. The background manager runs separately, reconciling duplicates and contradictions while the user is between messages — so the agent stays responsive even as memory grows.

Pro Tip: Start with the hot-path tools only. Watch what the agent chooses to remember for a week before you turn on the background manager. You will catch noisy memory-write patterns early, when fixing them is just a prompt edit instead of a data cleanup.

When to Use / When Not

ScenarioUseAvoid
Building agents on LangGraph that need cross-session memory
Quick prototype with no LangChain dependency
You want explicit, agent-driven control over what gets remembered
You need a turnkey hosted memory service with SLAs and dashboards
Mixing hot-path memory writes with background consolidation
Strict enterprise audit and compliance requirements out of the box

Common Misconception

Myth: LangMem is a database — you install it and your agent magically gets memory. Reality: LangMem is an SDK that gives the agent tools to read and write memory. The agent still has to decide what is worth remembering. If the prompt does not encourage memory use, no memory gets created and the agent stays as forgetful as before.

One Sentence to Remember

LangMem turns memory into something an agent reasons about — a tool, not a side effect — which is why it works best when paired with a prompt that makes remembering an explicit part of the agent’s job.

FAQ

Q: Is LangMem a database? A: No. It is a Python SDK that gives agents tools for reading and writing memory. The actual storage lives in a backend you choose, such as LangGraph’s long-term memory store or a database you already run.

Q: Does LangMem only work with LangChain agents? A: According to LangMem Docs, the core memory API is storage-agnostic and integrates natively with LangGraph. Using it outside the LangChain ecosystem is possible, but most examples and integrations assume a LangGraph runtime.

Q: How is LangMem different from a vector store? A: A vector store retrieves similar text. LangMem orchestrates when to write, search, and consolidate memory through agent-callable tools and a background manager — closer to a memory framework than a storage layer.

Sources

Expert Takes

Memory in language models is not a property — it is an architecture choice. LangMem makes this explicit by separating two operations: synchronous memory access during reasoning, and asynchronous consolidation between turns. That split mirrors how cognitive systems handle working memory and long-term storage. The separation matters because conflating them creates the latency-versus-coherence tradeoff that quietly ruins most early memory implementations.

Treating memory as tools is a specification move, not an implementation detail. The agent’s prompt now has to describe when to remember and what counts as worth remembering. That contract is where most LangMem deployments succeed or fail. If your spec says “remember user preferences,” the agent will write noise. If it says “remember stable facts the user repeats across sessions,” you get signal.

Memory is the moat that turns an AI feature into a sticky product. LangMem ships with the only credibility that matters in this category — it is built by the team behind the framework most production agents already run on. For builders inside the LangChain ecosystem, that is the path of least resistance. For everyone else, it is at least the reference architecture worth studying before rolling your own.

Persistent memory creates persistent risk. Every fact LangMem stores about a user is a fact someone could subpoena, leak, or weaponize. The “remember the user” framing sounds friendly until you ask who has read access, who can delete, and who is liable when memory goes wrong. Convenience here demands a parallel investment in deletion, audit, and consent that few teams are budgeting yet.