LLM Memory in LangChain: Conversation State and Durable Context

LangChain is an open-source framework for building applications with large language models (LLMs). It provides memory classes that give a chain or agent access to earlier parts of a conversation. Without memory, each call to the model is stateless: the model has no knowledge of what was said before.

LangChain memory handles conversation history within a session. It does not handle durable project context across sessions, and it does not provide a shared record that other people or AI tools can read. Tools like fenbs serve that second purpose: keeping the project decisions, task state, and rules outside the model so they are available to any session regardless of which framework or model is in use.

How LangChain memory works

LangChain memory classes sit between chain invocations. At the start of each invocation, the memory class loads its stored history and adds it to the prompt. At the end, it saves the new exchange. The model therefore "remembers" earlier turns because they appear in the text it receives, not because the model itself retains them.

This means the effective memory is bounded by the model's context window (the maximum amount of text a model can process at once). As a conversation grows, older messages either push out newer ones or must be summarized before they fit. The memory class determines how that tradeoff is handled.

Common LangChain memory types

• ConversationBufferMemory: stores every message in the conversation and adds the full history to each prompt. Simple but grows without bound.
• ConversationBufferWindowMemory: stores the last K exchanges. Older messages are discarded. Good for keeping recent context without filling the window.
• ConversationSummaryMemory: maintains a running summary of the conversation instead of the full transcript. Cheaper on tokens but can lose detail.
• ConversationSummaryBufferMemory: keeps recent messages in full and summarizes older ones. A practical middle ground for longer conversations.
• VectorStoreRetrieverMemory: stores exchanges as vector embeddings (a numerical representation for semantic search) and retrieves the most relevant ones for each new message. Useful when the conversation covers many topics.

LangGraph, LangChain's framework for stateful multi-step agents, adds a checkpoint system that serializes agent state to a store between steps. This is closer to durable persistence: a run can be paused and resumed from the last checkpoint, and different threads can share state.

What LangChain memory does not do

LangChain memory scopes to a session or a thread. When the process restarts, in-memory stores are empty. Persistent stores such as Redis or a database extend the life of the data, but the memory is still private to the application and the session identifier it uses.

LangChain memory does not provide a shared record visible to people and other AI tools working on the same project. It does not track which decisions were made by a person and which were generated by the model. It does not show who changed what or when.

For managing related memory architectures and tradeoffs, what is agent memory covers the landscape. For comparing memory approaches to retrieval, see agent memory vs RAG.

Choosing a persistent backend for cross-session memory

When you need LangChain memory to survive application restarts, you configure a persistent backend. Common choices are Redis for low-latency access, a relational database such as PostgreSQL via an SQLAlchemy integration, or a cloud key-value store. The backend stores the serialized history under a session key; loading it at startup resumes the conversation from where it left off.

Test the backend explicitly. Write a conversation history, restart the application, reload from the backend, and confirm the messages are present and in the correct order. Serialization formats can lose precision on special characters or long messages; catching that early is simpler than debugging it in production.

Separating conversation state from project context

A useful pattern is to separate two categories of information: the conversational exchange the LangChain memory class manages, and the durable project context that belongs outside the model entirely.

Conversational exchange includes the current request, intermediate results, and the reasoning steps from this session. This is what LangChain memory is built for. Project context includes the agreed decisions, the current task state, the rules that always apply, and where the last session stopped. This is what a project record is built for.

Mixing the two causes problems. Project decisions written only inside a LangChain memory store are invisible to a different agent, a different framework, or a different session ID. A person reviewing the work cannot see them. Another AI tool working on the same project cannot read them.

How to do this with fenbs

1. Create a free account and add the project your LangChain application supports.
2. Add the project's decisions and rules as Decisions in fenbs. These are facts a person chose, not model-generated text.
3. Connect a supported AI tool over MCP from Integrations to read the project context at the start of each session.
4. After significant sessions, record the outcomes in fenbs: what was completed, what was decided, and where the next session should start.
5. Use LangChain memory for conversation state within a session. Use fenbs for the durable record that survives across sessions and tools.

For managing memory at a higher level, see portable AI memory and AI memory for teams. For the specific memory types in LangGraph agents, see langchain agent memory.