How does RunnableWithMessageHistory feed prior turns into a LangChain LCEL chain?

## What the wrapper does `RunnableWithMessageHistory` turns a stateless chain into a conversational one without changing the chain. It is a runnable itself, so it keeps `invoke` / `stream` / `batch` and composes like any other. Per call it performs four steps: resolve the session, load history, run the inner chain with history injected, and persist the turn. ## The session comes from config, not from the input The conversation key travels in the runnable config, not the payload: `chain.invoke(payload, config={"configurable": {"session_id": "abc"}})`. The wrapper hands that value to your `get_session_history` callable, which returns a `BaseChatMessageHistory` for that conversation. Because the factory is yours, the backend is your choice — an in-process dict for tests, Redis or SQL in production — and the chain above never knows the difference. Forgetting the configurable value is an error, not a silent stateless run. One session id is rarely enough in a real product; you usually want user plus conversation. `history_factory_config` accepts a list of `ConfigurableFieldSpec` objects, which lets the factory take several parameters (for example `user_id` and `conversation_id`) that callers pass under `configurable`. ## Wiring the keys If the inner runnable takes a bare list of messages, no keys are needed — history is simply prepended. If it takes a dict (the common case with a prompt template), you must say which key is which. - `input_messages_key` — the dict key holding this turn's user input. - `history_messages_key` — the key the loaded history is injected under. It must match the placeholder variable your prompt reserves for prior messages; a mismatch means the model sees an empty conversation while the store quietly fills up. - `output_messages_key` — needed when the chain returns a dict rather than a message or string, so the wrapper knows which field to persist. ## What gets persisted After the inner chain returns, the wrapper appends both sides of the turn. Consequences worth stating in an interview: a failed turn may leave the input recorded without an answer; retries can double-write; and streaming persists once the stream completes, so a client that disconnects mid-stream can produce a half-recorded turn. If exactly-once semantics matter, write to the store yourself instead of relying on the wrapper. ## The cost it hides Nothing here bounds size. Every turn reloads the full history and re-sends it, so prompt tokens grow roughly linearly with conversation length, latency drifts up, and eventually the provider rejects the request for exceeding the context window. Memory in LangChain is a context-window budget problem, and this wrapper deliberately does not solve it — you compose a trimming or summarizing step into the inner chain, ahead of the prompt, so it runs on every invocation. ## Where it sits in LangChain 1.x This is the successor to the pre-1.0 `ConversationChain` plus `BaseMemory` pairing, which coupled memory to a specific chain class. The wrapper is composable instead: any runnable, any store. For richer state — branching, resuming a partially completed run, human approval mid-flight — LangChain now points at graph-level persistence rather than a flat message log, and the honest interview answer names that boundary: this wrapper is right for chat transcripts and thin for workflow state.