JA EN
shiichan

Amazon Bedrock AgentCore Memory now lets you add up to 5 custom namespace keys!

AWS What's New ★★★★ View Markdown
#aws#ai#security

Hey, it's Shii! AWS just shipped an update that's a bit understated but really scratches an itch, so let me walk you through it. Amazon Bedrock AgentCore Memory's memory organization just got a lot more flexible!

AWS What's New aws.amazon.com

What was announced?

AWS's What's New page announced that Amazon Bedrock AgentCore Memory now supports "flexible namespace variables." AgentCore Memory manages long-term memory for AI agents, and it decides how to organize that memory through a hierarchical structure called a namespace. With this update, you can now define your own custom keys to scope memories along application-specific dimensions like organization, tenant, team, or environment.

The story so far

Until now, the only variables you could use in a namespace template were the three built-in ones: actorId (who the memory belongs to), sessionId (which session it's from), and strategyId (which memory strategy is used). If a multi-tenant application wanted to also split memories by organization or team, you'd have had to duplicate strategies or repurpose the built-in variables in ways that didn't quite match their original meaning, which was a bit awkward.

What changes

You can now register your own keys (like orgname or teamname) on a memory resource, then reference them inside a strategy's namespace template as {orgname}. At runtime, you just pass the actual values along when you call the CreateEvent API to record an event. The service automatically substitutes those values into the template during long-term memory extraction.

That means multi-tenant SaaS products and agent applications with complex org/team/environment hierarchies can now keep memories cleanly separated and organized, without adding more strategies.

Dive Deep

Let's look a bit closer at how it works.

  • You register custom keys using the namespaceKeys parameter when you create or update a memory resource
  • You can define up to 5 keys per memory resource, and up to 5 custom variables per namespace template
  • Key names must be lowercase alphanumeric, at most 32 characters, and can't reuse a built-in variable name like actorId or sessionId
  • For each key, you can optionally set validation with a list of allowed values (up to 10) and/or a regex pattern (up to 64 characters); if you set both, a value must satisfy both

For example, if you want to split memories by organization and team, you could create a memory resource like this.

aws bedrock-agentcore-control create-memory \
    --name "MultiTenantAgentMemory" \
    --memory-strategies '[{"semanticMemoryStrategy": {"name": "TenantScopedStrategy", "namespaceTemplates": ["/org/{orgname}/team/{teamname}/actor/{actorId}/session/{sessionId}/"]}}]' \
    --namespace-keys '[{"key": "orgname"}, {"key": "teamname"}]'

Then, when you call CreateEvent, you just pass the orgname and teamname values in the extractionConfig.namespaceVariables field. If you forget to supply a custom variable that a strategy needs, the event itself still gets recorded successfully, but long-term memory extraction for that strategy is simply skipped. To catch that, it's worth setting up vended logs and watching the NamespaceResolutionFailure metric.

One more nice touch: IAM policies can now use the bedrock-agentcore:namespaceVariable/{key} condition key. That lets you enforce write-path tenant isolation, like allowing CreateEvent only when orgname equals acme, purely through policy, without writing any authorization code. On the read path (ListMemoryRecords, RetrieveMemoryRecords), the existing condition keys already work against the fully resolved namespace, so no extra setup is needed there.

Wrap-up

Here's a recap of today's update.

  • Namespace templates now support up to 5 custom keys of your own choosing, on top of the 3 built-in ones (actorId, sessionId, strategyId)
  • Custom keys can be shared across multiple strategies, so you no longer need to duplicate strategies just to split memories by tenant or team
  • Each key can be validated with allowed values or a regex pattern, and IAM condition keys let you enforce write-path tenant isolation
  • Available at no extra cost in every region where AgentCore Memory is generally available

If you're building a multi-tenant SaaS or an agent application with a complex org/team/environment hierarchy on top of AgentCore Memory, this is a quiet but genuinely useful update!

Related posts