Amazon Bedrock AgentCore - Memory | Amazon Web Services

Key Takeaways

Hello everyone. As part of the Amazon Bedrock agent core video series, we are going to cover agent core memory. As part of this video, so let's start with a simple scenario that describes the problem that we are trying to solve. Imagine you are talking to a tech support agent about an issue with your computer. You spend around 30 minutes explaining your problem. The agent suggests some workarounds and then you hang up. A week later, you call back the agent again because none of the solution worked. But here is the problem. Because the agent is stateless, it has completely forgotten everything you discussed previously. So you have to start over again explaining the same issue all over again. This is exactly what memory aims to solve. It provides a mechanism to store and retrieve relevant agent experiences during runtime creating a personalization layer between agents and the users. So let's go back to our tech support example. So when you first call in the agent suggests workarounds and stores the entire interactions in the memory. Now when you call back the next time hey none of those workarounds actually worked the memory system kicks in. It provides the agent the context of your previous conversation what was tried before what did not work and what kind of solutions were suggested. Now the agent can pivot intelligently saying so I see those previous workarounds didn't help. Let's try something different this time. So this gives us a several key benefits. First, the context retention across sessions. The agent remembers your history. Second, the improved decision quality over time. It learns what worked and what did not. Third, reduced processing and latency. No need to research the same solution repeatedly. Finally, the personalization at scale. The agent learns about each user individually. So we can split the memory into two broad categories. First is short-term memory. This is essentially a collection of raw events like user messages or tool calls and assistant responses. It also handles session management and conversation branching. Think of it like you have the ability to go back and edit the previous message and create a new conversation branch. The short-term memory gets updated accordingly. So for example, you looking for flight tickets from Atlanta to New York and then you change your mind to change the destination to New Jersey. So memory gets updated accordingly based on the new edits. So that is short-term memory. The second category is the long-term memory which extracts meaningful and actionable information from those raw events. For example, if you keep asking your agent to generate code in camel case, it might learn that as a user preference. Or if you buy a grand latte at Starbucks three times a week, it extracts I buy coffee three times a week as a semantic fact. While I like grande becomes a user preference. At a very high level, here is how it works. Like know user interactions first goes into the short-term memory storage. Then an offline workflow extracts meaningful information based on specified strategies whether that's user preferences or semantic facts or session summaries. Finally, a consolidation phase manages these memories over time, dduplicating, merging or updating information to maintain accuracy. So, memory transforms AI agents from stateless tools into intelligent assistant that learns and adapt over time, making every interaction more personalized and effective. So, with this, we'll go into the code walkthrough in the demo. First import the memory client from the bedrock agent core. Then define the memory name. Then create memory using memory client by passing the memory name uh description event expiry date which defines the TTL like know time to live. In this case it's 7 days and the poll interval which checks the status in regular interval. In this case it's for every 10 seconds. You can see that the memory got created in the console. Next, we create the langraph agent. This function creates a langraph based fitness coach agent that integrates with agent core memory for conversation persistence. It sets up a chat bedrock lm with clots on it. defines the list events tool for retrieving conversation history and builds a graph for flow that automatically saves user assistant exchanges to memory while providing personalized fitness guidance based on remembered context. Then we define the actor ID and the session ID. These ids ensure each conversation session is uniquely tracked in the memory system allowing the agent to maintain separate conversation history for different users and workout sessions. Then we do couple of interactions with the workout routine. All these conversations are getting saved in the short-term memory. Next, we will test the short-term memory retrieval functionality by creating a new agent instance using the same actor ID and the session ID. This demonstrates like no session continuity. When we ask about the previous interaction, the agent successfully retrieves the conversation history from the memory and provides contextually relevant responses based on the earlier exchanges. Next, we will go through the long-term memory. First we will define the memory name. Then let's create a memory using the memory client by passing the memory name, description, event expiry date, the poll interval. The main difference here is we also pass the strategy and the name space. As I mentioned earlier, there are three kinds of strategies. The user preferences, semantic facts or the session summaries. The name spaces the memory system uses an hierarchical structure similar to S3 storage like know where extracted information is organized under the specific path using runtime variables like um actor ID, the strategy ID or the session ID ensuring like know complete data separation between users and preventing information leakages across different user sessions. Then we define the actor ID, the session ID and the name space. These three IDs ensure each conversation session is uniquely tracked in the memory system allowing the agent to maintain separate conversation histories for different users and work sessions. Here we are just mocking up some previous conversations and adding all those to the short-term memory. This one adds everything to the short-term memory. when we list all the events it displays all the previous mocked up conversations. So behind the scenes you know you know after the create event call is done the memory system detects that the memory has the user preference strategy configured. So without any additional coding, the system analyzes the conversation for the preference indicators, identifies the statements like like uh I am a vegetarian and I really enjoy Italian cuisines and extract these preferences into structured data. The extracted preferences are saved in the configured name space. This automatic process ensures that important information is preserved in the long-term memory even after the short-term memory conversation records expires. Now when you try to retrieve the content like foot preferences from the memory, you can see the context and the user preferences. So when you ask for the restaurant recommendations in your wine based on the user preferences, it was able to provide the appropriate restaurant suggestions in your wine. So that's the end of this code walkthrough of agent code memory. Thanks.