Why did LangChain replace `ConversationBufferMemory` with `RunnableWithMessageHistory`?

Flashcard·Medium·4.0 · 0·~30s·Asked atIronclad Kpmg Lambda Labs

Attempt it

Memory subclasses were stateful: they held the conversation buffer on the object itself and mutated it on each call. That broke composition with the (deliberately) stateless Runnable model, you could not share a chain across users without sharing their histories. RunnableWithMessageHistory wraps a chain and parameterises the history by session_id: the history store (Redis, Postgres, in-memory) is looked up per call, threaded into the prompt as {history}, and updated after the response. The chain stays stateless, sessions are explicit, and multi-tenant deployment works without contortions.

Your answer

**The old pattern.** `ConversationBufferMemory` was a class that held the conversation history as a field on itself. You constructed it, attached it to a chain, and every call read from and wrote to the same buffer. That works fine in a notebook with one user. It breaks the moment you have two users. A Runnable (LangChain's core abstraction) is designed to be **stateless**, you compose Runnables with `|`, share them across requests, and they behave the same regardless of who called them. A stateful `Memory` attached to a Runnable violates that. Two users hitting the same chain see each other's conversation history because they share the same `Memory` object. The workarounds were ugly: construct a fresh `Memory` per request, thread it manually through the chain, monkey-patch the chain to swap in the right buffer. All of it fighting the stateless design. **The new pattern.** `RunnableWithMessageHistory` wraps a chain and parameterises the history by `session_id`. You configure a history-store factory (Redis, Postgres, SQLite, in-memory dict) keyed by session id. On each call, you pass a `session_id` in the config; the wrapper looks up that session's history, threads it into the prompt as `{history}`, runs the chain, and appends the new messages to the same store. The chain stays stateless. Sessions are explicit. Multi-tenant deployment works without contortions.

**The deprecation fixed a structural mismatch.** `ConversationBufferMemory` and its siblings (`ConversationSummaryMemory`, `ConversationEntityMemory`) held conversation state on the object itself, mutating internal fields on each call. The Runnable model is, by design, stateless: composing Runnables with `|` produces a chain you can share across requests because the chain's behaviour is a function of its input alone. A stateful `Memory` attached to a Runnable broke that invariant. **The breakage in production.** Two users hitting the same chain instance shared the same `Memory` object's buffer. User B saw User A's history appended to their prompt. The workarounds, construct a fresh `Memory` per request, thread it through the chain manually, monkey-patch, all fought the stateless design rather than embracing it. **`RunnableWithMessageHistory` is the embrace.** It wraps a Runnable and parameterises the history by `session_id`. You pass a history-store factory (Redis-backed `RedisChatMessageHistory`, Postgres-backed, SQLite-backed, plain dict for dev) keyed by session id. Every invocation passes a `session_id` in `config={"configurable": {"session_id": ...}}`. The wrapper looks up that session's history from the store, threads it into the prompt as `{history}` (or wherever you mapped it), runs the chain, and appends the new messages to the same store. **Three structural wins.** 1. The chain itself stays stateless and shareable. One chain instance serves a million users. 2. Sessions are explicit. The session id is right there in the call, not hidden in an attached object. 3. The history store is pluggable. Swap Redis for Postgres or in-memory without touching chain code. The deprecation isn't cosmetic, it aligns the memory pattern with the Runnable model so multi-tenant deployment stops requiring contortions.

TL;DR

Old `Memory` held state on the chain object, breaking multi-tenancy; `RunnableWithMessageHistory` parameterises history by `session_id` and keeps the chain stateless.

Memory aid

Easy to grasp

Picture a customer-service phone line where every caller hears the previous caller's last sentence whispered into their ear because the operator never resets her notepad. That's the old `ConversationBufferMemory`, one shared notepad on the chain object. The new pattern hands every caller their own labeled folder; the operator pulls the right folder for the right caller, reads from it, writes to it, and puts it back. The phone line itself stays clean, each caller's history lives in their own folder addressed by a session id.

Key concepts

LLM Frameworks

Concept explanation~2 min read

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

LangChain's deprecation of ConversationBufferMemory is one of the better-motivated breaking changes in the library's history. The old pattern looked fine in tutorials, ran fine in notebooks, and quietly broke when production traffic arrived. The new pattern, RunnableWithMessageHistory, is more verbose for the trivial case but aligns memory with the stateless Runnable model that the rest of LangChain depends on.

This explanation walks the structural mismatch, the concrete production failure mode, the new contract, and the relationship to LangGraph's checkpointer-based memory for agent graphs.

The structural mismatch that prompted the deprecation

Runnables are designed to be stateless. The contract is: invoke a Runnable with an input, get an output that's a deterministic function of that input (modulo provider-side non-determinism in LLM calls). The whole reason prompt | model | parser works is that each step's behavior depends on its input, not on what other calls happened to be in flight or completed earlier. That's what lets you share a chain across requests, instantiate it once at module load, and trust that two concurrent calls don't interfere.

ConversationBufferMemory violated this. It held the conversation history as an attribute on the object (self.buffer) and appended to it on every call. Attach the memory to a chain, and the chain now has hidden state: its behavior depends on what previous calls left in the buffer.

In a notebook with one user, this is fine and even convenient. In any production service with concurrent users, it's a multi-tenancy bug waiting to happen. The framework gave you a primitive (stateless Runnables) and a feature (Memory) whose semantics directly contradicted each other.

How the breakage manifested in production

The new contract: externalize state, key by session

Three production wins from the new pattern

Where this fits relative to LangGraph

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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

Production LangChain apps using `RedisChatMessageHistory` keyed by user-session id, with TTL configured at the Redis layer for automatic cleanup.
LangChain's own migration docs show the before/after pattern explicitly, deprecating `ConversationBufferMemory` and showing `RunnableWithMessageHistory` as the replacement.

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

QHow would you implement `ConversationSummaryMemory`'s semantics on top of `RunnableWithMessageHistory`?

Two clean approaches. One: subclass BaseChatMessageHistory with a custom add_messages that triggers a summarization LLM call when the buffer exceeds a token threshold, replacing old turns with a summary message. Two: keep raw history in the store and add a chain step before the prompt that conditionally summarizes if {history} is too long. Option two keeps the storage layer simple and the compression behavior explicit.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Sharing a chain across users when the chain has a stateful Memory attached, two users now silently share each other's conversation history.

60 second bullets to scan on the way to the call.

Why a stateful Memory attached to a stateless Runnable breaks multi-tenancy.
How RunnableWithMessageHistory externalises history into a store.

Primary sources. Browse if you want the original framing.