Amazon Bedrock agents maintain session memory during a conversation, but that memory is cleared when the session ends. When a new session begins, the agent has no record of prior interactions.

After introducing external orchestration, the next question is how an agent retains context across executions. To support that requirement, context must be stored outside the agent.

Amazon DynamoDB provides a serverless, low latency data store that integrates directly with AWS Lambda and scales automatically, which makes it well suited for storing agent context. Persistent memory allows the agent to use information from previous interactions to inform future responses.

The agent does not read from or write to DynamoDB directly. Lambda retrieves stored context before invoking the agent and writes updated context after the agent responds.

Session memory is built into Amazon Bedrock agents. When you invoke an agent with a session ID, the agent retains context from previous turns within that session, which allows follow-up questions without repeating earlier details because the agent has access to the conversation history.

Session memory exists only for the duration of the session. So, when the session ends or a new one begins, that context is lost and the agent has no record of prior interactions.

Persistent memory allows context to be reused across sessions. Context is stored in DynamoDB and loaded by Lambda before invoking the agent. After the agent responds, Lambda writes updated context back to DynamoDB.

Storing context outside the session supports scenarios that session memory cannot. The agent can retain user preferences across sessions, track which recommendations have already been provided, and maintain conversation history beyond a single interaction.

Context can also be shared between agents if required. This workflow follows three steps: read, invoke, and write. Before the agent runs, a Lambda function reads stored context from DynamoDB and includes it in the request sent to the agent.

From the agent's perspective, this context is simply part of the input. The agent processes the request using the provided context. It reasons over the input, selects action groups if needed, and generates a response.

The agent remains focused on reasoning and tool invocation, and is not responsible for managing state. After the response is returned, the Lambda function writes updated context back to DynamoDB so it can be used by the next invocation.

The agent never reads from or writes to DynamoDB directly. Lambda manages all state, which keeps the agent focused on reasoning and tool selection. When AWS Step Functions is used, these steps map directly to the state machine.

One state reads context, the next invokes the agent through Lambda, and the final state writes updated context. Step Functions manages execution order, and each component handles a single responsibility.

In a previous demo, "Build your first Bedrock agent," we built a simple Cost Optimizer agent that returns an AWS cost saving tip when asked. Each response is selected randomly from a predefined list.

When the same question is asked multiple times, the agent can return the same recommendation more than once. Persistent memory allows this behavior to be controlled.

Before invoking the agent, a Lambda function reads from Amazon DynamoDB to retrieve the cost optimization tips that the user has already received. Lambda includes this information in the request sent to the agent, guiding the agent to avoid repeating previous recommendations.

For example, the request might state that the user has already received tips about deleting unattached EBS volumes and using Amazon S3 intelligent tiering, and instruct the agent to provide a different cost-saving recommendation.

The agent processes the request and returns a new tip. After the response is generated, the Lambda function writes the new recommendation to DynamoDB and adds it to the user's history.

When the user asks for another tip later, Lambda reads the updated history and includes it in the next request. Across multiple interactions, the agent continues to return varied recommendations without repeating earlier advice.

The agent logic itself does not change, and it still reasons over the input and generates a response. The difference lies in the context provided at invocation time. Lambda manages state and DynamoDB provides persistence across interactions.

Persistent memory allows an agent to retain context beyond a single interaction. Instead of relying on the agent itself to remember previous exchanges, context is stored externally. In this design, Amazon DynamoDB stores user-specific history such as prior recommendations or preferences.

AWS Lambda is responsible for reading that history before each invocation and writing new information after a response is generated. The agent itself remains unchanged.

It continues to reason over the input it receives, while Lambda and DynamoDB work together to ensure context is preserved across multiple interactions.

This approach is useful whenever continuity matters, including scenarios like tracking previous recommendations, maintaining user preferences, or supporting multi-turn conversations.

Persistent memory with DynamoDB

About