AWS Bedrock AgentCore Memory: three patterns for namespace-level long-term agent memory with IAM access control

On April 29, 2026, AWS published reference architectural patterns for organizing long-term agent memory within the Bedrock AgentCore Memory service. The post, authored by Noor Randhawa, Akarsha Sehwag, and Piradeep Kandasamy, presents three patterns for different use cases and shows how IAM condition keys enforce access control at the individual namespace level.

Three namespace patterns

1. Actor-Scoped (semantics and preferences)

User facts and preferences accumulate across multiple sessions and are consolidated under a single actor identifier. Structure:

/actor/{actorId}/facts/
/actor/{actorId}/preferences/

Typical use case: application user settings, historical decisions, profile memories.

2. Session-Scoped (summaries)

Conversation summaries remain tied to specific interactions. Structure:

/actor/{actorId}/session/{sessionId}/summary/

Benefit: reduces token consumption for subsequent turns within the same session without mixing context between unrelated conversations.

3. Episodic with Reflection Hierarchy

Episodes capture reasoning traces within an individual session; reflections generalize learnings across sessions at the parent namespace level. This is the most sophisticated pattern for agents that must “learn from experience” across user sessions.

Two key API methods

AgentCore Memory distinguishes:

• RetrieveMemoryRecords — semantic search for contextually relevant memory during agent interactions
• ListMemoryRecords — enumerates memory within a specific namespace for display, audit, or bulk operations

The distinction matters: the first performs vector search, the second a plain listing — used for audit tooling, GDPR-style deletion, or user-managed memory.

IAM access control at the namespace level

Perhaps the most important part for enterprise: IAM condition keys for strict access control:

• bedrock-agentcore:namespace with StringEquals — exact-match access
• bedrock-agentcore:namespacePath with StringLike — hierarchical retrieval

Dynamic scoping uses principal tags such as ${aws:PrincipalTag/userId} for user isolation — an agent working for one user cannot accidentally retrieve another user’s memory.

Why does this matter?

Memory is currently the weakest part of production multi-agent systems — either too small (static prompt context), or too large (an entire vector store leaking between users). AgentCore Memory namespace patterns give AWS customers a conventional structure that can be audited, IAM-controlled, and consolidated per actor.

This builds on the AWS post from April 29 about the AgentCore MCP proxy (governance layer between agents and tools) — AWS is building an enterprise agent stack layer by layer: identity, memory, tool access, audit.