Agent memory is often described as if an LLM naturally remembers everything. In practice, a memory service stores events and derives material that can later be retrieved. Amazon Bedrock AgentCore Memory separates short-term conversation history from long-term extracted records. That separation changes accuracy, privacy and deletion requirements: a temporary conversation turn should not automatically become a permanent fact about a person.
How the architecture works
In AWS documentation, short-term memory stores events from a session and long-term memory can extract summaries, facts or preferences across sessions. Applications may submit events and retrieve long-term records. Memory is different from a curated retrieval index: a RAG index represents documents with a known document owner, while memory can represent past interactions and inferred preferences. Design the provenance and retention policy for both separately.
A controlled, practical example
Imagine a technical support agent that remembers a customer prefers email responses. Store only an explicitly stated communication preference with source event, timestamp and expiry policy. Do not turn an offhand comment about a temporary computer problem into a permanent hardware attribute. When the customer corrects their preference, write a fresh authoritative record and make old derived memory ineligible for retrieval. A user query should still be answered from current ticket data rather than relying on a past memory.
Permissions, approvals and trust boundaries
Before enabling memory, define an actor ID that cannot accidentally collide across tenants. Enforce read and delete permissions at the memory API, protect sensitive events in storage and logs, and establish a process to revoke derived records when source information is deleted. A model’s instruction to save a memory must not supersede privacy policy. Keep irreversible account changes outside memory operations; history is context, not a transaction ledger.
Limits and version caveats
Asynchronous long-term extraction can be delayed, inaccurate or inconsistent with a corrected source. Semantic retrieval returns potentially relevant records, not guaranteed true records. AWS documentation establishes short- and long-term concepts, not a universally applicable retention period or exact cost for every deployment. Regional scope, default memory strategies and live runtime behavior should be separately checked at configuration time.
Where it fits and what to use instead
Use short-term state for ongoing conversation continuity and long-term memory only when a clearly useful, consented attribute is expected to remain valid. Prefer RAG for organizational policy documents with governed edits and citations. Prefer ordinary relational storage for authoritative customer fields. Some assistants need no persistent memory beyond an incident or session, and eliminating it may be the safer design.
How to validate before deployment
Test user A/user B separation, stale preferences, withdrawn consent and deletion after derived summarization. Check that an erased event no longer influences replies through long-term records or cached retrieval. Measure correction responsiveness and inappropriate memory mentions, not just recall rate. Include forced worker restart and repeated event submission to verify continuity without duplicate entries.
Version, tier and region applicability
The source links below describe specific capabilities or dated announcements; documentation may change afterward. Where no exact release version, eligible market, service region, contract plan or numeric quota is substantiated, those facts are unknown and are not inferred. This article is a researched implementation guide, not a record of hands-on testing, a license grant, a benchmark, or a current price quote. Independently recheck current product access and commercial terms before deployment.