AWS AgentCore Memory: how it works and when to use it

What is Amazon Bedrock AgentCore Memory?

AgentCore Memory is a fully managed service that gives Bedrock AgentCore agents short-term session context and extracted long-term knowledge. AWS describes the product as addressing agent statelessness without requiring teams to build and operate the memory infrastructure themselves.

The service is narrower than a complete customer data platform and broader than a message array. It stores raw interaction events, can apply memory strategies to extract durable insights and exposes operations for sessions, events, records and retrieval. The application still owns identity policy, product authorization, user experience and decisions about which remembered facts may influence an action.

What are the two AgentCore Memory types?

AgentCore separates short-term memory from long-term memory. Short-term memory stores raw event data for the current or previous sessions. Long-term memory stores structured insights extracted asynchronously from those events, such as summaries, facts, preferences or episodic records.

How does short-term memory work in AgentCore?

Each customer or agent interaction can be written as an event. Events are associated with a session ID and may include conversation turns, structured data and metadata. Operations such as CreateEvent, ListSessions, ListEvents and GetEvent retrieve the raw interactions needed to continue a session or inspect earlier context.

Event metadata can support filtering, but AWS warns that metadata is not encrypted with a customer-managed KMS key and is not intended for sensitive content. Store sensitive values inside the protected event payload or outside memory entirely.

• Use one stable session identifier for the current interaction.
• Keep event metadata to non-sensitive routing fields.
• Apply retention to raw events independently from extracted records.
• Do not treat a session ID as proof of user or tenant authorization.
• Retrieve only the history needed for the next action.

How does AgentCore create long-term memory?

Long-term generation is asynchronous. AgentCore extracts information from new events or directly ingested content, consolidates the new information with existing memory and stores the resulting memory records. Applications later list, retrieve or semantically search those records.

This decoupling protects the live interaction from extraction latency, but it creates eventual consistency. A fact written during the current turn may not be available from long-term retrieval immediately. Read-after-write behavior must therefore use the source event or application state rather than assume extraction has completed.

Which AgentCore Memory strategies should you enable?

A memory with no long-term strategy stores only short-term events. Adding a strategy tells AgentCore what kind of insight to extract. Current built-in options described by AWS include semantic, summarization, user preference and episodic strategies, with support for overrides and custom strategies.

Enable the smallest strategy set that supports a measured product behavior. More extraction increases write volume, retention obligations and evaluation work.

How do retention, namespaces and security work?

Raw event expiry is configured per memory and has a maximum of 365 days in the current AWS documentation. Long-term records can use a per-strategy time-to-live with a current minimum of 31 days, or remain without expiry if no TTL is configured. These are service settings, not a replacement for a product retention policy.

Use namespaces to separate the logical ownership model of extracted memory. Then enforce the authenticated tenant and user in the application before constructing a namespace or requesting retrieval. Consider a customer-managed KMS key for sensitive workloads and keep event metadata free of sensitive content.

• Document TTL separately for raw events and each long-term strategy.
• Treat service defaults as defaults, not legal retention decisions.
• Partition namespaces by the exact product and tenant boundary.
• Use customer-managed KMS where the security review requires it.
• Test deletion of records, events and any application-side caches.

How should you evaluate AgentCore Memory pricing?

Build a cost model from the service’s current usage dimensions rather than copying a headline price from an article. Include short-term event storage and operations, long-term extraction strategies, retained memory records, retrieval calls and any AWS infrastructure around the agent.

Measure the complete memory loop: write volume, extraction volume, number of retrievals per turn, context returned, token cost and successful task completion. Storage price alone is not memory cost because irrelevant retrieval can consume more model tokens than the memory saves.

What are the main AgentCore Memory tradeoffs?

The strongest advantage is integration: AWS-native IAM, KMS, observability, SDKs and the broader AgentCore runtime can reduce undifferentiated work for teams already standardized on Bedrock. The service is an AWS primitive, so neutrality across clouds and non-AWS agent platforms is a separate architectural concern.

How do you keep AgentCore Memory portable?

Keep a model-neutral memory contract in your application even if AgentCore is the first implementation. Use stable application identities and a memory type independent of AWS resource names. Store the source event and canonical fact outside the provider adapter when your policy requires an exportable customer record.

The adapter translates create, retrieve, correct and delete operations. The rest of the product should not depend directly on AgentCore session IDs, strategy names or resource ARNs. An export should preserve scope, provenance, validity and deletion status so it can be replayed into another memory service.

interface MemoryPort {
  remember(event: ScopedEvent): Promise<WriteResult>;
  recall(query: ScopedQuery): Promise<MemoryRecord[]>;
  correct(memoryId: string, patch: FactPatch): Promise<void>;
  forget(scope: MemoryScope): Promise<DeletionReceipt>;
}

class AgentCoreMemoryAdapter implements MemoryPort {
  // Map the stable contract to AWS session, event and memory-record APIs.
}

How should you test AgentCore Memory before production?

Run the same memory evaluation suite used for any other provider: current-fact recall, contradiction resolution, irrelevant recall, scope isolation, deletion, extraction latency and token cost. Add AWS-specific tests for strategy configuration, event expiry, long-term-record TTL, KMS policy and retry behavior.

Measure extraction delay explicitly. Verify how the agent behaves between the event write and the availability of the extracted long-term record. Then test source correction: updating a fact should not leave a stale semantic or summary record that continues to win retrieval.

• Verify the intended strategy extracted the expected memory type.
• Test the namespace boundary with two tenants and two users.
• Measure read-after-write behavior before long-term extraction completes.
• Change a fact and prove the current truth supersedes old records.
• Exercise raw-event and long-term-record expiry independently.
• Test deletion and export across the adapter and source storage.

When is AWS AgentCore Memory the right choice?

Choose AgentCore Memory when Bedrock and AWS-native operations are strategic, the team wants managed session events and extraction strategies, and the product can accept an AWS-centered architecture. Choose or add a model-neutral memory layer when multiple agent frameworks, clouds, regions or vendor exit paths are first-class requirements.