Video Transcript (English)

By now, you know what short-term memory is, why it matters, and why MongoDB is a great fit for implementing it. In this video, we're going to build it!

We'll use the checkpointer API in LangGraph with MongoDB as our persistent storage. By the end of this video, you'll have laid the foundation for an agent that remembers conversations within a thread, maintains isolation between threads, and can pause and resume anytime.

Let's get started.

Before we dive into the code, let's review our environment. We're working with two main components: LangGraph and MongoDB.

LangGraph is an agent framework that makes it easy to build conversational AI applications. It handles the flow of messages, tool calls, and state management. We’re going to work with its checkpointer API, which is the mechanism that lets us persist conversation state externally.

MongoDB is our persistent storage layer. It stores the conversation checkpoints so they survive beyond a single API call or application restart.

To get started, there are three packages we need to import. Each package plays a specific role.

`MongoDBSaver` is LangGraph’s MongoDB’s checkpointer implementation. `MongoClient` handles our database connection. And `create_agent` is what builds our LangGraph agent.

With these pieces in place, we're ready to set up our checkpointer.

First, we establish a connection to MongoDB using the `MongoClient`.

We then instantiate the MongoDBSaver class. This creates a checkpointer that manages the agent's short-term memory, allowing it to persist and retrieve its state in a conversation.

When we create a checkpointer this way, it automatically creates two collections in our database. The first is `checkpoints`, which stores the conversation state including the messages, context, and everything the agent needs to remember. The second collection is `checkpoint_writes`, which logs each individual action the agent takes, such as specific tool calls and their corresponding outputs.

This detailed log acts as a safety net, allowing the system to recover accurately after an interruption and providing a clear, step-by-step audit trail of the agent's behavior.

At this point, we have a place to store our agent’s short-term memory, but the agent is not using it yet. To persist conversation state on every turn, we need to connect this checkpointer to an agent.

To create an agent with short-term memory, we pass the checkpointer into the create_agent function.

Under the hood, create_agent builds a LangGraph state graph using our chosen LLM and tools.

We include the `checkpointer` parameter as part of the build to tell the agent to persist its conversation state after every interaction.

This allows the agent to handle things like retrying a failed task or resuming a conversation using a specific thread ID. If we waited to add the checkpointer, the agent wouldn't know how to keep things consistent or how to jump back into a conversation after it's been paused.

Now we need a way to interact with the agent. To do so, let's create a simple chat function.

Notice the configuration object. It uses the thread_id as the primary key for the checkpointer to save and resume the agent's state. Without it, the agent cannot persist or load its memory. We also include the user_id and thread_id in our function parameters to create a unique conversation identifier for our own tracking purposes.

This is how we achieve what’s called thread isolation. Thread isolation enables the same user to have multiple independent conversations, each with its own memory. And different users are completely separate. Let's see this in action.

We'll start with a simple multi-turn conversation. We'll have a user named Alice chat with the agent in thread-1:

So what happens under the hood here?

In the first message, Alice introduces herself. The agent responds and the checkpointer saves the conversation state to MongoDB.

In the second message, Alice shares what she's learning. Again, the state is saved. In the third message, Alice asks the agent to recall her name.

And the agent remembers. It responds with something like: "You told me your name is Alice."

This is short-term memory in action. The agent isn't storing Alice's name in any special way. It's persisting the entire conversation history.

When Alice asks about her name, the agent has access to all the previous messages and can answer correctly.

Each message builds on the last. The conversation feels natural and coherent. That's exactly what we want.

Now let's see what happens when Alice starts a new thread and asks "Do you know my name?":

This time, the agent doesn't know, even though Alice told it her name in thread-1. Thread-2 is a completely separate conversation. The agent responds with something like: "I don't know your name yet. What should I call you?"

This is thread isolation where each thread has its own memory which is independent from other threads.

Now let's go back to the original thread. If Alice now asks "What have we talked about so far?"), the agent remembers everything previously from thread-1.

It can summarize the conversation: Alice introduced herself, mentioned she's learning about MongoDB, and asked about her name.

Thread-1's memory is intact. Thread-2 is separate. Each conversation maintains its own state, and we can switch between them freely.

Here's what makes what we've built stand out. The conversation state persists within MongoDB. If our application crashes, restarts, or the user closes their browser and comes back tomorrow, the conversation is still there.

This is fundamentally different from LLM context windows. A context window only exists during a single API call. Once the call ends, it's gone. But with MongoDB-backed short-term memory, the agent can resume anytime.

Imagine we stop our application right now, restart it, and ask the agent "Can you remind me what we discussed?"

The agent would have access to the full conversation history and be able to respond.

This is what makes the database approach valuable for production applications. Our users expect conversations to survive interruptions. With MongoDB and the checkpointer API, they do.

Well done!

In this video, we implemented short-term memory using the LangGraph checkpointer API with MongoDB.

We set up a MongoDB checkpointer, created an agent that persists conversation state, and demonstrated both context retention within a thread and isolation between threads.

We saw how the combination of `user_id` and `thread_id` creates unique conversation identifiers, and how the conversation state survives when the application restarts because it's stored in MongoDB.