What does RunnableWithMessageHistory fix that the old ConversationBufferMemory got wrong?

MCQ·Medium·4.0 · 0·~1 min·Asked atMicrosoft Cursor Perplexity

Attempt it

The old `ConversationBufferMemory` stored the conversation buffer as an attribute on the memory object. That object got attached to the chain. So the chain became stateful. It carried the conversation buffer of whoever last used it. For a single-user notebook this works. For a web server serving many users concurrently, it is a bug waiting to happen. Two requests on the same chain object can see each other's conversation history. The textbook fix was to instantiate a new memory and new chain per request, which broke the share the chain globally pattern and added per-request overhead. `RunnableWithMessageHistory` is the replacement. The Runnable itself stays stateless. At call time, the user passes a `session_id` in the config. A factory function, provided by the user, receives the session id and returns the message history store for that session (an in-process dict, a Redis key, a Postgres row, whatever). The Runnable reads the history before the LLM call, the model responds, the response is appended back to the same session's store. The correct answer names this structural fix. The other options are features (compression, encryption, windowing) that the old memory classes also supported in some form. Those were not the bug.

The motivation for `RunnableWithMessageHistory` was a statelessness gap in the old memory classes. `ConversationBufferMemory` (and its siblings `ConversationSummaryMemory`, `ConversationBufferWindowMemory`) all held the conversation buffer as an attribute on the memory object. The memory object got attached to a chain. The result was a chain that carried per-instance state, which made the chain unsafe to share across concurrent users. The symptoms were predictable. Naive deployments would build one chain at startup and serve all users from it. And discover cross-session bleed where one user saw another's chat history. The workaround was to instantiate a fresh memory and fresh chain per request, which threw away the share the chain globally pattern that LCEL otherwise enabled and added per-request construction overhead. `RunnableWithMessageHistory` fixed this by parameterizing the history. The Runnable itself is stateless. At call time the caller passes `config={'configurable': {'session_id': 'user-abc'}}`. The wrapper invokes a user-supplied `get_session_history(session_id)` factory that returns a `BaseChatMessageHistory` for that session. Backed by anything you want (in-process dict, Redis, Postgres, etc.). The wrapper reads history before the chain, runs the chain, and appends the new exchange to the same session's store afterward. The other MCQ options describe orthogonal features. Compression (summarization) was already in `ConversationSummaryMemory`. Windowing was in `ConversationBufferWindowMemory`. Encryption is a storage concern that any backend can implement. None of those were the bug. The bug was statefulness, and that is what the new primitive fixed.

Quick reference

TL;DR

RunnableWithMessageHistory parameterises history by session_id with a per-call factory, fixing the statefulness bug in ConversationBufferMemory that made it unsafe to share across concurrent sessions.

Memory aid

Easy to grasp

Picture a notebook on the wall labelled 'last conversation'. If two people use the same notebook at the same time, they bleed into each other's notes. The fix is to give each person a notebook with their name on it and have a clerk hand the right notebook to whoever walks in. The clerk is the per-session lookup; the named notebook is the session-keyed history. The same shared chain can now serve everyone safely.

Key concepts

LLM frameworks Agents

Detailed answer & concept explanation

~5 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

3 minutes: name the statefulness bug in old memory, describe the session_id parameterization fix, walk the get_session_history factory pattern, and connect to LangGraph's checkpointer as the next-step generalization.

Code example

python

from langchain_core.runnables.history import RunnableWithMessageHistory
from langchain_core.chat_history import BaseChatMessageHistory, InMemoryChatMessageHistory
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain_openai import ChatOpenAI

store: dict[str, BaseChatMessageHistory] = {}

def get_session_history(session_id: str) -> BaseChatMessageHistory:
    if session_id not in store:
        store[session_id] = InMemoryChatMessageHistory()   # swap for Redis / Postgres in prod
    return store[session_id]

prompt = ChatPromptTemplate.from_messages([
    ('system', 'You are a helpful assistant.'),
    MessagesPlaceholder(variable_name='history'),
    ('human', '{input}'),
])
chain = prompt | ChatOpenAI(model='gpt-4o-mini')

chat = RunnableWithMessageHistory(
    chain,
    get_session_history,
    input_messages_key='input',
    history_messages_key='history',
)

# Same `chat` object: different sessions, isolated history
chat.invoke({'input': 'Hi, my name is Alex.'},
            config={'configurable': {'session_id': 'alex'}})
chat.invoke({'input': 'Who am I?'},
            config={'configurable': {'session_id': 'alex'}})        # remembers
chat.invoke({'input': 'Who am I?'},
            config={'configurable': {'session_id': 'beth'}})        # cold start

Real-world examples

Real products, models, and research that use this idea.

LangChain's current chatbot tutorials use RunnableWithMessageHistory with Redis backing
Production deployments serving Claude Opus 4.7 or GPT-5.5 chat use this pattern with Postgres-backed history for durability
Vercel AI SDK takes a different approach, history is passed in per request explicitly, but the structural principle (no state on the shared chain) is the same
Many production teams migrate further from RunnableWithMessageHistory to LangGraph once they need typed state beyond message history

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does this pattern compare to LangGraph's checkpointer for managing conversation state?

QWhat goes wrong if get_session_history returns a new in-memory history every call?

QWhat are the trade-offs between in-process, Redis, and Postgres backends for session history?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Reading the question as being about a feature (compression, windowing, encryption) when the actual fix is structural. Statefulness was the bug, not buffer size or security.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.