LangChain Agent Memory: Keep Useful Context Across Runs

LangChain agents use memory classes to carry context forward inside a chain or across multiple calls. Without a memory class, each call to a chain is stateless: the agent receives only what is in the current prompt and returns only the current response.

The built-in memory classes differ in what they store, how long they store it, and whether they survive a process restart. Tools like fenbs keep the shared task list and standing decisions outside LangChain entirely, so any connected assistant, whether it runs the same chain or a different one, picks up the same project context at the start of each session.

In-memory history: fast but transient

ConversationBufferMemory holds the full message history in a Python list in memory. It is the simplest option and requires no external dependencies. The limitation is that it disappears when the process ends. Use it in scripts that run start to finish in one invocation, where continuity across restarts is not needed.

ConversationBufferWindowMemory keeps only the last k exchanges rather than the full history. This limits the token count sent to the model on each call, which matters once a conversation grows long. Both classes are in-memory and are equally transient. If you restart the process, the history is gone.

Summary memory: a compressed view of the conversation

ConversationSummaryMemory uses an LLM call to compress earlier messages into a summary as the conversation grows. The agent then receives the summary plus the most recent messages, rather than the full history. This keeps the prompt size manageable for long conversations but introduces latency and cost from the extra summarization call.

Like the buffer classes, ConversationSummaryMemory is in-memory by default. For persistence, pass it a chat_memory argument pointing to a persistent message history backend.

Persistent memory: surviving a process restart

LangChain's ChatMessageHistory backends write messages to an external store. SQLChatMessageHistory writes to a SQLite or PostgreSQL database. RedisChatMessageHistory writes to Redis. Pass a session ID when you instantiate the history backend; LangChain stores all messages for that session under that ID and retrieves them on the next call.

Pair a persistent history backend with any memory class by passing it as the chat_memory argument. The memory class handles the summarization or windowing logic; the backend handles durability. For a comparison of backend options and their tradeoffs, see how to build agent memory and agent memory vs RAG.

Verifying that memory persists across restarts

Run a four-step check after setting up a persistent backend.

1. Run the agent and send at least one message that the agent should remember.
2. Stop the Python process completely.
3. Start the process again and instantiate the same memory class with the same session ID.
4. Send a follow-up message that requires the agent to recall what was said in step one. Confirm it does.

If step four fails, check that the session ID is the same in both runs and that the backend is writing to a durable location rather than to an in-memory instance. For a deeper look at memory recall and retrieval patterns, see agent memory vs RAG.

Handling handoffs between agents

When one LangChain agent hands work to another, the receiving agent needs enough context to continue without re-reading the entire history. Pass a summary or a structured context object rather than a raw message list. The handoff context should answer three questions: what was being worked on, what was decided, and what remains to be done.

A handoff that relies on a shared persistent backend is cleaner than one that passes the full history as a prompt. Both agents read from and write to the same session store. The receiving agent loads the history and continues where the previous one stopped. See agent memory vs context for more on structuring context for handoffs.

Choosing a session ID for persistence

The session ID is the key that links runs together across a persistent backend. A good session ID is stable, unique per conversation or project, and meaningful to the people maintaining the system. A user ID combined with a project identifier works well. Avoid generating a fresh random ID each time the process starts; a new ID creates a new empty message history on every invocation, which defeats the purpose of a persistent backend.

Store the session ID outside the agent process in a configuration file or an environment variable tied to the deployment. If the session ID is held only in memory, a crash or restart creates a new session. The previous history remains in the database under the old ID but is unreachable until you restore the ID. Choose the session ID scheme before the first real data is written, since changing it later means either migrating or abandoning existing history.

How to do this with fenbs

Use LangChain's memory classes for the agent's conversation history. Use fenbs for the project record that multiple agents and team members need to read.

1. Create a free account and add your project to fenbs with the current tasks and standing rules.
2. Connect your assistant from /integrations and add a fenbs context-read step before your LangChain chain runs.
3. Choose a persistent backend: SQLChatMessageHistory for a local SQLite file, or RedisChatMessageHistory for a shared Redis instance.
4. Use a stable session ID tied to the project or user, not a random ID generated on each run.
5. Before the session ends, ask the agent to save progress in fenbs so the next session starts with an accurate Where we left off.