LangChain Agent Memory Across Sessions: A LangGraph Guide

LangChain agent memory across sessions, explained

LangChain agent memory across sessions is the difference between an agent that forgets you the moment a conversation ends and one that remembers your name, your preferences, and what it did for you last Tuesday. By default, an agent's memory lives in the request. When the process ends or the conversation resets, it is gone. Making memory survive across sessions means deciding what to keep, where to store it, and how to bring it back at the right moment. LangGraph, the stateful sibling of LangChain, gives you concrete tools for both the within-a-session kind and the across-sessions kind.

The distinction that trips people up: there are two very different things people call memory, and they solve different problems. Getting them mixed up is the source of most confusion. This builds directly on how AI agents work, so if the think-act-observe loop is not familiar yet, start there.

Short-term vs long-term memory

Short-term memory is the running history of the current task: the messages, tool calls, and observations that have happened since this session started. It fits in the model's context window, or it does until the task gets long, at which point you have to summarize or trim. Short-term memory is about coherence within one job.

Long-term memory is what persists after the session ends: facts about the user, past decisions, learned preferences, results worth keeping. It lives in a database, not the context window, and you retrieve the relevant pieces when a new session needs them. Long-term memory is about continuity across jobs.

Here is the split in a table:

You need both. Short-term keeps a single task coherent. Long-term is what makes the agent feel like it knows you.

Short-term memory in LangGraph: threads and checkpoints

LangGraph handles short-term memory with a checkpointer. Each conversation gets a thread ID, and after every step LangGraph saves the state under that thread. Resume the same thread and the agent picks up exactly where it left off, which is what makes LangChain agent memory across sessions possible even within a single ongoing conversation that spans process restarts.

from langgraph.checkpoint.postgres import PostgresSaver

checkpointer = PostgresSaver.from_conn_string(DB_URL)
agent = graph.compile(checkpointer=checkpointer)

# Every call on the same thread_id resumes the saved state.
config = {"configurable": {"thread_id": "user-42-chat"}}
agent.invoke({"messages": [user_msg]}, config)

from langgraph.checkpoint.postgres import PostgresSaver

checkpointer = PostgresSaver.from_conn_string(DB_URL)
agent = graph.compile(checkpointer=checkpointer)

# Every call on the same thread_id resumes the saved state.
config = {"configurable": {"thread_id": "user-42-chat"}}
agent.invoke({"messages": [user_msg]}, config)

Swap the in-memory checkpointer for a Postgres one and the thread survives a crash or a redeploy. The agent that was halfway through a task before the process died resumes from its last checkpoint. This is the first real step past "forgets everything on restart."

Long-term memory: the store and retrieval

Threads keep one conversation alive. They do not help a brand-new session recall a fact from three weeks ago. For that you need a separate long-term store, keyed by user rather than by thread, that you write facts into and read facts out of.

LangGraph exposes a store interface for exactly this. The pattern is: after a session, extract the durable facts and write them; at the start of a new session, retrieve the relevant ones and inject them into the prompt.

# Write a durable fact after a session.
store.put(("user-42", "prefs"), "timezone", {"value": "Europe/Berlin"})

# Retrieve it in a future, unrelated session.
tz = store.get(("user-42", "prefs"), "timezone")

# Write a durable fact after a session.
store.put(("user-42", "prefs"), "timezone", {"value": "Europe/Berlin"})

# Retrieve it in a future, unrelated session.
tz = store.get(("user-42", "prefs"), "timezone")

For richer recall, back the store with embeddings so you can retrieve by meaning, not just exact key. "What did we decide about the pricing page?" pulls the relevant past note even if the words do not match exactly. That is retrieval-augmented memory, and it is how an agent recalls the right thing at the right time without stuffing its entire history into every prompt.

What to actually store, and what to drop

The hard part of long-term memory is not the plumbing. It is judgment about what deserves to persist. Store too much and retrieval gets noisy and expensive. Store too little and the agent feels forgetful.

A workable policy:

• Keep stable facts. Preferences, names, standing decisions, account settings. Things that stay true.

• Keep outcomes. What the agent did and whether it worked, so it can avoid repeating a failed approach.

• Drop the transcript. You rarely need the full text of an old conversation. A short summary of what was decided is enough and far cheaper to retrieve.

• Expire the volatile. Anything time-sensitive should carry an expiry so stale facts do not resurface as if they were still true.

Deciding what to persist is itself a small agentic judgment, and you can even have a step in the loop whose only job is "extract the durable facts from this session."

The persistence tradeoff nobody mentions

Every design above assumes one thing: a database that is actually there when the agent restarts. This is where memory quietly becomes an infrastructure problem. Your checkpointer needs a Postgres it can reach. Your long-term store needs durable storage that survives a redeploy. If the agent runs on ephemeral compute that wipes its disk on every restart, all of this falls apart, and the agent that "remembers across sessions" forgets every time it is rescheduled.

So the memory question and the hosting question are the same question. An agent needs a persistent place to write, and a stable connection to its stores. Sokko gives each agent a persistent workspace that survives restarts and keeps each agent's database credentials in secure storage, isolated from the others, so the checkpointer and the long-term store both have somewhere durable to live. The memory design is yours; the durable substrate underneath it is the part you should not have to rebuild. Whether you reach for this or a plain workflow tool depends on the same factors we weigh in n8n vs LangChain for AI agents.

A worked example: the assistant that remembers

Make it concrete. You build a personal assistant agent. On Monday a user says "I prefer meetings in the afternoon, and I am in Berlin." Without long-term memory, the agent forgets both by Tuesday. With it, here is the flow.

At the end of Monday's session, an extraction step reads the conversation and writes two durable facts to the store under that user: a timezone of Europe/Berlin and a meeting preference of afternoons. Nothing else from the chat is kept, because the rest was one-off.

On Thursday the user opens a fresh session and says "book me a call with Sam next week." The agent starts by retrieving that user's stored facts, sees the timezone and the afternoon preference, and proposes Thursday at 2pm Berlin time without asking. The user never repeats themselves. That single experience, the agent quietly remembering, is what separates a tool that feels smart from one that feels like a stranger every time.

Common memory mistakes

Most memory problems come from a handful of predictable errors.

• Storing everything. Dumping full transcripts into long-term memory makes retrieval slow, noisy, and expensive. Store extracted facts, not raw chat.

• Never expiring anything. A fact that was true in March resurfaces in September as if still current. Time-sensitive memories need an expiry.

• Retrieving too much. Injecting fifty past facts into every prompt buries the relevant one and burns context. Retrieve the few that match the current task.

• Trusting memory blindly. A stored fact can be stale or wrong. For anything that matters, confirm rather than assuming the memory is still accurate.

• Ignoring privacy. Long-term memory about users is personal data. It needs the same deletion, export, and consent handling as any other stored user record.

Each mistake is easy to make and easy to avoid once you know to look for it.

Choosing a backend for memory

The store behind your memory is a real decision with tradeoffs.

• Postgres. The safe default. Durable, transactional, and it doubles as your checkpointer. Add a vector extension and it handles semantic retrieval too, so you can run one database instead of two.

• A dedicated vector database. Worth it when semantic recall is central and you have a lot of it. More moving parts, another service to operate.

• A key-value store. Fine for simple, exact-key facts like preferences. Fast and cheap, but no semantic search, so it does not answer fuzzy recall questions.

For most agents, Postgres with a vector extension covers both the checkpointer and the long-term store, which keeps your operational surface small. Reach for a dedicated vector database only when retrieval quality at scale becomes the bottleneck. Whatever you pick, the non-negotiable is durability: the store has to survive a restart, or your across-sessions memory quietly resets on every deploy. And because that memory is personal data, design the store with a user key from the start so a "forget me" request is one clean delete, not an archaeology project across scattered tables.

The takeaway

LangChain agent memory across sessions comes down to two mechanisms working together: a checkpointer that keeps a single task alive across restarts, and a long-term store, keyed by user and ideally searched by meaning, that carries durable facts between sessions. Short-term keeps a task coherent. Long-term makes the agent feel like it knows you. Both assume durable storage underneath, so treat the database as part of the design, not an afterthought. The LangGraph documentation has the current API details for both the checkpointer and the store.