AgentCore Memory: AWS Long-Term Memory Deep Dive

AgentCore long-term memory is the part of Amazon Bedrock AgentCore Memory that turns raw conversation events into durable records an agent can search later. You write turns as events (short-term memory). Configured memory strategies then extract facts, preferences, summaries or episodes from those events and store them as memory records in namespaces, where any later session can retrieve them.

AgentCore became generally available in October 2025. This page follows the AgentCore Memory developer guide, the API reference and the pricing page, checked on 8 November 2026. The new additions since October (harness managed memory, record streaming, metadata filters, cross-account access, redrive) are covered below.

What is AgentCore Memory?

AgentCore Memory is a fully managed AWS service that stores an agent’s conversation history as events and, through configurable strategies, extracts long-term memory records from them. Records are organized by namespaces built from actor and session IDs, and retrieved by semantic search so agents can personalize answers across sessions.

It handles both layers of short-term and long-term memory:

• Short-term memory is turn-by-turn context inside one session. It’s the raw events you send with CreateEvent. When the user asks “What about tomorrow?”, the agent reads the recent events to know they meant tomorrow’s weather in Seattle.
• Long-term memory is what strategies extract across sessions: “prefers window seats,” an order number, a summary of last week’s support case.

A memory resource with no strategies stores events only. AWS says plainly that without strategies, no long-term records are extracted.

Key building blocks

Events also support branching, so you can fork a conversation from an earlier event to try an alternative path without losing the original.

The four built-in memory strategies

Each built-in strategy runs an LLM pipeline with up to three steps. Extraction pulls insights from events. Consolidation decides whether to write a new record or update an existing one. Reflection, only in the episodic strategy, draws insights across episodes.

The semantic and user preference strategies only read USER and ASSISTANT messages. Both default to the namespace /strategy/{memoryStrategyId}/actors/{actorId}/, so records are grouped per user. Summaries default to a per-session namespace, /strategy/{memoryStrategyId}/actor/{actorId}/session/{sessionId}/. You can combine several strategies on one memory resource.

Episodic memory and reflections

The episodic strategy, added after GA, is the closest AgentCore comes to episodic memory in AI agents. AgentCore detects when an episode is complete and writes one structured record with the situation, intent, assessment, justification and an episode-level reflection. Records only appear after an episode ends, so they lag behind the other strategies.

Reflections then analyze many episodes to find patterns: which tool combinations tend to succeed, which approaches fixed past failures. AWS recommends including TOOL results in your events for best results. Reflections can be stored at the actor level or the strategy level. The docs flag a privacy point: strategy-level reflections can span multiple users, so reflect at the actor level if that’s a concern.

Overrides and self-managed strategies

Built-ins are the easiest path but the least flexible. Two other options trade setup for control:

• Built-in with overrides: you change the extraction or consolidation prompts and choose a Bedrock model, which runs in your account. Storage is cheaper than built-in.
• Self-managed: AgentCore notifies your pipeline (via S3 and SNS) when trigger conditions are met, and you run your own extraction with any model, then write records back. You own the infrastructure.

Direct ingestion: long-term memory without events

Since 8 September 2026 you don’t have to store data as a short-term event to get long-term records from it. The IngestData API (AWS announcement) sends content straight to the memory’s configured long-term strategies.

Use it to backfill memory from history you already keep elsewhere (old chat logs, CRM activity, app events) without replaying it as sessions, or when you only want the extracted facts and not the raw turns. The announcement doesn’t say how direct ingestion is billed, so check the pricing page before a large backfill. In open source, Hindsight’s retain call is the equivalent single step: send it content and a model extracts facts, time, entities and relationships into long-term memory, with no separate event store in front.

Expiring long-term records (TTL)

Events always expired (3 to 365 days), but until October 2026 long-term records stayed forever. Since 13 October 2026 you can give them a time-to-live (AWS announcement, developer guide). The default is still no expiry.

Three details matter in practice:

• Changes are not retroactive. A TTL is stamped on each record when it’s made. Changing or removing it affects only records created afterwards, and expired records can’t be recovered.
• Expiry is not immediate. Background deletion “can typically take a few days”, and until then RetrieveMemoryRecords, GetMemoryRecord and ListMemoryRecords can still return the record. For a privacy deletion, call DeleteMemoryRecord or BatchDeleteMemoryRecords instead.
• It needs its own permission. Any request carrying a TTL also needs bedrock-agentcore:UpdateMemoryRecordExpirySpecification, or it fails with AccessDeniedException. AWS’s reason: a short TTL is a delayed delete, so without this permission anyone who can update a memory could delete records they aren’t allowed to delete directly.

1aws bedrock-agentcore-control create-memory \
2  --name "SupportAgentFactMemory" \
3  --event-expiry-duration 90 \
4  --memory-strategies '[{"semanticMemoryStrategy": {
5      "name": "FactExtractor",
6      "namespaceTemplates": ["/support_cases/{sessionId}/facts/"],
7      "recordExpirySpecification": {"recordExpiryDurationDays": 60}}}]'

A TTL deletes records by age, not by whether they’re still true or used. For memory that should fade by relevance instead, see AI memory decay.

What’s new in AgentCore Memory (October and November 2026)

Five additions landed in the developer guide after the TTL release. None changed the pricing table below; all were read in the docs on 8 November 2026.

The harness turns memory on by default

The AgentCore harness (GA, documented alongside the AgentCore CLI 1.0 release of 28 October 2026) is AWS’s managed agent loop: you declare model, tools, skills and instructions, and AWS runs the compute, filesystem, identity and memory. The memory part is this service:

• Managed memory is the default. Creating a harness without a memory configuration provisions an AgentCore Memory resource for it. The CLI does the same unless you pass --memory with mode disabled or existing. The strategy names are SEMANTIC, SUMMARIZATION, USER_PREFERENCE and EPISODIC, set with eventExpiryDuration for the raw events; you change them later through UpdateHarness, and can still read and write events and records through the Memory APIs directly.
• Bring your own memory when you need custom namespace templates or one memory shared by several harnesses: attach an existing resource by ARN, or by name if the same project declares it. Only the by-name form accepts a retrievalConfig and survives agentcore export harness.
• Retrieval is automatic. With active strategies, the harness queries long-term memory on every invocation with topK=10 and relevanceScore=0.2 per strategy namespace and injects the results before the model reasons. Pass your own retrievalConfig to change topK, the score threshold or the namespaces, or to skip a strategy. If you add or remove strategies on a BYO memory, call UpdateHarness or the retrieval configuration goes stale.
• Per-user scoping comes from the actorId you pass at invoke time; each actor gets isolated short-term and long-term memory.
• Context truncation is separate from memory: sliding_window (default, keeps the last N messages), summarization (compresses older turns) or none.
• Cost. The harness itself is free; managed memory bills at the standard AgentCore Memory rates below for events, stored records and retrievals. AWS’s own advice: “To avoid persistent Memory charges, disable Memory when you create the harness.”

1agentcore add harness --name Support \
2  --memory '{"mode":"managed","strategies":["SEMANTIC","SUMMARIZATION"],"eventExpiryDuration":30}'
3# or, no memory at all:
4agentcore add harness --name Support --memory '{"mode":"disabled"}'

Streaming, metadata and the other operational additions

• Record streaming fires on extraction from events, direct BatchCreateMemoryRecords, BatchUpdateMemoryRecords, explicit deletes and, notably, on consolidation: when the pipeline de-duplicates or supersedes a record, you get a MemoryRecordDeleted event. Choose METADATA_ONLY (ids and timestamps) or FULL_CONTENT (adds memoryRecordText) per stream; deletion events carry only the ids either way. The memory needs a memoryExecutionRoleArn that can write to your stream, and a StreamingEnabled test event confirms the setup.
• Metadata filtering adds structured attributes inside a namespace. You declare up to 10 indexed keys per memory (STRING, STRINGLIST or NUMBER); a key can’t be removed once added, and existing records aren’t backfilled. A query combines up to 5 filters with AND, using EQUALS_TO, CONTAINS, numeric comparisons, and BEFORE / AFTER on the system timestamps x-amz-agentcore-memory-createdAt and updatedAt, which need no indexed key. Each strategy can carry a metadata schema that tells the LLM what to extract from the conversation (for example sentiment, or an escalated priority, with allowed values capped at 10). Keys marked STRICTLY_CONSISTENT are copied from the event without LLM inference, and they also partition extraction and consolidation: a record tagged compliance_level: hipaa never merges with one tagged standard. Changing which keys are strict isolates old records from new ones, so AWS says to plan this before ingesting, and to start with 3 to 5 keys.
• Cross-account access attaches a resource-based policy to the memory with PutResourcePolicy, so a role in another account can call BatchCreateMemoryRecords, RetrieveMemoryRecords and the other data-plane actions by passing the full memory ARN as the memory id. Self-managed strategy and streaming destinations in another account need the execution role plus bucket, topic or stream policies on the other side.
• Redrive covers the case where extraction from events to records fails. For built-in strategies AWS says “the only failure scenario is hitting the ingestion limit”; overrides add model and permission failures. Watch the FailedExtraction CloudWatch metric, list the failed jobs, fix the reason, then re-run each job by id.

What this adds up to: AgentCore Memory now has the operational surface of a database (change feed, typed filters, cross-account IAM, dead-letter redrive) on top of the extraction pipeline. The open-source equivalents are partial. Hindsight has no change stream; its data-movement path is a bank export to a transfer ZIP that another Hindsight instance restores or merges, in its own format rather than a cross-vendor one. It scopes memory with isolated banks and a retrieval token budget rather than per-record indexed keys. If you need Kinesis-style events on every memory change today, AgentCore is the one that ships them.

Using AgentCore Memory from Python

AWS’s getting-started guide creates the memory resource with the AgentCore CLI (agentcore add memory --strategies SEMANTIC then agentcore deploy) and uses the bedrock-agentcore Python SDK for events. You can also create it with boto3:

 1import boto3
 2from bedrock_agentcore.memory import MemorySessionManager
 3from bedrock_agentcore.memory.constants import ConversationalMessage, MessageRole
 4
 5control = boto3.client("bedrock-agentcore-control", region_name="us-west-2")
 6
 7# Create a memory resource with one semantic strategy (takes a few minutes)
 8memory = control.create_memory(
 9    name="SupportMemory",
10    eventExpiryDuration=30,  # days to keep raw events (3-365)
11    memoryStrategies=[{
12        "semanticMemoryStrategy": {
13            "name": "facts",
14            "namespaceTemplates": ["/facts/{actorId}/"],
15        }
16    }],
17)["memory"]
18
19# Write conversation turns as events (short-term memory)
20manager = MemorySessionManager(memory_id=memory["id"], region_name="us-west-2")
21session = manager.create_memory_session(actor_id="user-123", session_id="order-42")
22session.add_turns([
23    ConversationalMessage("My order #35476 hasn't arrived.", MessageRole.USER),
24    ConversationalMessage("Sorry to hear that. Let me check.", MessageRole.ASSISTANT),
25])
26
27# Later, in any session: search extracted long-term records
28records = session.search_long_term_memories(
29    query="open support issues", namespace_path="/facts/user-123/", top_k=3
30)
31for record in records:
32    print(record)

Extraction is asynchronous, so records show up some time after the events. For Strands agents, the SDK ships an AgentCoreMemorySessionManager that loads history and retrieves records per namespace automatically.

AgentCore Memory pricing (checked November 2026)

Short-term events are billed with a 12 KB minimum and 64 KB maximum per event, so lots of tiny events cost more than their raw size suggests. A rough example: 10,000 users with 50 built-in records each is 500,000 records, or $375 a month in storage. Every 100,000 retrieval calls add $50. There’s no memory-specific free tier on the pricing page.

LLM memory on AWS: the options

If you searched for “LLM memory on AWS,” these are the realistic routes:

The Bedrock Agents memory docs now point new users to AgentCore. For self-hosting, Mem0, Graphiti, Cognee, Letta and Hindsight all run in containers and can use Bedrock models; the open-source memory systems comparison lists licenses and storage backends.

Of these, Hindsight covers the most of what AgentCore’s strategies do, in open source. Its retain extracts facts, entities and time from each conversation, background consolidation turns them into observations (beliefs with the quotes behind them, refined as evidence arrives), and reflect reasons across memories, much like AgentCore’s episodic reflections. It’s MIT-licensed with every feature in the open-source server, deploys to EKS with its Helm chart, uses Bedrock as its LLM provider, and has an integration for AWS’s Strands Agents. You pay for your database and model calls instead of per stored record. The trade-offs: you run and back it up yourself, and every write calls a model. See what Hindsight is.

How AgentCore compares with Azure and Google

All three clouds now sell a managed memory layer with the same basic loop: write conversation data, let an LLM extract and merge facts, retrieve per user. The differences are in the knobs.

• AgentCore gives the most control over extraction, from built-ins to fully self-managed pipelines, and is the only one with an episodic strategy that reflects across episodes.
• Azure AI Foundry long-term memory has user profile, chat summary and procedural memory, partitioned by scope, and was still in preview in October 2026.
• Vertex AI Agent Engine Memory Bank uses topics and structured profiles, keeps revision history, and integrates natively with Google ADK.

Pick the one in the cloud you already run on. Memory data, IAM and model access are much simpler when they sit next to your agent.