---
title: 7 AI Agent Memory Types Mapped to AWS, with AgentCore Memory Benchmarked (2026)
description: On 25 October 2026 we benchmarked AgentCore Memory in us-east-1. Semantic and preference records became retrievable in about 82 seconds, episodic records in about 16 minutes, and 9 of 9 planted facts came back top-3. Here is where all seven agent memory types live on AWS.
url: https://www.factualminds.com/blog/ai-agent-memory-types-aws-agentcore-2026/
datePublished: 2026-10-25T00:00:00.000Z
dateModified: 2026-10-25T00:00:00.000Z
author: palaniappan-p
category: AI Agents
tags: ai-agents, bedrock-agentcore, amazon-bedrock, agent-memory, eventbridge
---

# 7 AI Agent Memory Types Mapped to AWS, with AgentCore Memory Benchmarked (2026)

> On 25 October 2026 we benchmarked AgentCore Memory in us-east-1. Semantic and preference records became retrievable in about 82 seconds, episodic records in about 16 minutes, and 9 of 9 planted facts came back top-3. Here is where all seven agent memory types live on AWS.

import { Image } from 'astro:assets';
import mapDiagram from '~/assets/images/blog/ai-agent-memory-types-aws-agentcore-2026-map.webp';
import lifecycleDiagram from '~/assets/images/blog/ai-agent-memory-types-aws-agentcore-2026-lifecycle.webp';

Picture a platform lead telling an internal AWS assistant on Monday that production runs in us-east-1 and everything ships through Terraform. On Thursday, in a new chat, the assistant offers a console walkthrough for eu-central-1. Nothing broke in the model. The facts lived only in Monday's context window, and that window closed when the session ended.

The "seven types of agent memory" list (working, semantic, episodic, procedural, retrieval, parametric, prospective) is a popular way to explain agent memory, and the definitions are fine. What the list doesn't tell you is where each type lives on AWS, what it costs in latency, and when to leave it out. On **October 25, 2026** we ran a small benchmark against Amazon Bedrock AgentCore Memory in us-east-1 to put numbers on the parts AWS manages for you. Semantic and preference records became retrievable about **82 seconds** after the conversation ended. Episodic records took about **16 minutes**. All **9 of 9** planted facts came back in the top 3 for a fresh session.

This post maps each memory type to a specific AWS service, gives the numbers we measured, and says when not to use each one. It is a first-party benchmark with synthetic fixture users. It is not a client engagement, and we don't claim production recall rates from 9 planted facts.

> **Reproduce this.** The script is in [`examples/architecture-blog-2026/agent-memory-types/`](https://www.factualminds.com/examples/architecture-blog-2026/agent-memory-types/README.md). Run `uv run --no-project --with "boto3>=1.43.118" python bench_memory.py --profile <profile> --region us-east-1`. It creates one Memory resource with four strategies, writes 18 events for three synthetic users, polls until long-term records appear, prints latency and recall JSON to `out/`, and deletes the resource. A run costs well under $1.

## The map: seven types, seven AWS homes

| Memory type | What it holds | AWS home | Lifetime | Skip it when |
| --- | --- | --- | --- | --- |
| **1. Working** | The current turn: messages, tool results, retrieved chunks | Model context window, reloaded from AgentCore Memory short-term events | One session (events expire after 3 to 365 days) | Never skip. Keep it small instead |
| **2. Semantic** | Durable facts and user preferences | AgentCore Memory semantic + user-preference strategies | Until TTL or delete | The fact already lives in a system of record the agent can query |
| **3. Episodic** | What happened in past sessions | AgentCore Memory summary + episodic strategies | Until TTL or delete | Sessions are one-shot, or history is already in a ticket system |
| **4. Procedural** | How to do a task | Skills and prompts you version in S3 or Bedrock Prompt Management; learned reflections from the episodic strategy | Until you change them | You can't review what the agent "learned" |
| **5. Retrieval** | Shared documents | Bedrock Knowledge Bases on S3 Vectors or OpenSearch | Until re-ingested | The corpus fits in a prompt |
| **6. Parametric** | General knowledge | Bedrock foundation model weights | Until the model version changes | You need it to be current, or to cite a source |
| **7. Prospective** | Tasks due later | EventBridge Scheduler targeting Step Functions or a Lambda that invokes the agent | Until the schedule fires | A human can own the follow-up in an existing queue |

<Image src={mapDiagram} alt="Architecture diagram: an agent loop on AgentCore Runtime writes events to AgentCore Memory short-term storage, which extracts asynchronously into long-term strategies; the agent also loads skills from S3, retrieves from Bedrock Knowledge Bases on S3 Vectors, invokes a Bedrock model, and is triggered by EventBridge Scheduler through Step Functions" />

## 1. Working memory: the context window, rebuilt every turn

Working memory is whatever is in the model's context window right now. It is the only memory the model actually reasons over. Every other type on this list is a store whose job is to put the right few hundred tokens into this window.

On AWS, the window itself belongs to the Bedrock model you invoke. Persisting it across turns is AgentCore Memory's **short-term memory**: you call `CreateEvent` for each user and assistant message, scoped by `actorId` and `sessionId`, and `ListEvents` to rebuild the session. Events expire after the `eventExpiryDuration` you set on the resource (3 to 365 days in the current API).

What we measured, us-east-1, three actors, 18 events:

| Call | p50 | p95 |
| --- | --- | --- |
| `CreateEvent` | 365 ms | 1,029 ms |
| `ListEvents` (full session reload) | 342 ms | 368 ms |

**When not to lean on it:** don't replay a whole long session into every prompt. In our run the average session-1 transcript was 331 characters, and the top-3 long-term records that answered the same questions were 967 characters. That is the opposite of what most diagrams promise: for short sessions, retrieved memory was about three times larger than the transcript it came from, because records are rewritten as full sentences and preferences come back as JSON with context and categories. Retrieval pays off when sessions are long and only a few facts matter, so measure both sizes before you assume memory saves tokens. Working memory is the most expensive place to keep anything, because you pay for it in input tokens on every turn.

## 2. Semantic memory: facts and preferences across sessions

Semantic memory is what the agent knows about this user or account that should outlive the session: "production is us-east-1", "prefers CLI over console steps". AgentCore Memory provides it through two built-in long-term strategies:

- **`semanticMemoryStrategy`** extracts facts from conversation events.
- **`userPreferenceMemoryStrategy`** extracts preferences and styles.

Both write records into namespaces you template with `{actorId}`, so retrieval for one user never searches another user's records. AWS documents that the built-in strategies skip personally identifiable information by default.

Extraction is **asynchronous**. Records are not there the moment the user says something. In our run the first semantic and user-preference records appeared about 82 seconds after the last event was written. A fact stated two turns ago in the same session is not in long-term memory yet, so it has to stay in working memory.

The two strategies also overlap. The semantic strategy stored "The user prefers short answers with CLI commands instead of console steps", which is a preference. The preference strategy stored "Production workloads run in us-east-1 and eu-west-1 is used for DR", which is a fact. Retrieve from both namespaces and de-duplicate, or pick one strategy per kind of record with a custom strategy.

Recall on the planted facts: **9 of 9** questions returned a record containing the expected answer in the top 3. `RetrieveMemoryRecords` latency was **534 ms p50 and 620 ms p95** over 30 calls.

**When not to use it:** if the fact already lives in a CRM, an account database, or a CMDB the agent can query with a tool, query the tool. A memory record is a copy, and copies go stale. Our [eCommerce memory post](https://www.factualminds.com/blog/ai-agent-memory-ecommerce-2026/) walks through that failure in detail: the shopper changes their address in the account UI, and the agent quotes the old one from Memory.

## 3. Episodic memory: what happened last time

Episodic memory records past interactions and their outcomes, so the agent can say "last time this deployment failed on the IAM role, and we fixed it by adding `iam:PassRole`". AgentCore offers two strategies for it:

- **`summaryMemoryStrategy`** keeps a running summary per session.
- **`episodicMemoryStrategy`** detects when an episode is complete, then consolidates it into a structured record: situation, intent, assessment, justification, and an episode-level reflection.

This is the slow one. In our run the summary record appeared after about 82 seconds, but the first episode took **992 seconds (about 16.5 minutes)** after the last event, and the first reflection took 945 seconds. We sent no end-of-session signal; the strategy decided on its own that the episode was over. If your product promises "the agent remembers what we just did", the summary strategy or working memory has to cover the first quarter hour.

**When not to use it:** for one-shot agents (classify this ticket, draft this reply) there is no "last time" worth recalling. And if the history already lives in Jira, ServiceNow, or your ticketing system, a tool that reads the ticket is more accurate than a model-written summary of it.

## 4. Procedural memory: how to do the task

Procedural memory is the agent's know-how: the steps, rules, and tool order for a job. On AWS it has two very different sources, and we treat them differently.

**Procedures you write.** System prompts, Agent Skills, runbooks. Version them like code, in S3 or Bedrock Prompt Management, and review them like code. Our [MCP vs Agent Skills benchmark](https://www.factualminds.com/blog/mcp-vs-agent-skills-strands-bedrock-2026/) showed what a written procedure does: on the same refund job, MCP tools alone passed 0 of 30 and a Skill alone passed 0 of 30. With the Skill holding the refund policy alongside the tools, it passed 30 of 30.

**Procedures the agent learns.** The episodic strategy can generate **reflections**: insights drawn across episodes, such as "when the user asks about costs, query Cost Explorer first". These land in a namespace under the episodic one. That isn't just convention; the API enforces it:

> **What broke.** First run, October 25, 2026. We put reflections at `/reflections/{actorId}/` and `CreateMemory` failed with `Reflection namespace '/reflections/{actorId}/' must be the same as or a hierarchical prefix of the episodic namespace`. We fixed it by moving reflections to `/episodes/{actorId}/`, a prefix of the episode path `/episodes/{actorId}/{sessionId}/`. The run before that failed earlier still: a mid-2026 botocore rejected `namespaceTemplates` as an unknown parameter. Pin boto3 1.43.118 or newer.

**Our recommendation:** let written procedures govern and treat reflections as suggestions. A reflection is model-generated text about what worked before. Read reflections in a weekly review, and promote the good ones into a versioned skill. Don't let a reflection silently change how an agent handles money, access, or customer data.

## 5. Retrieval memory: documents the agent searches

Retrieval memory is external knowledge the agent searches at run time: runbooks, product docs, policies. On AWS that's a **Bedrock Knowledge Base** backed by S3 Vectors (cheapest at rest) or OpenSearch Serverless (lowest query latency).

The difference from semantic memory is scope. Semantic memory is per actor and extracted from conversations. Retrieval memory is shared across users and ingested from documents you control. Mixing them is a common mistake: a user's preference doesn't belong in a shared knowledge base, and a 40-page runbook doesn't belong in a per-user memory namespace.

See [how to build a RAG pipeline with Bedrock Knowledge Bases](https://www.factualminds.com/blog/how-to-build-rag-pipeline-amazon-bedrock-knowledge-bases/) and AgentCore with S3 Vectors for the build.

**When not to use it:** if the whole corpus is a few thousand tokens, put it in the prompt or a skill and skip the vector store.

## 6. Parametric memory: what the model already knows

Parametric memory is knowledge baked into the model weights during training: what an S3 bucket policy is, how Terraform state works. You get it free with every Bedrock model call, and you can't edit it without customizing the model.

Two limits matter in practice. It has a cutoff date, so it doesn't know about launches after training. And it can't cite where an answer came from. For anything that changes (prices, quotas, your own architecture) pull from retrieval or a tool instead.

**When not to use fine-tuning as memory:** almost always. Fine-tuning teaches format and style well, and facts poorly. Our [fine-tuning vs RAG guide](https://www.factualminds.com/blog/fine-tuning-vs-rag-bedrock-when-to-use/) covers the cases where it does pay off.

## 7. Prospective memory: what the agent must do later

Prospective memory is a commitment to act in the future: "check whether the Savings Plan recommendation changed next Monday", "follow up if the ticket is still open in 48 hours". No language model remembers to do something later. Something outside the model has to wake it up.

AgentCore Memory doesn't schedule anything. On AWS, the clean pattern is:

1. The agent calls a `schedule_followup` tool that creates a one-time **EventBridge Scheduler** schedule with an `at(...)` expression and `ActionAfterCompletion: DELETE`.
2. The schedule targets a **Step Functions** state machine (or a Lambda function) that invokes the agent on AgentCore Runtime with the original `actorId` and a payload describing the task.
3. The woken agent **re-checks current state** before acting. The ticket may have closed, and the price may have changed.

Our event-triggered AgentCore post has the wiring for the EventBridge side.

**When not to build it:** if a person already owns follow-ups in a queue (a CRM task or a Jira due date), have the agent create that task instead. A reminder a human can see and cancel beats one only the agent knows about.

<Image src={lifecycleDiagram} alt="Lifecycle diagram: in session 1 the user's messages become short-term events, strategies extract them asynchronously into long-term records in actor namespaces, and in session 2 RetrieveMemoryRecords injects the top 3 records into the prompt; EventBridge Scheduler can also invoke the agent later" />

## The benchmark in one table

Run on October 25, 2026, in us-east-1, with boto3 1.43.118. Three synthetic actors each stated two facts and one preference in session 1, giving 18 events in total. The raw JSON is in the artifact folder.

| Measurement | Result |
| --- | --- |
| `CreateMemory` to `ACTIVE` | 151 s |
| `CreateEvent` latency (n=18) | p50 365 ms, p95 1,029 ms |
| `ListEvents` session reload (n=30) | p50 342 ms, p95 368 ms |
| First semantic record | 81.5 s after last event |
| First user-preference record | 81.9 s |
| First summary record | 82.3 s |
| First reflection | 944.8 s |
| First episode | 991.5 s |
| `RetrieveMemoryRecords` (n=30, topK 3) | p50 534 ms, p95 620 ms |
| Planted-fact recall, top 3, fresh session | 9 of 9 |
| Avg session-1 transcript vs. retrieved records | 331 vs. 967 characters |

What these numbers don't tell you: recall on 9 short, cleanly stated facts is an easy test. Real conversations bury facts in noise and contradict themselves. Treat our recall figure as a smoke test that the wiring works, not as a quality score.

## What we'd build first

For most teams shipping their first production agent on AWS, start with four types and add the rest when a specific failure asks for them:

1. **Working memory** with a hard budget: the last N turns plus retrieved records, never the full transcript.
2. **Semantic + preference strategies** with an `{actorId}` namespace and a record TTL (`recordExpirySpecification`).
3. **Written procedural memory**: skills and prompts in version control.
4. **Retrieval** over the documents the agent must cite.

Add **episodic** when users come back to multi-session work, such as investigations, deployments, or case handling. Add **prospective** when the agent makes promises about the future. Leave **parametric customization** for last.

The trade-off: each long-term strategy you enable adds extraction model calls, stored records, and retrievals to the bill, plus one more place a stale or wrong fact can come from. The [AgentCore pricing breakdown](https://www.factualminds.com/blog/amazon-bedrock-agentcore-pricing-12-components/) shows how long-term Memory compounds without a TTL.

## What to do this week

1. Write down every piece of state your agent carries today and tag it with one of the seven types. Anything tagged "working" that must survive the session is a bug.
2. Run the [benchmark script](https://www.factualminds.com/examples/architecture-blog-2026/agent-memory-types/README.md) in your own region to get your extraction delay. Design the next-turn behavior around that number.
3. Set `recordExpirySpecification` on every long-term strategy before launch, not after the first bill.
4. Move any procedure that lives only in a reflection or a chat log into a versioned skill.
5. For every "remind me" feature, decide who owns it: EventBridge Scheduler or a human queue.

## What this post doesn't cover

- **Custom memory strategies** (your own extraction prompt and model). We only measured the built-in ones.
- **Recall at scale.** Nine planted facts across three synthetic users is a wiring test. We haven't measured recall over thousands of messy, real sessions.
- **Self-managed memory** on DynamoDB or Aurora with pgvector. That is a valid choice when you need full control over extraction. It isn't benchmarked here.
- **Multi-agent memory sharing**, where one agent reads another agent's namespace. That needs its own access model.
- **eCommerce data ownership** (Memory vs CRM vs OMS). See the [eCommerce memory layering post](https://www.factualminds.com/blog/ai-agent-memory-ecommerce-2026/).

## FAQ

### Which AWS service implements each of the seven agent memory types?

Working memory is the Bedrock model context window, persisted per session as AgentCore Memory short-term events. Semantic memory is the AgentCore semantic and user-preference strategies. Episodic memory is the summary and episodic strategies. Procedural memory is skills and prompts you version in S3 or Bedrock Prompt Management, plus reflections from the episodic strategy. Retrieval memory is Bedrock Knowledge Bases on S3 Vectors or OpenSearch. Parametric memory is the model weights. Prospective memory is EventBridge Scheduler invoking the agent through Step Functions or Lambda.

### How long does AgentCore Memory take to make a new fact retrievable?

In our run, semantic, user-preference, and summary records first became listable about 82 seconds after the last event was written. Episodic records and reflections took about 16 minutes (945 to 992 seconds), because the episodic strategy waits until it judges an episode complete. Design the next turn around that gap: a fact stated in this session is not yet in long-term memory, so keep it in working memory until the session ends.

### When should we NOT enable long-term AgentCore Memory?

Skip it when the facts already live in a system of record the agent can query with a tool (CRM, CMDB, account database), when sessions are one-shot, or when you have not decided a record TTL and a deletion path. A memory record is a copy, and a stale copy produces confident wrong answers.

### What could go wrong if reflections are treated as procedures?

A reflection is model-written text about what worked before. If it silently changes how the agent handles refunds, access, or customer data, nobody reviewed that change. Read reflections in a weekly review and promote the good ones into a versioned skill. Written procedures should govern.

### Does AgentCore Memory handle reminders or scheduled follow-ups?

No. Memory stores and retrieves; it does not wake the agent up. Use an EventBridge Scheduler one-time schedule that targets Step Functions or a Lambda function, which invokes the agent with the original actorId. The woken agent should re-check current state before it acts.

### Is fine-tuning a good way to give an agent memory?

Rarely. Fine-tuning changes parametric memory: it teaches format and style well, and facts poorly, and it can't cite a source or be updated per user. Use semantic memory for per-user facts and a Knowledge Base for shared documents.

## How the agent memory layer stays bounded

Pick which memory store each kind of agent state belongs in: context window, AgentCore Memory, S3 skills, Knowledge Bases, model, or scheduler.

- **Maturity:** Level 2 — reference architecture
- **Risk:** medium
- **Oversight:** monitored
- **Starts when:** An agent must recall a user fact, a past episode, or a task that is due later.
- **Tools:** Reads only, through named tools. No shell, no unrestricted SQL, and no undeclared API.
- **Stops for a person:** Memory writes carry no authority. A remembered preference never approves an action, and scheduled tasks re-check state before they act.
- **Checked by:** Facts retrieved from Memory lose to a newer record in the system of record. Retrieval is scoped by actorId namespace.
- **Untrusted data:** User text that tries to plant a durable instruction or preference for another actor.
- **If it fails:** If the agent memory layer stops, name the reason: completed, budget_exceeded, timed_out, cancelled, guardrail_blocked, approval_required, tool_failure, verification_failed, or partial_completion. Retry a timeout at most twice. Back off on rate limits. After repeated verification failure, escalate. Stop when the budget is exhausted or a permission is denied. No unbounded loop. Memory writes carry no authority. A remembered preference never approves an action, and scheduled tasks re-check state before they act.
- **Lifecycle:** Explore, then act, then confirm, then verify. Explore gathers the context for the agent memory layer. Act stays reversible. Confirm stops before an irreversible step. Verify is a separate check of the outcome.

Reference architecture, not a published production deployment. The shared contract is the [AWS store-agent architecture](https://www.factualminds.com/blog/aws-ai-agents-for-ecommerce-factualminds-2026/#operating-contract).

## FAQ

### Which AWS service implements each of the seven agent memory types?
Working memory is the Bedrock model context window, persisted per session as AgentCore Memory short-term events. Semantic memory is the AgentCore semantic and user-preference strategies. Episodic memory is the summary and episodic strategies. Procedural memory is skills and prompts you version in S3 or Bedrock Prompt Management, plus reflections from the episodic strategy. Retrieval memory is Bedrock Knowledge Bases on S3 Vectors or OpenSearch. Parametric memory is the model weights. Prospective memory is EventBridge Scheduler invoking the agent through Step Functions or Lambda.

### How long does AgentCore Memory take to make a new fact retrievable?
In our run, semantic, user-preference, and summary records first became listable about 82 seconds after the last event was written. Episodic records and reflections took about 16 minutes (945 to 992 seconds), because the episodic strategy waits until it judges an episode complete. Design the next turn around that gap: a fact stated in this session is not yet in long-term memory, so keep it in working memory until the session ends.

### When should we NOT enable long-term AgentCore Memory?
Skip it when the facts already live in a system of record the agent can query with a tool (CRM, CMDB, account database), when sessions are one-shot, or when you have not decided a record TTL and a deletion path. A memory record is a copy, and a stale copy produces confident wrong answers.

### What could go wrong if reflections are treated as procedures?
A reflection is model-written text about what worked before. If it silently changes how the agent handles refunds, access, or customer data, nobody reviewed that change. Read reflections in a weekly review and promote the good ones into a versioned skill. Written procedures should govern.

### Does AgentCore Memory handle reminders or scheduled follow-ups?
No. Memory stores and retrieves; it does not wake the agent up. Use an EventBridge Scheduler one-time schedule that targets Step Functions or a Lambda function, which invokes the agent with the original actorId. The woken agent should re-check current state before it acts.

### Is fine-tuning a good way to give an agent memory?
Rarely. Fine-tuning changes parametric memory: it teaches format and style well, and facts poorly, and it can't cite a source or be updated per user. Use semantic memory for per-user facts and a Knowledge Base for shared documents.

---

*Source: https://www.factualminds.com/blog/ai-agent-memory-types-aws-agentcore-2026/*