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

Flashcard·Medium·4.0 · 0·~30s·Asked atMicrosoft Cursor Perplexity

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.

Quick reference

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

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.

State the structural mismatch (stateful Memory vs stateless Runnable), describe the multi-tenant breakage concretely, walk the `RunnableWithMessageHistory` contract (session_id config, history factory, store backends), list production wins (horizontal scaling, pluggable persistence), and finish with the LangGraph checkpointer connection.

Real-world examples

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.
LangGraph's `checkpointer` (Postgres/Redis backed, keyed by `thread_id`) is the analogous pattern for stateful agent graphs, same architectural principle at a different layer.
FastAPI-backed LangChain services typically inject the chain as a module-level singleton and pass `session_id` from the request headers, the chain serves many tenants without isolation contortions.

Interviewer follow-ups

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

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

QWalk through a multi-tenant production setup with `RunnableWithMessageHistory` and Redis.

QWhat's the relationship between `RunnableWithMessageHistory` and LangGraph's checkpointer-based memory?

Don't say this

Red flags and common mistakes 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 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.