Does LangChain Remember Between Runs? What Actually Persists

The short answer: No, not by default. A LangChain agent is stateless between runs: every invocation starts with a blank thread unless you attach a checkpointer or store. In-memory checkpointers like MemorySaver keep one conversation coherent while the process is alive and lose everything when it restarts. File or database checkpointers like SqliteSaver or PostgresSaver keep thread history across restarts, but only inside the thread that created it. If you need knowledge shared across threads, agents, or tools, that is a separate layer you wire in yourself.

Why does a LangChain agent forget between runs?

The LLM underneath is stateless: each call only knows what you send in that request. LangChain does not change this. When you build an agent with create_react_agent, the agent holds no durable state of its own. The "memory" people talk about is really two separate mechanisms that you opt into:

1. Checkpointer — saves the thread's message history step by step, so a conversation can resume.
2. Store — saves long-term knowledge (facts, preferences, conventions) that any thread can look up.

Confusing the two is the most common mistake. A checkpointer answers "where did this thread leave off?" A store answers "what does the agent know?" Both can live on disk, but only the store crosses thread boundaries.

What are the options for LangChain memory, from simplest to production?

Level 1: MemorySaver (in-process only)

from langgraph.checkpoint.memory import MemorySaver

memory = MemorySaver()
agent = create_react_agent(llm, tools, checkpointer=memory)
config = {"configurable": {"thread_id": "support-1"}}

With the same thread_id, the agent carries the conversation forward turn after turn while the process runs. Restart the process and the memory is gone. This is fine for a demo or a CLI tool you run interactively, and wrong for anything scheduled or deployed.

Level 2: SqliteSaver (persists on one machine)

import sqlite3
from langgraph.checkpoint.sqlite import SqliteSaver

conn = sqlite3.connect("checkpoints.db", check_same_thread=False)
memory = SqliteSaver(conn)
agent = create_react_agent(llm, tools, checkpointer=memory)

Tell the agent your name, stop the process, start it again with the same thread_id, and it still knows you. The history now lives in a local file. This is the right answer for a single-machine deployment, and the limit shows up the moment you move to containers or a second machine: the SQLite file lives wherever the process runs.

Level 3: Postgres checkpointer plus a store (cross-thread knowledge)

Checkpointers preserve thread history. For knowledge that should reach across threads, LangChain's store layer (for example PostgresStore with an embeddings function) saves facts that any thread can retrieve by semantic search. A durable per-user preference goes in the store; the conversation it came from stays in the checkpointer.

Note the honest accounting: at this level you are operating infrastructure. You provision the database, run the migrations, choose and pay for the embedding model, design the namespace scheme (per user, per workspace, per agent), and decide what expires. Nothing in LangChain does that for you.

Level 4: A shared memory layer outside the agent

This is the option for when the agent is not the only thing that needs to remember. Vilix AI is a cloud-hosted shared memory and work-state layer: your LangChain agent connects as a headless agent with an API key as the Bearer header to https://api.vilix.ai/mcp, save_turn stores the full exchanges (not just distilled facts), and get_context loads the relevant context into later runs with semantic plus keyword retrieval. Because it is hosted, you manage no infrastructure, and the same memory follows into Claude Code, Codex, Cursor, and your other tools, so the deployed agent and the dev laptop stop being strangers.

What should you actually choose?

• Demo or interactive CLI: MemorySaver, one process, one machine. Free and simple.
• Single-machine production: SqliteSaver plus a small discipline of stable thread_id values.
• Multi-instance or team deployment: Postgres checkpointer plus a store, with namespaces per user or workspace.
• Memory that spans the agent, your IDE, and your other AI tools: a shared hosted memory layer, so you are not re-implementing the store per platform.

Frequently asked questions

Does LangChain remember between runs by default?

No. Agents built with create_react_agent are stateless between runs. Memory appears only when you attach a checkpointer (for thread history) or a store (for long-term knowledge).

What is the difference between MemorySaver and SqliteSaver?

MemorySaver keeps thread state in RAM and loses it when the process restarts. SqliteSaver writes the same thread state to a local SQLite file, so it survives restarts on the same machine.

Can a LangChain agent share memory across different threads or agents?

Yes, through the store layer (for example PostgresStore), which saves long-term knowledge any thread can retrieve. Checkpointers only replay the history of the thread that created it.

Does Vilix AI work with LangChain agents?

Yes. A LangChain agent connects as a headless agent using an API key as the Bearer header to https://api.vilix.ai/mcp. save_turn stores the full exchanges and get_context loads relevant context into later runs, with the same memory shared across your other connected tools.