Memory Strategies

From the previous lesson, recall the split: short-term memory is the raw, immutable interaction events you write with CreateEvent; long-term memory is the derived memory records AgentCore extracts across sessions — but only if you attached a strategy. No strategy means no extraction: you get raw events and nothing else.

A strategy is the instruction that tells AgentCore Memory what to pull out of those raw events and how to organize it. You attach strategies at CreateMemory time, or add them later to an existing memory resource.

import boto3
control = boto3.client('bedrock-agentcore-control')

resp = control.create_memory(
    name="ShoppingSupportAgentMemory",
    memoryStrategies=[
        {'summaryMemoryStrategy': {
            'name': 'SessionSummarizer',
            'namespaceTemplates': ['/summaries/{actorId}/{sessionId}/']}},
        {'userPreferenceMemoryStrategy': {
            'name': 'UserPreferenceExtractor',
            'namespaceTemplates': ['/users/{actorId}/preferences/']}}
    ])
# then poll until ACTIVE before writing events
# control.get_memory(memoryId=...)['memory']['status'] == 'ACTIVE'

Two limits to internalize now. There is a hard cap of 6 strategies per memory — and per the quotas page this one is not adjustable, so design within it. (The account-level ceiling of strategies is adjustable; the per-memory 6 is fixed [VOLATILE — verify the live quotas page].) Extraction is also asynchronous: a record written by CreateEvent does not appear in RetrieveMemoryRecords instantly. Build for eventual consistency — a retrieve immediately after a create will commonly return nothing.

AgentCore gives you three ways to implement a strategy, trading control for cost and operational burden.

Built-in is the default starting point: managed extraction and consolidation with prompts AWS has benchmarked. You attach a strategy type and AgentCore does the rest. It carries a higher storage cost because the service stores and manages the derived records for you.

Built-in with overrides keeps AgentCore's pipeline and fixed record schema but lets you replace the extraction instructions and choose which Bedrock model runs them. Because those are now your LLM calls, you must supply a memoryExecutionRoleArn the service assumes, and the Bedrock inference is billed to your account.

Self-managed (GA October 2025) hands extraction and consolidation entirely to you — any model, prompt, and schema — and you push the finished records into AgentCore purely for storage and retrieval. It has the lowest storage cost of the three because the service is doing the least work.

Built-in (and built-in-with-overrides) ship in four flavors. Each runs a different subset of the pipeline and extracts a different shape of record.

Semantic captures durable facts ("the user is allergic to peanuts", "works in EST"). It outputs JSON facts and processes only USER and ASSISTANT message roles. Default namespace: /strategy/{memoryStrategyId}/actors/{actorId}/.

Summary produces a rolling per-session summary as XML <topic> chunks. It runs Consolidation only (no separate Extraction step) — and crucially its namespace must include {sessionId} because a summary is session-scoped (more on that below).

User Preference extracts JSON records of context / preference / categories ("prefers email over phone", "dark mode"), again from USER/ASSISTANT roles only.

Episodic (GA October 2025) auto-detects when an episode completes, outputs XML, and — uniquely — runs a Reflection step that analyzes patterns across episodes. Episodes are indexed by "intent" and reflections by "use case". For best results, include TOOL results in the events you write so the model sees what actually happened. Episodes and reflections take longer to appear than the other types.

This is the single most common configuration error, and it is worth memorizing cold. The SDK / API config key and the CLI enum for the same strategy do not always share a name. The worst offender is Summary.

The trap: the SDK key is summaryMemoryStrategy, but the CLI enum is SUMMARIZATION — not the intuitive SUMMARY. Pass SUMMARY to the CLI and it will reject it.

In the boto3 / SDK path you pass the config-key objects:

control.create_memory(
    name="ComprehensiveMem",
    memoryStrategies=[
        {'semanticMemoryStrategy':       {'name': 'Facts'}},
        {'summaryMemoryStrategy':        {'name': 'Summaries',
                                          'namespaceTemplates': ['/summaries/{actorId}/{sessionId}/']}},
        {'userPreferenceMemoryStrategy': {'name': 'Prefs'}}
    ])

In the starter-toolkit CLI you pass the enums on --strategies:

# short-term only (no strategies)
agentcore add memory --name my_agent_memory

# attach built-in strategies by their CLI ENUMS
agentcore add memory --name ShoppingMem --strategies SUMMARIZATION,USER_PREFERENCE
agentcore add memory --name ComprehensiveMem --strategies SEMANTIC,SUMMARIZATION,USER_PREFERENCE

agentcore deploy && agentcore status

Every built-in strategy runs the same async pipeline; the four types simply differ in which steps they use.

1. Extraction — the model reads raw events and produces candidate insights (facts, preferences, episodes). Semantic, User Preference, and Episodic run this; Summary skips it.
2. Consolidation — candidate insights are reconciled against existing records. The consolidation engine decides per record: ADD (new), UPDATE (supersede), or NO-OP (nothing new). Critically, when a record is superseded, the outdated one is marked INVALID rather than deleted — you keep an immutable audit trail of how the memory evolved. All four types run Consolidation.
3. Reflection — episodic only. After episodes accumulate, Reflection analyzes patterns across episodes to derive higher-order insights (the "use case" index).

 raw events
     │
     ▼
 [Extraction]      ← Semantic, User Preference, Episodic  (Summary skips)
     │  candidate insights
     ▼
 [Consolidation]   ← ALL types: ADD / UPDATE / NO-OP
     │  outdated records → INVALID (kept, immutable audit)
     ▼
 [Reflection]      ← EPISODIC ONLY: cross-episode patterns
     │
     ▼
 queryable memory records

Because the engine never destructively overwrites, you can audit why a memory record says what it says today — the superseded INVALID versions remain. Do not treat INVALID records as garbage to clean up; they are the history.

Two built-in strategies have sharp edges that aren't obvious from the config key.

Summary is session-scoped — its namespace MUST contain {sessionId}. A summary describes one session, so AgentCore requires {sessionId} in the namespace template. Omit it and the strategy is misconfigured.

# CORRECT — summary namespace includes {sessionId}
{'summaryMemoryStrategy': {
    'name': 'SessionSummarizer',
    'namespaceTemplates': ['/summaries/{actorId}/{sessionId}/']}}

Episodic reflections can span multiple actors — a privacy gotcha. Reflection looks for patterns across episodes, and depending on how you've scoped namespaces, those episodes can belong to different actors. If actor A and actor B's episodes feed the same reflection, A's data can leak into an insight surfaced for B. Mitigate by reflecting at the actor level (scope the namespace so each actor's reflections stay within {actorId}) or by adding guardrails. Treat this as a default-unsafe behavior to design around, not an edge case.

Overrides: appendToPrompt REPLACES the default — despite the name. When you use built-in-with-overrides, the field is called appendToPrompt (max ~30 KB [VOLATILE — verify quotas]), but it does not append — it replaces the default extraction instructions. So you must rebuild on the documented base prompt, not just add a sentence to it. Two more rules: do not rename the consolidation operations (AddMemory / UpdateMemory) and do not change the record schema. Overrides also require memoryExecutionRoleArn, and the LLM calls are billed to your account.

# built-in-with-overrides sketch (custom strategy with overridden instructions)
{'customMemoryStrategy': {
    'name': 'DomainSemantic',
    'configuration': {
        # appendToPrompt REPLACES the default instructions — build on the base
        'appendToPrompt': '<your full extraction instructions, <= 30KB>',
        # plus your chosen Bedrock model id; requires memoryExecutionRoleArn on the memory
    }}}