AgentCore Memory, end to end.

Yesterday we mapped the /invocations wire contract. Today we move one layer up: how an agent remembers what happened on the last turn, and what it remembers about you across sessions. AgentCore Memory is the managed answer to the statelessness problem — and it splits cleanly into two halves stitched together by a single hierarchical path called a namespace.

01Two halves of the same store

From the docs: "AgentCore Memory is a fully managed service that gives your AI agents the ability to remember past interactions … It provides a simple and powerful way to handle both short-term context and long-term knowledge retention without the need to build or manage complex infrastructure."

It splits into two memory types that work together:

• Short-term memory captures turn-by-turn interactions within a single session. Lets the agent resolve "What about tomorrow?" after "What's the weather in Seattle?" without asking you to repeat yourself.
• Long-term memory automatically extracts and stores key insights from conversations across multiple sessions — user preferences, important facts, session summaries — for persistent knowledge retention.

02The seven words you need

AgentCore Memory has its own small vocabulary. The official memory terminology page spells it out:

Two things to internalise: events are immutable and timestamped, and long-term records are scoped to a namespace. Everything else falls out of those two facts.

03Short-term: write events, get them back

You write to short-term memory with CreateEvent. Every event is keyed by actorId (who) and sessionId (which conversation). Payloads come in two shapes:

• Conversational — messages with a role (user, assistant) and content. Only conversational data flows into long-term memory.
• Blob — binary or JSON. Stored, but it stays in short-term.

The high-level Python SDK wraps it cleanly:

Notice there's no "create a session" API call — sessions are an organisational concept. A session exists the moment you write the first event with a given sessionId.

Event branching is built in. The branch parameter on CreateEvent lets you fork from any prior event (rootEventId + name) — perfect for edited messages or "what if we tried this path instead." The original branch stays intact; you can switch back.

04Long-term: strategies do the extraction

By default, an AgentCore Memory only stores raw events. To get long-term memory, you attach one or more memory strategies when you call create_memory (or via update_memory later).

Built-in strategies, all from the Built-in strategies page:

• SEMANTIC — extracts factual statements from a conversation and consolidates them into searchable records.
• USER_PREFERENCE — builds a persistent profile of preferences ("prefers window seats", "vegetarian", "Eastern Time").
• SUMMARIZATION — condenses each session into a summary record you can recall instead of replaying every turn.
• EPISODIC — structured episodes for richer reflection — has its own per-session token budget (see Limits).

Each strategy runs three internal steps powered by an LLM: Extraction (find useful insights in short-term), Consolidation (write to a new record or update an existing one), and Reflection (generate insights across episodes). Each step is driven by a system prompt with an output schema specific to that strategy. You can ship built-in with overrides strategies if you want to tweak the prompt or model.

Important footnote from the docs: "Long-term memory records will only be extracted from conversational events that are stored after a new strategy becomes ACTIVE. Conversations stored before a strategy is added will not be processed for long-term memory." So: add the strategy first, then have the conversation.

05Namespaces: how multi-tenant isolation actually works

Every long-term record lands inside a namespace, which is a hierarchical path like a file path. You set the template on the strategy at creation time and AgentCore Memory fills in the placeholders at extraction time. From the memory organization page:

Reconstruction from the memory-organization reference

Three rules the docs are explicit about:

• Use forward slashes to separate levels.
• Always end with a trailing / to prevent prefix collisions in multi-tenant apps — /actors/Alice/ won't collide with /actors/AliceCorp/, but /actors/Alice would.
• Pick the granularity you actually need. Most granular is per-actor-per-session; coarsest is a single global /.

The namespace is also your IAM boundary. The condition keys bedrock-agentcore:namespace (exact match) and bedrock-agentcore:namespacePath (hierarchical prefix) let you write policies like "this role can only call RetrieveMemoryRecords on records under summaries/agent1/*." That's how a per-tenant role gets per-tenant memory access without standing up a per-tenant memory resource.

06Retrieving long-term records

Two read patterns. List by namespace prefix when you want everything under a path:

Semantic search when you want the top-k most relevant records to a query (this uses the embedding-backed semantic index that the SEMANTIC strategy maintains for you):

The high-level Strands integration takes this even further — you configure a retrieval_config per namespace prefix and the agent automatically pulls the right slice on every turn:

This is the seam where AgentCore Memory and your agent runtime stop being two services and start feeling like one.

07Limits worth knowing

From the official quotas page:

• 150 AgentCore Memory resources per account per Region. Adjustable.
• 6 strategies per memory resource. Not adjustable. Plan your strategy mix carefully — that's the hard ceiling per store.
• Event retention: 7 to 365 days. Not adjustable. If you need raw conversation history for longer, archive it yourself; long-term records persist independently.
• Per-event size: up to 100 messages per CreateEvent, 100 KB per message, 10 MB per event. Not adjustable.
• Long-term extraction throughput: 150,000 tokens/minute per account per Region across built-in strategies (adjustable, tracked via the TokenCount CloudWatch metric in the Bedrock-AgentCore namespace).
• Episodic extraction: 50,000 tokens/min per session. Not adjustable — design your sessions accordingly.
• Write throughput: 10 CreateEvent TPS per account, but only 5 TPS per actor/session for conversational payloads.
• Read throughput: 30 RetrieveMemoryRecords TPS per account.

And two non-quota gotchas: only conversational payloads flow into long-term memory, and strategies don't backfill — they only apply to events stored after the strategy is ACTIVE.

08Try it in five minutes

Assuming an existing agentcore project from yesterday's tip:

The very first call may return nothing — extraction is asynchronous. Give the strategy a beat, then re-run; the user-preference record should appear under the namespace you configured (default /users/{actorId}/preferences/ if you used the SDK example).

Tomorrow we'll look at AgentCore Identity — OAuth, credential vending, and how an agent gets a token to call a downstream tool on behalf of the user without you writing the auth code.