LangChain Chatbot Memory in Python — With Examples

Your LangChain chatbot answers questions perfectly — until the user says "wait, go back to what you said earlier." The bot draws a blank. Every chain invocation starts from scratch, and without explicit memory management, even the most sophisticated prompt template produces a bot with amnesia.

This tutorial covers three distinct memory strategies — buffer, window, and summary — and exactly when each one fits. You will also learn the modern RunnableWithMessageHistory pattern that replaced the deprecated ConversationChain.

Every LLM API call is stateless. You send a list of messages, the model generates a response, and then it forgets everything. What feels like "memory" in ChatGPT is actually the application resending the entire conversation with every request.

The code below makes two separate LLM calls with no shared history. The model receives the second question in complete isolation — it has never seen the first message. It cannot answer "What's my name?" because that information was never included in the second request.

The second call returns something like "I don't have access to your personal information." The model genuinely does not know. This is the core problem LangChain's memory module solves: it manages conversation history automatically so your chatbot can reference earlier messages.

LangChain provides three core memory strategies. Each one answers the same question differently: what should we include in the message history?

Buffer memory is the natural starting point when prototyping. It stores every message — every user input and every AI response — and resends all of them on every call. Nothing is trimmed, nothing is summarized. I reach for this whenever I want something working fast.

The setup requires five pieces working together. A ChatPromptTemplate defines the system instructions and includes a MessagesPlaceholder where conversation history gets injected. A ChatOpenAI instance handles the LLM calls. A dictionary-based session_store maps session IDs to ChatMessageHistory objects. Finally, RunnableWithMessageHistory wires the chain to the store, automatically loading history before each call and saving new messages after.

The next block runs a three-turn conversation that tests whether memory is working. Turn 1 introduces a name ("Priya") and a topic ("decorators"). Turn 2 asks for an example without restating the topic — the bot must pull it from stored history. Turn 3 explicitly tests recall by asking the bot to repeat both facts. If all three turns produce correct responses, buffer memory is wired up correctly.

Turn 3 succeeds because all six messages (three user, three AI) get sent to the model every time. The bot answers "Your name is Priya and you're learning decorators" because both facts are literally in the history.

To verify what the memory stored, call get_session_history() with the session ID and access .messages. This returns a list of HumanMessage and AIMessage objects — one per message exchanged. After three turns, you should see six messages alternating between human and ai types. The loop below prints the type and first 80 characters of each.

Buffer memory works great until conversations grow past 20 turns. At that point, token costs climb and you risk hitting the context window ceiling. Window memory fixes this with a simple rule: keep only the last k exchange pairs and discard everything older.

The legacy ConversationBufferWindowMemory class demonstrates the concept clearly. Setting k=5 means "keep the last 5 exchange pairs" (10 messages total). The code below creates a window memory, feeds it three simulated turns via save_context, and checks the stored count. This class is being phased out in favor of trim_messages — I show the modern approach right after.

Once the conversation exceeds 5 turns, the oldest pair gets dropped. The model never sees turn 1 when you are on turn 7. The tradeoff is straightforward: you lose distant context but gain predictable token costs.

The modern approach replaces the legacy memory class with trim_messages from langchain_core.messages. It accepts a strategy parameter ("last" keeps the most recent messages), an include_system flag to protect the system prompt, and a start_on parameter to ensure trimmed history always begins with a human message. The token_counter=len setting counts messages, not actual tokens — for precise budgeting, you would pass a tiktoken-based counter instead.

One gotcha worth knowing: if the user refers to something from turn 1 and you are on turn 15 with k=5, the model will confidently hallucinate or say it does not know. That early message was trimmed. For some applications this is fine. For others, you need summary memory.

What if the conversation is 50 turns long and the user references something from turn 3? Window memory lost it. Buffer memory would work but costs a fortune in tokens. Summary memory offers a third option: it asks the LLM to maintain a running summary of the conversation instead of storing raw messages.

Instead of storing six messages, the memory holds a condensed summary like: "The user is Priya, a data engineer at Spotify who needs to build a real-time ETL pipeline using Kafka with Avro schema evolution for backward compatibility." Three turns compressed into one sentence.

The real advantage becomes obvious when you compare what the LLM receives at turn 20. The block below calculates approximate token counts using simple arithmetic: 50 tokens per message average, 20 turns total. Buffer sends all 40 messages (~2,000 tokens). Window with k=5 sends 10 messages (~500 tokens). Summary sends one compressed paragraph plus the latest exchange (~250 tokens). These are rough estimates, but the scaling difference is dramatic.

Which produces:

The gap widens as conversations grow. At turn 100, buffer memory sends roughly 10,000 tokens per call while summary memory stays around 300. For context on how this interacts with model limits, see our Context Windows and Token Budgets tutorial.

If you have read LangChain tutorials from 2023, you probably saw ConversationChain everywhere. That class is now deprecated. The replacement is RunnableWithMessageHistory, which is more flexible, composable, and fits naturally into LCEL pipelines.

We already used RunnableWithMessageHistory in the buffer memory section. Here I want to break down why it works the way it does and label all the moving parts. Five steps: (1) create the LLM, (2) build a prompt template with a MessagesPlaceholder for history, (3) compose them into an LCEL chain, (4) define a session store with a lookup function, and (5) wrap the chain with RunnableWithMessageHistory.

Three things to notice. First, input_messages_key tells the wrapper which part of your input dictionary is the user's message — this gets saved to history. Second, history_messages_key must match the variable_name in your MessagesPlaceholder. Third, the session ID comes from the config at invocation time, not at construction time.

A real chatbot serves many users at once. The session ID keeps their conversations separate — each call to bot.invoke() carries a config dictionary specifying which session to load. The store holds one ChatMessageHistory per session, so User 1's context never leaks into User 2's responses.

The store dictionary now has two entries: "user-001" with Priya's history and "user-002" with Carlos's history. In production, you would replace the dictionary with a persistent backend — covered in the Persistent Memory section below.

In practice, the most effective pattern combines summary and window memory. Keep the last k messages verbatim for detailed recent context, and prepend a summary of everything older for long-range awareness. The model gets both precision (exact recent messages) and breadth (compressed older context).

ConversationSummaryBufferMemory handles this automatically. It stores raw messages until the total token count exceeds a threshold you set with max_token_limit. Once the limit is breached, older messages get summarized into a single paragraph while recent messages stay intact. The code below creates one with a 300-token limit, adds two turns, and checks whether messages are still raw or already summarized.

With only two turns, the token count is below 300, so you see raw messages. Add 5–6 more turns and the older messages get compressed into a summary while recent ones stay verbatim.

Buffer, window, and summary cover the vast majority of chatbot use cases. But LangChain offers two specialized memory types that solve problems the core three cannot.

Entity memory tracks specific entities — people, projects, companies — mentioned in the conversation. Instead of storing raw messages or summaries, it maintains a dictionary of entity descriptions that gets updated as new information appears. This works well when a chatbot needs to remember facts about particular subjects: a sales assistant tracking multiple clients, or a project manager bot keeping tabs on several workstreams.

This memory type stores messages as vector embeddings and retrieves only the most semantically relevant ones for each new query. Instead of keeping the most recent messages (window) or a summary of all messages (summary), it finds messages most related to the current question. This is valuable in long-running sessions where the user jumps between unrelated topics. The code below creates a FAISS-backed vector memory using OpenAI embeddings, saves one context, and retrieves relevant history by semantic similarity.

Everything we have built so far uses a Python dictionary for session storage. Restart the server and all conversations vanish. For production chatbots, you need persistent storage.

The good news: the architecture stays the same. You only swap the get_session_history function. Redis is a popular in-memory data store used for caching and message brokering; here it persists conversation messages across server restarts. The code below imports RedisChatMessageHistory from langchain_community, creates a factory function that connects to a Redis URL, and passes it to RunnableWithMessageHistory. The chain, prompt, and invocation code remain identical — only the factory function changes.

LangChain supports several persistent backends. The table below lists the most common options:

LangChain's memory classes and RunnableWithMessageHistory are not the end of the story. The LangChain team now recommends LangGraph for new agentic applications. LangGraph takes a fundamentally different approach to memory: instead of wrapping chains with history, it builds conversation state directly into a graph of nodes.

In LangGraph, you define a graph with a MessagesState, compile it with a MemorySaver checkpointer, and pass a thread_id in the config. The framework automatically checkpoints state after each node execution. A minimal example looks like this:

For a simple chatbot, this is more code than RunnableWithMessageHistory. The payoff comes when you add tool calling, conditional routing, or multi-agent workflows. If your project is a straightforward Q&A bot, stick with the patterns taught earlier in this tutorial.

Time to put everything together. The customer support bot below uses trim_messages for window-style memory, handles multiple sessions, and includes a system prompt tailored for support interactions.

The first block sets up the LLM, a system prompt with support-specific rules, the prompt template, and a trimmer keeping the last 20 messages. These four components get composed into a single LCEL chain via the pipe operator.

The second block adds session management and runs a four-turn support conversation. Each turn builds on previous context — by turn 4, the bot knows the customer's order number, shipping tier, and original complaint without the customer repeating anything.

Without memory, each turn starts from zero and the customer repeats their order number and shipping details every time. Memory transforms a frustrating interaction into a natural conversation.

These three bugs surface over and over when wiring LangChain chatbots with memory. I check for them first whenever a bot acts like it has amnesia.

RunnableWithMessageHistory requires a session ID to know which conversation to load. Without the config, you get a ValueError about missing configurable fields.

This is the sneakiest bug because it raises no error at all. The history placeholder receives an empty list, and the bot behaves as if it has no memory. Always verify key names match before debugging anything else.

If you see from langchain.chains import ConversationChain in a tutorial, that tutorial is outdated. ConversationChain was deprecated in LangChain 0.2.7. The modern replacement is the RunnableWithMessageHistory pattern shown throughout this tutorial.

Yes. RunnableWithMessageHistory works with both .invoke() and .stream(). The wrapper saves messages to history after the stream completes. For more on streaming architecture, see our Streaming AI API Backend tutorial.

Call .clear() on the ChatMessageHistory object for that session:

With buffer memory, you get an API error when the total tokens (system prompt + history + new message) exceed the model's limit. GPT-4o-mini supports 128K tokens, so this is rare for text-only conversations. For models with smaller windows (8K–32K), use window memory or summary buffer memory. See our Context Windows and Token Budgets tutorial for details.

LangChain messages have an additional_kwargs field for arbitrary metadata. You can add timestamps, user IDs, or any other data without affecting how the LLM processes the message:

Yes. Replace .invoke() with await bot.ainvoke() and .stream() with async for chunk in bot.astream(). The history loading and saving happens asynchronously, which matters for high-concurrency applications: