Agent Infrastructure and State with Amazon Bedrock AgentCore
Explore Amazon Bedrock AgentCore’s Runtime, Memory, and Identity layers. Learn how to isolate agent sessions, manage short- and long-term memory, secure authentication and credentials, and deploy each layer through sequential testing and infrastructure as code.
A foundation model keeps nothing between calls. An agent that answers “Use my usual shipping carrier” works only if something stores the facts about the user and decides whose data the agent may touch. This lesson covers where the agent runs, where its state lives, how it gets credentials, and how to verify the deployment.
Amazon Bedrock AgentCore splits these concerns across Runtime, Gateway (covered in the previous lesson), Memory, and Identity. A deployment is done when a test user can start a session, leave, return in a new session, and see the agent use what it learned, with no other user’s data in the answer.
The diagram below shows how the four services fit around one agent.
Where agent state lives
State exists at four levels, and each one has a different lifetime. The following table compares them.
State Level | Where It Lives | Lifetime | Use It For |
Context window | The model’s prompt | One model call | The current reasoning step |
Runtime session | One microVM, memory and disk | Up to 8 hours on microVMs; stops after 15 minutes idle by default | Working data of the current conversation |
Short-term memory | AgentCore Memory events | Event expiry you set, 3 to 365 days | Turn-by-turn history, reloadable after a restart |
Long-term memory | AgentCore Memory records | Across sessions | Facts, preferences and summaries across sessions |
Runtime session state is ephemeral. By default, when a session stops, the microVM is terminated and its memory is sanitized, so anything the agent kept in variables or local files is gone. Use AgentCore Memory for anything that must outlive the session.
Design rule: If losing the data at session end would hurt the user, it belongs in AgentCore Memory, not in the agent’s variables.
Hosting agents on AgentCore Runtime
AgentCore Runtime runs the agent as a serverless, containerized application. Each session gets a dedicated microVM with isolated CPU, memory, and filesystem, which prevents one user’s data from leaking into another’s session. The application supplies the runtimeSessionId, which must be at least 33 characters, so a UUID works ...