--- title: "AgentCore Memory — short-term events, long-term strategies, and the namespace that ties them together" date: 2026-05-28 service: "Amazon Bedrock AgentCore" component: "Memory" tags: [agentcore, memory, short-term, long-term, namespaces, strategies, events, actors, sessions, semantic, summarization, user-preference, episodic] source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html verified_on: 2026-05-28 url: https://vanemmerik.ai/aws-ai/2026-05-28.html --- # AWS Bedrock & AgentCore · Tip of the Day · 2026-05-28 ## AgentCore Memory — short-term events, long-term strategies, and the namespace that ties them together 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**. agentcore add memory \ --name ShoppingSupportAgentMemory \ --strategies SEMANTIC,SUMMARIZATION,USER_PREFERENCE agentcore deploy ≈ 8 min read · Bedrock AgentCore · Memory --- ## 01 · Two 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 across sessions. > **The shift.** You stop hand-managing chat history in DynamoDB and > stop bolting RAG onto every conversation. Short-term is a stream of > immutable events the platform stores for you; long-term is what an > LLM-powered extraction pipeline distills out of that stream and > drops into searchable namespaces. --- ## 02 · The seven words you need AgentCore Memory has its own small vocabulary. The official [memory terminology page](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-terminology.html) spells it out: | Term | What it is | | --- | --- | | **AgentCore Memory** | The top-level container resource. Holds all events and extracted insights. | | **Memory strategy** | Configurable rules that decide what to extract from short-term into long-term. | | **Namespace** | A hierarchical path (`/users/{actorId}/preferences/`) used to group long-term records. | | **Memory record** | A structured unit of long-term information, identified by ID, scoped to a namespace. | | **Session** | One continuous interaction. Grouped by `sessionId`. | | **Actor** | The entity interacting with the agent (user, agent, or system). Grouped by `actorId`. | | **Event** | The fundamental unit of short-term memory. Immutable, timestamped, organized by `actorId` + `sessionId`. | 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. --- ## 03 · Short-term: write events, get them back You write to short-term memory with [`CreateEvent`](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_CreateEvent.html). 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: from bedrock_agentcore.memory import MemorySessionManager from bedrock_agentcore.memory.constants import ( ConversationalMessage, MessageRole, ) mgr = MemorySessionManager(memory_id=MEMORY_ID, region_name="us-west-2") session = mgr.create_memory_session( actor_id="User1", session_id="OrderSupportSession1", ) session.add_turns(messages=[ ConversationalMessage("Hi, how can I help you today?", MessageRole.ASSISTANT), ]) session.add_turns(messages=[ ConversationalMessage( "I just made an order, but it hasn't arrived. Order #35476.", MessageRole.USER, ), ]) # Replay the tail of the conversation for turn in session.get_last_k_turns(k=5): print(turn) 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. --- ## 04 · Long-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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/built-in-strategies.html): - **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. --- ## 05 · Namespaces: 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-organization.html): namespaceTemplates = [ "/strategy/{memoryStrategyId}/actor/{actorId}/session/{sessionId}/" ] Available variables: **`{actorId}`**, **`{strategyId}`**, **`{sessionId}`**. 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 `/`. Granularity choices, straight from the docs: | Pattern | What it isolates | | --- | --- | | `/strategy/{memoryStrategyId}/actor/{actorId}/session/{sessionId}/` | One record set per actor per session. | | `/strategy/{memoryStrategyId}/actor/{actorId}/` | One actor's memory across all their sessions. | | `/strategy/{memoryStrategyId}/` | All actors, scoped to a single strategy. | | `/` | Global. Everything in one bucket. | 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. --- ## 06 · Retrieving long-term records Two read patterns. **List by namespace prefix** when you want everything under a path: records = session.list_long_term_memory_records(namespace_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): hits = session.search_long_term_memories( query="can you summarize the support issue", namespace_path="/", top_k=3, ) 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: retrieval_config = { f"/users/{actor_id}/facts": RetrievalConfig(top_k=3, relevance_score=0.5), f"/summaries/{actor_id}/{session_id}": RetrievalConfig(top_k=3, relevance_score=0.5), } This is the seam where AgentCore Memory and your agent runtime stop being two services and start feeling like one. --- ## 07 · Limits worth knowing From the [official quotas page](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html): - **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; the 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`. --- ## 08 · Try it in five minutes Assuming an existing `agentcore` project from yesterday's tip: # 1. Add a memory with two long-term strategies and deploy it agentcore add memory \ --name CustomerSupportMemory \ --strategies SEMANTIC,USER_PREFERENCE agentcore deploy agentcore status # wait for ACTIVE # 2. Write a few turns from a Python shell python - <<'PY' import boto3 from bedrock_agentcore.memory import MemorySessionManager from bedrock_agentcore.memory.constants import ConversationalMessage, MessageRole control = boto3.client("bedrock-agentcore-control", region_name="us-west-2") memory_id = control.list_memories()["memories"][0]["id"] mgr = MemorySessionManager(memory_id=memory_id, region_name="us-west-2") s = mgr.create_memory_session(actor_id="User1", session_id="demo-1") s.add_turns(messages=[ConversationalMessage("I prefer window seats and aisle access.", MessageRole.USER)]) s.add_turns(messages=[ConversationalMessage("Noted — I'll remember that.", MessageRole.ASSISTANT)]) # 3. After a minute or two, ask long-term what it learned for r in s.search_long_term_memories(query="seat preference", namespace_path="/", top_k=3): print(r) PY 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. --- **Verified against the official AWS docs on 2026-05-28.** Sources: , , , , , , , , . If the docs change, this lesson is a snapshot of that day — check the sources for current behaviour. --- > **This page — research, writing, verification, and deployment — was built by > Claude Cowork.** No human touched the prose, the layout, or the upload > pipeline. The lesson was generated this morning, cross-checked against the > official AWS docs by an independent verification pass, and published > to Cloudflare R2 on a schedule. > > A daily experiment by Monty van Emmerik · — AWS Bedrock & AgentCore · Tip of the Day · No. 003 · vanemmerik.ai