Name: LangMem
Uploaded: 2025-03-01T11:15:20.523Z
Duration: 2 min 33 s
Description: An SDK enabling AI agents to learn and adapt through long-term memory integration.

langmem

An SDK enabling AI agents to learn and adapt through long-term memory integration.

LangMem

Hi all, Will here. This week we're excited to launch the LangMem SDK—a library of utilities for helping you build agents that learn and adapt as you go. In this video, I will show you how to add semantic memory to your agents so they can remember important facts and other information that guides the content of their responses. 

Semantic memory is all about facts and knowledge. With LangMem, you can chat with your bot. Your bot can save memories for later use, and when you chat with it again, it can reference those memories. As you can see, it remembers that I'm training for a half marathon and that I have a current training plan in place. 

With every interaction, the memory state is updated. Each memory gains additional context—in this case, it now remembers that I'm dealing with tendonitis and need a modified training regimen. So, let's create a React agent with semantic memory. First, we'll review how to make an agent link graph. We'll use the prebuilt wrapper for concision. First, we'll install LangMem.

Then we'll create the agent. We'll give the agent short-term memory in the form of checkpointing, and we'll also provide a long-term memory store. 

(Note that it won't have a direct connection with the long-term store yet, so it won't actually use it.) Now, we'll create the agent again—this time with a little wrapper to make interaction more convenient. 

Now that we've created the agent, we can chat with it. If you continue the conversation along the same thread, it will remember previous context because this is stored in the conversation history (i.e., short-term memory). 

However, if you start a new thread, it won’t remember that information because it isn’t stored long term. Now it's time to add memory. We'll give our agent two tools to interact with the memory store. 

One tool is for creating, updating, and deleting memories. The other is for searching the store whenever it needs to recall information. We will update our long-term memory store by adding an indexing configuration.

This tells LangGraph that anytime you save an item to the store, it will be embedded with a vectorizer so that we can later perform semantic searches over the memories. 

We will create our tools by providing a namespace for the agent to interact with the memory store. The namespace tells LangGraph where to store the memories within its underlying long-term memory system. Since the store is shared across the entire graph, if you have multiple agents—or if you want to save memories pertaining to different users—you may want to organize them under separate namespaces. 

After fixing our model name, let's return to the scenario from before. The agent tells us that it has saved the plan to memory. Let's double-check. Let's check LangSmith to observe a few things. 

First, let's see what the tools look like from the perspective of the agent. We have provided two tools: Manage Memory and Search Memory.

The Search Memory tool allows it to filter, limit, and offset results, but primarily to generate a specific query for searching its memories. Here, you can see that it's looking up "Half Marathon Training Plan" to verify that there are no additional memories it should consult before updating anything. 

After searching its memory, the agent then decides to use the Manage Memory tool. Let's check the Manage Memory tool from the LLM’s perspective. It contains its own set of instructions on when it should be used, allowing the LLM to choose actions for creating, updating, or deleting memories. 

Depending on the action, it can provide content for creations/updates or an ID for updates/deletions. In this case, the agent has decided to create a new memory. If I start a new thread with an ambiguous context that requires the agent to jog its memory, it will perform a search for us. You can confirm in LangSmith that it indeed searched for this memory.

If you follow the agent's trajectory, you see that the first message it receives triggers a memory search for additional contextual information. It then uses those results to respond, indicating exactly where we're supposed to be. If we provide information that conflicts with old memories or requires an update, the agent can again use the Manage Memory tool to update its memories. 

In the corresponding trace in LangSmith, the LLM first calls the Search Memory tool to review existing memories and then uses the Manage Memory tool to update that memory accordingly. It then commits this modified plan to accommodate the injury and saves it to memory, overwriting the previous memory to ensure that all searchable information remains valid. 

Up to this point, the agent has been saving memories in the same namespace—the "agent memories" namespace we created. If your agent supports multiple users, you'll likely want to keep their memories separate to prevent information leakage between interactions.

To do so, add a template variable to your namespace. LangMem interprets this as a value that needs to be populated at runtime from your configuration dictionary. We will recreate the agent and modify our chat helper to accommodate a new user ID. 

If I first chat as User A, the agent will save those memories to User A's namespace. If I then interact with the same agent as User B, it will manage memories that don't conflict with those of User A. You can check that there is no overlap by interrogating the model from the perspective of User ID 2 or by directly searching the store. 

Here, you can see memories for User A (about Will training for a half marathon) and memories for User B (learning chess and wanting to improve). Since these are stored in separate namespaces, the agent cannot access memories from one user when configured for another. If you recall from the agent trace, these tools don't even require a namespace parameter—the agent operates solely on IDs and content.

Behind the scenes, the tool reads your configuration and places memories in the correct location accordingly. If you're paying attention, you'll notice that the agent must actively decide when to search its memories. 

Let's change that. We're going to add an initial search step that scans memories based on the incoming context before calling the LLM. This provides the LLM with relevant information about the conversation before it makes any decisions, potentially saving one or two tool calls if the necessary context is already present. 

What we're going to do is add a memory search step and then incorporate the results into a system prompt so that the LLM can respond with all the relevant context. We'll fetch the store from context and use the content of the most recent message to search for relevant memories. 

This is a quick heuristic—you might want to include context from the last human message (in case there are other tool messages) or more conversational context when generating the query.

Now that we've created our new agent, let's run our simulation again. This time it ran much faster, as confirmed by the LangSmith trace. If you look at the new agent trajectory, you can see the additional prompt step that returns all of the memories (dumped into a string). In this case, the AI still decided to search again for additional memories, which speaks to the trade-offs of exposing this step; however, it had enough information from the default contextual lookup to potentially respond on the first try. 

That's all for today. In this video, we built an agent that can manually manage its own semantic memory. This allows it to store important facts and use them in later conversations. For more information about other memory types and the conceptual framing behind LangMem, check out our concept videos or the LangMem docs. 

See you next time.

Note, that there may be slight differences in text and video. Watch video for the original content.

LangMem Video