Building Short-Term Conversational Memory

What is Conversational Memory?

At their core, LLM API calls are stateless. Each call is an independent event with no inherent memory of past calls. To create a conversational experience, we must build a memory system at the application layer. The most fundamental type is short-term memory, often called working memory.

This system's job is to:

1. Keep track of the back-and-forth messages in a conversation.
2. Provide this history as context for the next turn.

Conceptually, this is as simple as maintaining a list of messages and feeding it back to the LLM with each new user query.

This simple approach works, but it's not robust. As you build complex agents with multiple steps and tool calls, you need a more structured way to manage and persist the entire state of the agent, not just the messages.

This is where short-term memory (for the current conversation) fits into the broader picture, as distinct from long-term memory (for recalling facts across many conversations).

The LangGraph Solution: Checkpointers and Threads

In the last lesson, you worked extensively with the State object in LangGraph. This object held the messages, tool outputs, and other data needed for a single execution run. The key to conversational memory is persisting this state between invoke calls.

LangGraph provides a clean, powerful abstraction for this: Checkpointers.

A Checkpointer is a component that automatically saves the entire state of your graph at specified intervals (e.g., after every step). When you later invoke the graph for the same conversation, the checkpointer loads the last saved state, allowing the agent to pick up exactly where it left off.

To distinguish between different conversations, you provide a unique identifier for each one, typically called a thread_id. All invoke calls sharing the same thread_id will share the same persisted state and thus belong to the same conversation.

Implementing Persistent Memory with Redis

Now, let's put this into practice. While InMemorySaver is useful for quick tests, a real application requires a durable backend like a database to store the conversation state. This ensures that conversations can be resumed even if your application restarts. Redis, being a fast in-memory data store, is an excellent choice for this.

The following video provides a complete, practical walkthrough of integrating RedisSaver into a LangGraph agent to give it short-term memory.

By adding just two key pieces—the checkpointer object at graph creation and the thread_id at invocation—you've made your agent conversational.

Under the Hood: The Importance of Reducers

You've now seen how to implement memory, but for deep mastery, it's crucial to understand why it works so efficiently. Why doesn't LangGraph just overwrite the messages list in the state with each new update?

The answer lies in reducers.

As you may recall from your computer science background, a reducer is a function that takes an accumulated value and a new value and returns a new accumulated value (e.g., reduce(accumulator, new_value) -> new_accumulator).

In LangGraph, you can associate a reducer with each field in your state definition.

• By default, the reducer is overwrite.
• For conversational history, you need an append or add behavior.

LangGraph provides a special, highly optimized reducer called add_messages. When a node returns a new message, this reducer intelligently appends it to the existing list of messages in the state, even handling complex cases like updating tool calls. This is far more efficient than loading the entire state object, modifying a list in Python, and writing the whole object back.

Understanding reducers is what separates a user of the framework from an architect who can design robust, efficient, and custom stateful agents.

from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph import add_messages
from langchain_core.messages import BaseMessage

class PackageTrackerState(TypedDict):
    # The 'messages' field will use the add_messages reducer to append.
    messages: Annotated[list[BaseMessage], add_messages]
    
    # The 'package_status' field has no reducer, so it will be overwritten
    # with each update.
    package_status: str

Conclusion

In this lesson, you have equipped your agent with one of the most critical capabilities for practical use: memory. You've moved beyond single-shot executions and can now build agents that sustain context over an entire conversational session.

Key Takeaways:

• Memory is an Application-Layer Construct: LLMs are inherently stateless; we must build memory systems around them. Short-term memory maintains context within a single conversation.
• Checkpointers are the Key to Persistence: In LangGraph, checkpointers (like RedisSaver or PostgresSaver) are the mechanism for automatically saving and loading an agent's state.
• Threads Define Conversations: A thread_id passed during invocation tells the checkpointer which conversation's state to load, enabling you to manage multiple concurrent conversations.
• Reducers Enable Efficient State Updates: The add_messages reducer is the low-level mechanism that ensures conversational history is appended correctly and efficiently, rather than being overwritten.

What's Next?

Now that your agents can conduct complex, multi-step tasks and remember the context of a conversation, we can focus on making their reasoning process even more sophisticated. In our next lesson, "Design an agentic workflow that includes a planning step to decompose a complex user request into a sequence of sub-goals," we will dive deeper into the logic of the "supervisor" agent. You will learn how to prompt the agent to explicitly break down a user's request into a structured plan before execution, leading to more reliable and transparent agentic systems.