How to Fix LangChain Agent Memory Loss Across Long Conversations

If a LangChain agent forgets details during a long conversation, fix the architecture before increasing the model context window. In current LangChain v1-style agents, conversation continuity is built from two separate layers: a checkpointer for short-term, thread-scoped state and a store for long-term information that must survive across threads. Long conversations then need a third concern: context management, usually trimming or summarizing older messages before they overwhelm the model.

This guide follows LangChain's official documentation as checked on September 11, 2026. The current docs recommend langchain.agents.create_agent for new agents and describe LangGraph persistence as the underlying memory system. Older examples based on ConversationChain, ConversationBufferMemory, or initialize_agent may still appear in legacy material, but LangChain's v1 migration guide moved legacy chains and other deprecated functionality to langchain-classic. See the official LangChain v1 migration guide.

What “Memory Loss” Actually Means in LangChain

Before changing code, separate three problems that often look identical from the user's point of view.

LangChain's short-term memory documentation defines short-term memory as state within a single thread. Its long-term memory documentation defines long-term memory as information that persists across different conversations and sessions.

What You Need Before You Start

You need a current LangChain/LangGraph application, a model integration, and a place to persist state. For a local experiment, InMemorySaver is sufficient. For production, use a database-backed checkpointer. LangChain's official docs show PostgreSQL through the separate langgraph-checkpoint-postgres package.

Keep four identifiers clear:

• Conversation or chat ID: the identifier your application exposes to users.
• thread_id: the LangGraph persistence key used to resume one thread's state.
• User ID: the durable identity used to namespace long-term memories.
• Memory key: the key for one durable item inside a store namespace.

They should not automatically be the same value. One user can have many threads, and one thread can contain many facts.

Step 1: Reproduce the Failure With a Two-Request Test

Start with the smallest possible test. Ask the agent to remember a unique detail, then invoke it again and ask for that detail. Do not test memory with a single invoke() call because the model can see everything in that one request even when persistence is broken.

config = {"configurable": {"thread_id": "debug-thread-001"}}

agent.invoke(
    {"messages": [{"role": "user", "content": "Remember that my project codename is Juniper."}]},
    config,
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What is my project codename?"}]},
    config,
)

If the second request forgets “Juniper,” inspect checkpointer configuration and the actual thread_id before changing prompts.

Step 2: Add a Checkpointer for Same-Thread Memory

A checkpointer persists snapshots of the agent's graph state. LangGraph uses it for short-term memory, interruption recovery, human-in-the-loop flows, and fault tolerance. The current persistence guide describes checkpointers as thread-scoped and says the application accesses the state by passing a thread_id. See the official LangGraph persistence guide.

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
)

config = {"configurable": {"thread_id": "customer-42:case-7"}}

InMemorySaver is excellent for confirming that your thread wiring works, but it stores checkpoints in RAM. LangGraph explicitly warns that MemorySaver/InMemorySaver do not persist across process restarts.

Step 3: Keep the Same thread_id for the Same Conversation

The most common application-level bug is creating a new thread_id on every HTTP request. The database may be working perfectly while every request starts a different LangGraph thread.

For example, suppose your front end has chat ID chat_8bf4. Map that value deterministically to the LangGraph thread and reuse it for every turn in that chat. A new chat should receive a new thread ID.

Do not use one permanent thread_id for all chats belonging to the same user. That merges unrelated conversations into one state stream. If you use PostgreSQL, LangGraph's current troubleshooting guidance also says thread_id should stay under 255 characters; a UUID or deterministic hash is safer than a huge serialized object.

Step 4: Replace In-Memory Persistence Before Production

Once the two-request test passes, test a process restart. Save a fact, stop the application, start it again, then ask for the fact with the same thread ID. If you still use InMemorySaver, forgetting is expected behavior.

The official short-term memory docs show a PostgreSQL-backed production setup using PostgresSaver:

from langchain.agents import create_agent
from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://user:password@db-host/app"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()
    agent = create_agent(
        model="your-provider:your-model",
        tools=[],
        checkpointer=checkpointer,
    )

For the package setup currently documented by LangChain, see Short-term memory. Do not put real database credentials directly in source code; use your normal secret-management system.

Step 5: Manage Long Histories Instead of Sending Everything Forever

A context window is the amount of input and output context a model can handle in one model call. Checkpointing can preserve a very long conversation in storage, but that does not mean every historical message should be sent back to the model forever.

LangChain's short-term memory guide says long histories can exceed the model context window and that even models capable of accepting the full history can be distracted by stale or off-topic content, with higher latency and cost. The documented strategies are trimming, deleting, summarizing, or applying a custom policy.

Use summarization when old details still matter

SummarizationMiddleware is the current built-in option for replacing older history with a compact summary while retaining recent messages. Its trigger can be based on token count, message count, or a fraction of the model context.

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
    middleware=[
        SummarizationMiddleware(
            model="your-provider:summary-model",
            trigger=("fraction", 0.8),
            keep=("fraction", 0.3),
        )
    ],
)

The numbers above are an example policy, not universal settings. Choose thresholds after measuring your own prompts, tool outputs, model context limits, latency, and summary quality. See LangChain's built-in middleware documentation for the currently supported trigger and keep options.

Do not trim tool messages blindly

If you implement custom deletion or trimming, preserve a valid message sequence. LangChain warns that many providers require an assistant message containing tool calls to be followed by the corresponding tool-result messages. Removing one half of that pair can create provider errors or confusing model behavior.

Step 6: Move Durable Facts Into a Long-Term Store

A store is LangGraph's persistence layer for application-defined data outside one thread's graph state. Current LangChain docs use stores for information that should be available across conversations, such as user preferences, facts, or shared application knowledge.

Long-term store items are JSON documents organized by a namespace and a key. A practical namespace often contains a user or organization identifier:

namespace = ("users", user_id, "preferences")
store.put(
    namespace,
    "response_style",
    {"value": "concise", "source": "explicit_user_request"},
)

This is different from saving the entire transcript. Store the information your product intentionally treats as durable. If a fact is private or regulated, apply your normal retention, authorization, encryption, and deletion policies rather than assuming “agent memory” is exempt from them.

Use a database-backed store in production

The official long-term memory guide shows both InMemoryStore and PostgresStore, and explicitly notes that the in-memory implementation should be replaced by a database-backed store for production. It also lists store integrations beyond PostgreSQL. Use the backend that fits your deployment and operational requirements rather than selecting a vector database merely because the word “memory” is involved.

Add semantic search only when you need fuzzy recall

LangGraph stores can be configured with an index so store.search() can retrieve items by semantic similarity. That is useful when you have many memories and do not know the exact key. For a small set of structured preferences, direct namespace/key lookup is often simpler and more deterministic.

Step 7: Make Memory Read and Write Paths Explicit

Persisting a long-term item does not guarantee that the agent will use it. The application still needs a retrieval path. Current LangChain agents let tools access the supplied store through ToolRuntime.

from dataclasses import dataclass
from langchain.tools import tool, ToolRuntime

@dataclass
class Context:
    user_id: str

@tool
def get_response_style(runtime: ToolRuntime[Context]) -> str:
    store = runtime.store
    if store is None:
        return "No memory store configured"

    namespace = ("users", runtime.context.user_id, "preferences")
    item = store.get(namespace, "response_style")
    return item.value["value"] if item else "default"

You can also build dynamic prompts or middleware that reads state and durable memory before a model call. The important design rule is that the retrieval path should be observable and testable. “The information exists somewhere in the database” is not enough.

Step 8: Test the Four Memory Boundaries Separately

A reliable memory test suite should cover more than “the model remembered my name once.” Use at least these four cases:

Then add a long-conversation test that exceeds your summarization threshold. Assert that important durable facts survive, recent tool-call sequences remain valid, and the prompt size stays within your target budget.

A Minimal Production Architecture

For many agent applications, a robust design looks like this:

1. The API receives user_id, conversation_id, and the new user message.
2. The application maps conversation_id to a stable LangGraph thread_id.
3. A persistent checkpointer restores the thread state.
4. A long-term store retrieves only durable user or application facts needed for the request.
5. Summarization or trimming keeps the model-facing history within a measured context budget.
6. The agent runs tools and the model.
7. The checkpointer commits the updated thread state.
8. Only approved facts are written to the long-term store.

If you deploy through LangGraph Agent Server, the current persistence guide says the server handles persistence infrastructure automatically, so do not duplicate that layer without checking the deployment model.

Common Mistakes That Make Memory Look Broken

Generating a new thread_id for every request

This creates a new conversation state every turn. Log the thread ID next to your application chat ID and verify reuse.

Using InMemorySaver in a multi-worker or restartable service

RAM-local state disappears with the process and may not be shared across workers. Use a persistent backend for production continuity.

Assuming a checkpointer solves the context-window problem

A checkpointer preserves state; it does not guarantee that an ever-growing transcript is useful to the model. Add an explicit context-management policy.

Putting every historical fact into the prompt

More context is not automatically better context. Retrieve information that is relevant to the current turn and preserve recent conversational continuity separately.

Treating summaries as a perfect database

Summaries are compressed model-generated representations. If a fact must be exact—an account identifier, contractual constraint, user-approved preference, or workflow state—store it as structured data rather than hoping it survives repeated summarization.

Mixing short-term and long-term scopes

Thread history should not silently become a global user profile. Conversely, a user preference intended to follow the user across chats should not live only in one thread.

Copying pre-v1 memory tutorials without checking imports

If an example starts from legacy chains or old memory classes, compare it with the current v1 migration and memory docs before using it in a new application.

Debugging Checklist

• Confirm the agent was created with a checkpointer.
• Log and compare thread_id across consecutive requests.
• Inspect the stored thread state before blaming the model.
• Restart the process and repeat the same-thread test.
• Replace InMemorySaver with a persistent checkpointer for production.
• Measure message/token growth over long chats.
• Enable summarization or trimming before the history becomes excessive.
• Keep tool-call/result sequences valid when removing messages.
• Move cross-thread facts into a namespaced long-term store.
• Test a new thread for the same user to verify intentional long-term recall.
• Test a different user to verify memory isolation.
• Trace which memory items were retrieved for each answer.

Bottom Line

LangChain agent memory loss is rarely solved by one larger context window. First make thread state persistent with a checkpointer and a stable thread_id. Then control long histories with trimming or SummarizationMiddleware. Finally, place facts that must survive across conversations in a namespaced long-term store and retrieve them deliberately.

That separation gives you something much more useful than “memory”: a system you can restart, scale, test, audit, and reason about when a user asks, “Why did the agent forget?”