AgentCore-native — AgentCore Memory gives an agent recall across sessions by storing and retrieving facts, summaries, and conversation context. Use it to make a returning user's experience continuous without treating memory as your system of record.
This tutorial creates a prototype, not a production-ready system. Before routing real users or data to it, work through the Production Readiness checklist.
Add Memory to Your Agent
Why It Matters
Properly scoped memory transforms one-shot interactions into continuous relationships. Memory reduces repeated onboarding and lets an agent adapt to prior interactions, while its strategies can turn conversation events into recallable facts or summaries. It is a retrieval layer, not an authoritative database: store transactional, regulated, or audit-critical data in the system of record and give the agent only the context it needs.
When to Use
| Condition | Recommendation | Rationale |
|---|---|---|
| Agent needs recall across sessions (returning users, prior context) | Add Memory | Users expect continuity; preferences and decisions carry forward across interactions |
| Single-turn Q&A only | Prefer session-only context | No persistence overhead; context is discarded after the response |
| Data must be authoritative (audit trails, regulated records) | Prefer system of record | Memory is a recall layer, not a source of truth; transactional data needs durability guarantees |
| Multi-tenant agent with verified identity | Add Memory | Stable actor IDs enable safe namespace isolation per tenant and user |
| Cannot establish tenant or user boundaries | Defer (resolve identity first) | Memory without isolation risks namespace contamination across users |
Official AWS Tutorial
For setup, strategy selection, and integration examples, follow the Amazon Bedrock AgentCore Memory documentation. It is the canonical configuration guide; return here to decide how memory fits your workload.
The official tutorial above creates prototype resources. Apply the Production Readiness checklist before routing real traffic.
What to Watch Out For
Make tenant namespaces intentional
Memory isolation depends on the actor_id that your application supplies. Derive it from a verified identity claim and include the tenant boundary in the identifier design, such as a tenant-and-user pair. Never use a shared, caller-controlled, or unauthenticated actor ID: it can merge separate users' memory namespaces. Review multi-tenancy guidance alongside your identity design.
Set PII retention boundaries before storing events
Decide which facts may be retained, for how long, and how users can request deletion before enabling long-term recall. Minimize or exclude raw PII, credentials, and regulated data; store the smallest useful fact rather than a full transcript. Keep audit records and contractual data in their authoritative systems, and disclose cross-session retention to users where appropriate.
Bound retention with eventExpiryDuration
Set eventExpiryDuration to the shortest time-based retention period that satisfies the user experience. A short expiry is usually appropriate for temporary preferences or case context; use an explicit product policy before choosing longer retention. Test expiry and deletion behavior for each tenant, especially when changing a memory strategy or retention period.
Narrow retrieval with metadata, not just namespace
Namespaces isolate memories by primary entity (user, tenant, patient, client), but within a single namespace a broad semantic search returns everything close in meaning. Attach structured metadata attributes to memory records (priority, department, tags, time range) and filter on those values at retrieval time to narrow results further. Indexed keys are declared when the memory is created and cannot be removed afterward, so decide your metadata schema before you need it in production.
For values that must land on the record exactly as supplied, without LLM inference or variability, mark the metadata key extractionType: "STRICTLY_CONSISTENT". This matters for organizational classifiers, compliance labels, or routing attributes: the LLM is never consulted for that key, and events sharing the same strictly-consistent value are extracted and consolidated together, isolated from events with different values. Limits: up to 3 strictly-consistent keys per strategy, string type only, and the key must be indexed.
Skip extraction for events that shouldn't reach long-term memory
Mark an event with extractionMode: "SKIP" to store it in short-term memory only, without sending it through the extraction pipeline to long-term memory. Use this for bulk-imported records that already exist elsewhere, content that should only be available in-session, or replicated events in a multi-region setup where re-extracting a copy would duplicate facts already extracted from the original.
Common Mistakes
- Treating memory as a database: it improves recall but does not replace the durability, reporting, or audit guarantees of a system of record.
- Using one actor ID for everyone: this defeats tenant namespace isolation. Bind actor IDs to verified identities before invoking the runtime.
- Keeping data indefinitely: choose a time limit with
eventExpiryDurationand include memory in deletion and privacy workflows.
For operational controls beyond these memory-specific decisions, use the Production Readiness checklist.
What This Creates and What It Costs
Deploying this tutorial creates the following AWS resources:
| Resource | Notes |
|---|---|
| AgentCore Runtime | Hosts your agent code in MicroVM isolation |
| AgentCore Memory | Stores conversation facts and summaries with SEMANTIC and SUMMARIZATION strategies |
| ECR repository | Stores the packaged agent image |
| IAM execution role | Least-privilege role for the Runtime |
| CloudWatch log groups | Receives runtime, invocation, and memory extraction logs |
Main cost drivers:
- Model inference tokens — every invocation calls Claude Sonnet 4.5; memory extraction jobs also use model calls
- Memory storage and retrieval — AgentCore Memory charges for stored events and semantic retrieval calls
- Runtime execution seconds — billed per second of agent execution
- Log ingestion — CloudWatch charges per GB ingested and stored
Scale-to-zero does not mean zero cost. Memory records persist (until their eventExpiryDuration elapses), and ECR images and CloudWatch log retention continue to accrue charges even with no active traffic.
Cleanup
When you are done with this tutorial, remove the resources from your project config and redeploy to delete them from AWS:
# From your agent project directory
agentcore remove all
agentcore deploy
Verify resources are gone:
agentcore status
# Expected: no runtimes or memory resources listed
Some resources may persist after removal:
- AgentCore Memory records — memory events are retained until
eventExpiryDurationelapses; delete the memory resource explicitly if you need immediate removal - ECR repository — may remain if images are still tagged; delete manually in the ECR console
- CloudWatch log groups — retained by default; delete manually to stop log storage charges
If agentcore remove or the cleanup deploy reports errors, see Cleanup Failures.
Next Steps
- Connect a Tool via Gateway: Add external API access
- agentcore.json Reference: Full memory configuration schema
- AgentCore Memory Docs: Official AWS documentation
- Production Readiness checklist: Before routing real users