1. What is LangChain memory and how does it work?

LangChain memory is a mechanism that stores conversation history and injects it into the prompt before each LLM call. Since language models are stateless by default, LangChain manages the context externally. Each call reads stored history, passes it to the model, and writes the new exchange back to memory.

2. What's the difference between ConversationBufferMemory and ConversationSummaryMemory?

Buffer memory stores all conversation messages verbatim, which keeps everything accurate but grows large fast. Summary memory uses an LLM call to compress older exchanges into a shorter summary. Buffer memory is better for short sessions; summary memory handles long ones without burning through your token budget.

3. How do I persist LangChain memory across sessions?

Default memory is in-memory and resets on restart. To persist it, use a backend-backed message history like RedisChatMessageHistory or PostgresChatMessageHistory. Assign each user a unique session_id so their conversation history is stored and retrieved correctly between sessions.

4. Can LangChain memory work with agents?

Yes, but you need to attach it explicitly and set return_messages=True when using chat models. Agents using the CONVERSATIONAL_REACT_DESCRIPTION type work well with buffer memory. The memory key also needs to match what the agent prompt template expects, typically chat_history.

5. How many tokens does LangChain memory consume?

It depends on the memory type. Buffer memory passes every message, so token count grows linearly with conversation length. Window memory caps it based on recent turns. Summary memory compresses aggressively. For production use, always calculate token cost per turn and factor it into your per-request budget.

6. What is ConversationEntityMemory used for?

Entity memory extracts and tracks specific entities mentioned in a conversation, such as names, organisations, or locations. Instead of storing raw messages, it builds a structured knowledge base of what the model knows about each entity. It's most useful for apps where the user references specific people or things across many messages.

7. What does return_messages=True do in LangChain memory?

When set to True, memory returns conversation history as a list of HumanMessage and AIMessage objects instead of a single concatenated string. Chat models like GPT-4o require this structured format to process history correctly. Without it, the prompt may be malformed and responses will be unpredictable.

8. How do I use different memory for different users in LangChain?

Create a separate memory instance per user session using a unique session_id. If you're using Redis or a similar backend, each session_id maps to its own stored history. Never share a single memory object across users, as it will merge their conversation histories.

9. Is LangChain memory suitable for production applications?

Buffer memory alone isn't enough for production. You need persistent storage, proper session isolation, and a memory type that manages token usage. ConversationSummaryBufferMemory with a Redis or PostgreSQL backend is a common production setup that balances context retention and cost.

10. Can I build custom memory types in LangChain?

Yes. LangChain's memory classes are built on a BaseChatMemory interface. You can subclass it and override load_memory_variables and save_context to implement any custom storage or retrieval logic, including fetching context from a vector store or a database query.

11. How does LangChain memory interact with RAG pipelines?

In a retrieval-augmented generation setup, memory and retrieval serve different purposes. Memory holds conversational context from the current session. A vector store retrieves relevant document chunks based on the query. They can work together, where conversation history helps refine the retrieval query and both types of context get passed to the LLM in the final prompt.