Bedrock Agents Memory and Session Summarisation
Amazon Bedrock Agents can persist a summary of each finished session under a memory identifier and replay recent summaries into later sessions with the same user.
Agents for Amazon Bedrock provides a managed memory feature so you do not have to build the cross-session recall layer yourself. It is deliberately narrow: it stores session summaries, and it replays recent ones at the start of a new session.
The two identifiers
Getting these right is most of the battle. sessionId identifies one conversation. memoryId identifies the long-lived subject of the memory - in practice, the end user. Many sessions sit under one memory id. If you reuse a memoryId across different people, you have merged their memories; if you generate a fresh one per conversation, you have no long-term memory at all.
How it works
You enable memory on the agent with a memoryConfiguration that sets enabledMemoryTypes to SESSION_SUMMARY, a storageDays retention period, and a sessionSummaryConfiguration controlling how many recent session summaries are carried forward. That is a control-plane call on the bedrock-agent client; you then prepare the agent and invoke it through a versioned alias.
At runtime you pass both sessionId and memoryId to InvokeAgent. Within the session, the agent keeps the conversation in its own short-term context as usual. When the session ends - because you set endSession=True, or because the session idle timeout expires - the agent generates a summary of that conversation and stores it under the memoryId. The next session started with the same memoryId begins with those recent summaries already available to the agent.
Two runtime operations matter operationally, and both are data-plane calls on the bedrock-agent-runtime client rather than control-plane calls on bedrock-agent: GetAgentMemory lets you read back what the agent believes about a user, and DeleteAgentMemory erases it. The second is not optional in production - it is your answer to both an erasure request and a memory that has drifted or been poisoned.
What this is not
Session attributes are not memory. sessionState.sessionAttributes travels with the session and is forwarded to your action groups; promptSessionAttributes is injected into the prompt. Both are short-term carriers scoped to the session, and both are only as durable as the caller that supplies them. Nothing in session state survives to the next session.
Nor is a session summary a system of record. It is generated by a model and is lossy. An order number, a refund amount, an approval flag or an entitlement must live in DynamoDB, not in prose the agent wrote about itself. Use the summary for continuity of understanding; use a database for facts you will act on.
The gotchas
Summarisation happens at the end of the session, so a session abandoned without endSession contributes nothing until the timeout fires - a browser closed mid-conversation can lose its context. And because only a bounded number of recent summaries is replayed, older sessions fall off; memory here means recent memory, not complete history.
If you need finer-grained control - raw event storage, multiple extraction strategies, memory for agents you build yourself rather than Bedrock Agents - Amazon Bedrock AgentCore provides a dedicated Memory service with short-term event storage and configurable long-term extraction. Bedrock Agents memory is the managed, low-effort option; AgentCore Memory is the option you reach for when session summaries are too coarse.
Example
import boto3
control = boto3.client("bedrock-agent")
runtime = boto3.client("bedrock-agent-runtime")
# 1. Enable memory on the agent, then prepare and alias it.
control.update_agent(
agentId=AGENT_ID,
agentName="support-agent",
agentResourceRoleArn=ROLE_ARN,
foundationModel=MODEL_ID,
memoryConfiguration={
"enabledMemoryTypes": ["SESSION_SUMMARY"],
"storageDays": 30,
"sessionSummaryConfiguration": {"maxRecentSessions": 5},
},
)
control.prepare_agent(agentId=AGENT_ID)
# 2. memoryId = the user. sessionId = this conversation.
response = runtime.invoke_agent(
agentId=AGENT_ID,
agentAliasId=AGENT_ALIAS_ID,
memoryId=f"user-{user_id}",
sessionId=conversation_id,
inputText="Where did we get to with my replacement order?",
)
for event in response["completion"]:
if "chunk" in event:
print(event["chunk"]["bytes"].decode(), end="")
# 3. Close the session so the summary is written now, not at timeout.
runtime.invoke_agent(
agentId=AGENT_ID,
agentAliasId=AGENT_ALIAS_ID,
memoryId=f"user-{user_id}",
sessionId=conversation_id,
inputText="",
endSession=True,
)
# 4. Inspect or erase what the agent remembers.
runtime.get_agent_memory(
agentId=AGENT_ID,
agentAliasId=AGENT_ALIAS_ID,
memoryId=f"user-{user_id}",
memoryType="SESSION_SUMMARY",
)
# runtime.delete_agent_memory(agentId=..., agentAliasId=..., memoryId=...)When to use it
- A returns agent that greets a repeat caller already knowing the previous case was escalated, without the caller repeating themselves.
- An internal IT helpdesk agent whose memory retention is capped at 30 days to satisfy a data-minimisation policy.
- A support platform that calls DeleteAgentMemory when a customer requests erasure, or when an agent's stored summary is found to contain a bad instruction.
Discussion