Session Managers
1. Session Managers
If you're building anything beyond a single turn tool like a coding assistant, a support agent, or a research assistant, you need conversation history to persist across runs or sessions of the agent. In Strands, session managers handle this. You can start by storing session information in local files using the built-in file session manager. Let's take a look at the code using the same customer service example we've been using. I import file session manager. Then I create a new instance of the session manager and pass in a session ID and the storage directory. This session ID is how you identify this specific conversation and the storage directory is where the files will be saved. In a real-world application, you wouldn't hardcode these. These would need to be scoped to a specific user session so that if two users were using the same agent, they would have different isolated sessions for their conversation history. But for now, this is fine while we're just learning. We'll build up to a more production-ready solution by the end. To use the session manager, when you create the agent, you simply just pass it in. That's it. Every message and every state change will now be automatically persisted to disk at the directory we specified. We'll give this a run. And then we'll start chatting. Say, "Help me return my order." And already you can see that this sessions directory was created. And if we open this up, you can see that we have the agent messages are coming through. So if I open up message zero, you can see "Help me return my order." And message one is the response "I'd happy to I'd be happy to help you with that return." as well as some metadata and some different information here. So now I can say per C001 1001 which is the customer ID. And now more messages are being added on the side. Other information that it includes is the session.json which includes the session ID that we had created, and then there's also things like agent.json which includes internal state information about this agent. If we continue chatting, it will continue to populate these files over here. And then I can exit. Now I'll restart the script with the same file session manager configuration, the agent automatically restores the full conversation history and state. When I ask what are you helping me with, it should be able to find the messages and let me know. Yep, it says you reached out about returning your order, so we know that it was able to retrieve those memories. Persistence happens automatically at three points. When the agent initializes, it loads existing session data. When a message is added, it writes back to persistent memory. And after each invocation, it syncs agent state and conversation manager state. You don't need to call save or flush, Strands handles this for you. Under the hood, session managers are implemented as hook providers. That means persistence is really just another harness behavior layered into the agent life cycle through hooks. So everything you learn about hooks is what makes persistence, plugins, and steering all work. So that's the local file session manager. But once you're ready to deploy your agent somewhere, you're going to want to store this information off of your local disk. The nice thing is the way that Strands works, you can define a different session manager and swap the component without rewriting the entire app. For example, you could persist conversation history in Amazon S3, the object storage service from AWS. If you already have an AWS account and an S3 bucket set up, you can define an S3 session manager. You import it. You create an instance of the S3 session manager, passing in the session ID, the bucket name, an optional prefix, and the AWS region. Then, you pass that to your agent and you're done. When you use it, it saves the same session structure we saw, but now stored in S3 instead of the local file system. Later, I'll show you how to set up and use Amazon Bedrock agent core memory, which is especially interesting because it gives you more than just short-term persistence. It also supports long-term memory patterns where it automatically extracts information from the raw conversation history that can be retrieved by the agent when needed, like conversation summaries, user preferences, and semantic facts. We'll use that later in the course when we deploy our agent to the cloud. But, the great part is that the integration pattern is still the same. Just swap out the session manager. One other important distinction here, because this is something I think gets confused a lot. Session managers handle conversation persistence, but in production, your agent's context usually comes from many different sources beyond just the conversation history. Customer data from a database, product information from a rag system, user preferences from long-term memory, or operational state from external systems. Those are separate context sources that you can dynamically retrieve data from at runtime using tools that you wire into your agent independent of raw conversation history storage. Up next, we'll tackle multi-agent systems. We'll start with one of the simplest orchestration patterns, wrapping one agent as a tool for another using the agent as a tool pattern.2. Final slide
Context and memory in place — now build multi-agent systems.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.