Memory

What you will be able to do

• ✓Explain why memory is application-managed context, not the model remembering
• ✓Recognise ConversationBufferMemory and its relatives, and why they are deprecated
• ✓Give an agent memory with a checkpointer and a thread_id
• ✓Keep each user’s conversation separate, and inspect what is stored
• ✓Trim or summarize history - and predict what gets forgotten
• ✓Tell conversation memory from persistent memory, and make memory survive a restart

The idea, in plain English

A model call is stateless. Say "My name is Chandu" in one call and ask "What’s my name?" in the next, and the model does not know. Memory is your application keeping the conversation and sending it back each time - Lesson 1.8’s self.messages list.

Classic LangChain wrapped that list in memory classes: ConversationBufferMemory kept everything, ConversationBufferWindowMemory kept the last k exchanges, ConversationSummaryMemory kept a summary. They still run from the langchain-classic package, but every one prints a deprecation warning pointing to create_agent with checkpointing. In LangChain 1.x there is no langchain.memory module at all.

The replacement is a checkpointer. create_agent(..., checkpointer=InMemorySaver()) saves the agent’s messages after every run, under a thread_id you pass in the config. Call again with the same thread_id and the history is loaded and sent with your new message. Different thread_id, different conversation.

Every model output here is from llama3. A chat agent with no tools does not need tool calling, so these runs are the real thing.

Worked example: Chat agent with memory, next to Module 1’s manual version.

Memory is a message list

Without memory, every call is a blank slate. We ran create_agent with no checkpointer: turn 1 got "Nice to meet you, Chandu!", turn 2 got "I don’t actually know your name." Same agent object, no history between calls.

Lesson 1.8’s ChatAgent fixed it by appending each user message and reply to self.messages and sending the whole list: "I remember! Your name is Chandu!" The model did not remember anything - the application supplied the history. Every LangChain memory feature is that list, managed for you.

ConversationBufferMemory and its relatives

Classic LangChain had a family of memory classes. ConversationBufferMemory kept every message - a buffer, nothing dropped. ConversationBufferWindowMemory(k=1) kept the last k exchanges: after three, only q2/a2 remained. ConversationSummaryMemory replaced old messages with a model-written summary.

You will meet them in tutorials. In LangChain 1.4, from langchain.memory import ... fails with ModuleNotFoundError. From langchain-classic they still run, with a warning: "ConversationBufferMemory was deprecated in LangChain 0.3.1 and will be removed in 2.0.0. Use langchain.agents.create_agent instead. For agents that need to remember prior interactions, use create_agent with checkpointing or the Store API." Even InMemoryChatMessageHistory in langchain-core is deprecated as of 1.6.4.

The checkpointer and thread_id

Pass checkpointer=InMemorySaver() to create_agent and pass {"configurable": {"thread_id": "user-123"}} with every invoke. You send only the new message; the agent loads the thread’s history, runs, and saves the result. Call it without a thread_id and it raises ValueError: Checkpointer requires one or more of the following ‘configurable’ keys: thread_id, ...

agent.get_state(config).values["messages"] shows exactly what is stored - the first thing to check when an agent "forgets". Notice the system prompt is not in it: create_agent adds system_prompt to every call, so trimming the history can never remove it. In Module 1 you had to protect messages[0] yourself.

One thread per conversation

A hundred users cannot share one list. thread_id is the session key: we told thread user-123 the name, then asked thread user-456 - "I don’t actually know your name." Same agent, separate histories.

Memory also lives in the checkpointer, not the agent. A new agent with a new InMemorySaver did not know the name, even with the same thread_id - the same as Lesson 1.8’s new ChatAgent() starting empty.

Memory costs tokens

Every turn resends the whole thread. Over five short turns the input tokens llama3 processed went 35, 57, 88, 120, 141 - and they keep growing with every exchange. Lesson 1.8 showed what happens past the context window: Ollama silently dropped the oldest messages.

So a buffer that keeps everything works for short chats and needs a strategy for long ones: trim, summarize, or move facts somewhere else.

Trimming - by whole exchanges

Module 1’s first trim kept messages[0] plus the last N-1 messages, and could start the kept history with an assistant reply whose question was gone. trim_messages does the same with start_on="human": with 5 exchanges and room for 6 messages, without start_on it kept "assistant 3, user 4 ... assistant 5"; with it, "user 4 ... assistant 5" - whole exchanges only.

In an agent, trim in a before_model hook. We kept the last 5 messages: after three facts, "What’s my name?" got "I don’t know your name" while "Where do I live?" got "You live in Hyderabad!" - the name had been trimmed, the city had not. Trimming saves tokens by forgetting, and it forgets the oldest things first.

Summarizing - and what a summary drops

SummarizationMiddleware asks a model to summarize older messages when a trigger is reached, and replaces them with the summary. With trigger=("messages", 6) and keep=("messages", 2), llama3’s summary read: "The user, Chandu, has introduced themselves and shared their interest in Python."

It kept the name and lost the city. "I live in Hyderabad" was summarized away, and "Where do I live?" got "I don’t have that information." A summary is the model deciding what matters - and it can decide wrong.

Watch out: Every way of shrinking memory forgets something. Trimming forgets the oldest messages; summarizing forgets whatever the summary leaves out. Test what your agent still knows after it happens.

Conversation memory vs persistent memory

InMemorySaver - like self.messages - lives in the running process. Stop the program and the conversation is gone. Persistent memory is stored outside: SqliteSaver (pip install langgraph-checkpoint-sqlite) writes threads to a database file. We ran "Hi, my name is Chandu." in one Python process and "What’s my name?" in a second one: "I remember! Your name is Chandu!" - 4 messages loaded from disk.

Not everything belongs in permanent memory. A thread is short-term: this conversation. Long-term facts - the user prefers Python examples - are worth storing separately and loading when relevant; LangGraph’s Store API, named in the deprecation warning, is built for that. Production systems combine recent messages, summaries and stored facts.

Memory and tools together

Lesson 2.7’s agent plus a checkpointer. Turn 1: "My order number is 12345." Turn 2: "Where is my order?" - on that call the model received both turns, so it could call get_order_status with order_id 12345, which it was never given in the second message. (Scripted model, as in Lesson 2.7; llama3 cannot call tools.)

When the agent forgets - a checklist

Before blaming the model, look at what it was given.

Step-by-step code

Tip: Print agent.get_state(config).values["messages"] whenever memory surprises you. It is the LangChain version of printing self.messages.

Memory at a glance

create_agent(..., checkpointer=InMemorySaver())

{"configurable": {"thread_id": "user-123"}}

agent.get_state(config).values["messages"]

trim_messages(..., start_on="human")

@before_model

SummarizationMiddleware(model=llm, trigger=...)

from langgraph.checkpoint.sqlite import SqliteSaver

from langchain_classic.memory import ...

Try it yourself

The code does not change. Swap the content string and the program does something else entirely.

What usually goes wrong

✗ from langchain.memory import ConversationBufferMemory

✓ create_agent(..., checkpointer=InMemorySaver())

✗ {"configurable": {"thread_id": "chat"}}

✓ {"configurable": {"thread_id": session_id}}

✗ checkpointer=InMemorySaver()   # for production users

✓ checkpointer=SqliteSaver(conn)  # or another database-backed saver

✗ [messages[0]] + messages[-(n - 1):]

✓ trim_messages(..., include_system=True, start_on="human")

Quick check before you move on

1. 1.

   You call agent.invoke() with a checkpointer but no config. What happens?

   Show answer
2. 2.

   Same agent, thread user-123 knows the name. What does thread user-456 say?

   Show answer
3. 3.

   After trimming to 5 messages, the agent forgot the name but remembered the city. Why?

   Show answer
4. 4.

   Which classic class matches ConversationBufferWindowMemory(k=2) today?

   Show answer

Interview questions