Bedrock AgentCore Memory: Add an Auditable Knowledge Layer

Amazon Bedrock AgentCore Memory solves a real production problem: an agent process can end without losing its conversation state or useful knowledge. It stores raw interactions as short-term events and can asynchronously extract summaries, preferences, facts, and episodes for long-term retrieval. For an AWS-native support or personalization agent, that removes substantial infrastructure work.

But conversational recall and project knowledge are different assets. A deployment decision, runbook, API contract, or corrected architecture fact should not exist only as an extracted record returned by semantic search. It should also be a file people can review, edit, diff, and self-host. The practical design is a two-plane memory system: AgentCore for managed behavioral recall, plus readable Markdown for authoritative project knowledge.

How Bedrock AgentCore Memory works

AgentCore identifies three important scopes. A memory_id names the memory resource, an actor_id identifies a user or agent, and a session_id groups one conversation. Calls to CreateEvent persist messages as short-term memory. Long-term memory requires at least one strategy; AWS currently documents semantic, user-preference, summary, and episodic strategies.

Extraction runs asynchronously. The service extracts information from events, consolidates it into records, and exposes those records through list, get, and semantic retrieval operations. Namespaces such as /users/{actorId}/facts separate records by purpose and actor. Raw-event retention can be configured up to 365 days; changing that setting affects new events rather than extending old ones.

A minimal deployment follows the official CLI workflow:

python -m venv .venv
source .venv/bin/activate
pip install bedrock-agentcore-starter-toolkit bedrock-agentcore

agentcore add memory --name SupportMemory --strategies SEMANTIC,SUMMARIZATION
agentcore deploy

Run those commands inside an initialized AgentCore project with AWS credentials and a configured region. The deployed agent receives the generated memory resource ID through its environment. Your application must keep actor IDs tenant-safe and reuse a session ID only for the conversation whose events should be replayed.

What the current benchmarks actually say

AWS reports useful but workload-specific results. In its long-term-memory evaluation, semantic memory reached 70.58% correctness on LoCoMo with 89% compression, compared with 77.73% for a full-history RAG baseline. On LongMemEval-S, semantic memory reached 73.60% with 94% compression versus 75.2% for full history. Preference memory reached 79% on PrefEval versus 51% for the baseline, while summarization reached 83.02% on PolyBench-QA with 95% compression.

The honest conclusion is not “memory always improves accuracy.” Extraction trades some factual completeness for a much smaller context, while specialized preference memory can improve the task it was designed for. AWS also reports extraction and consolidation taking roughly 20–40 seconds and semantic retrieval around 200 ms in that evaluation. Design for eventual availability: never assume a fact written in the current turn has already appeared in long-term retrieval.

Pricing is similarly usage-shaped. AWS currently lists short-term events at $0.25 per 1,000, built-in long-term records at $0.75 per 1,000 stored per month, and retrieval at $0.50 per 1,000 calls. Model charges can apply when strategies run in your account. Recheck the official pricing page before estimating production cost.

The missing layer: authoritative project memory

The top AgentCore results explain resources, strategies, events, retrieval, retention, and SDK setup. They do not define which extracted memories are allowed to become a team's source of truth, how a reviewer corrects them in a normal code-review workflow, or how another non-AWS agent reconstructs the latest decision.

Add a promotion boundary:

1. Observe: write user interactions and tool outcomes to AgentCore events.
2. Retrieve: use long-term records for personalization, summaries, and similar-task hints.
3. Promote: when a fact becomes operationally authoritative, write a Markdown page with owner, scope, source, and review date.
4. Correct: edit the page rather than hoping a new embedding outranks an obsolete statement.
5. Expire: review or archive knowledge whose source or validity window has ended.

Meshnote is one implementation of that second plane: agents maintain linked Markdown wikis through MCP, while humans retain ordinary files. An AgentCore-based agent can use managed memory for conversation-derived context and call the same MCP knowledge tools as Claude Code, Cursor, or another client. That separation is also useful when designing persistent memory for LLM agents: retrieval is an index, not automatically the canonical record.

Run a five-case promotion audit

This test is the original element missing from the three leading setup pages. Run it before production with a disposable actor and project:

1. Send an event saying, “The payments service deploys to us-east-1.” Wait for extraction, then verify semantic retrieval returns it for that actor.
2. Promote the statement to architecture/payments.md, recording the event or ticket as its source and adding reviewed: 2026-09-18.
3. Send a correction: “Payments moved to us-west-2.” Confirm eventual AgentCore retrieval, then edit the Markdown page and verify its file history shows both versions.
4. Query with a different actor ID and a different project. Neither scope should reveal the original tenant's fact.
5. Disable long-term retrieval temporarily. A second MCP client should still recover the current region, source, and correction history from the files.

Fail the release if the old region is presented without qualification, isolation breaks, or the current decision cannot be reconstructed without the original agent runtime. This checks governance and portability rather than merely proving that semantic search returns something. For a broader test suite, see vector memory versus readable memory.

AgentCore, Mem0, Zep, Letta, or native memory?

Option	Best fit	Main trade-off
AgentCore Memory	AWS-native agents needing managed events, extraction, namespaces, and retrieval	Managed records are not the same as human-reviewable project files
Mem0	A memory layer with scoped add, search, update, delete, and hosted or open-source deployment choices	Your application must govern conflicts, scope, and canonical records
Zep / Graphiti	Changing relationships and point-in-time reasoning using a temporal knowledge graph	Graph operations are more infrastructure than many simple knowledge bases need
Letta	Stateful agents that manage always-visible blocks and searchable archival memory	The memory model is closely tied to the stateful agent runtime
ChatGPT or Claude native memory	Personal continuity with minimal setup	Limited application-level control and weaker cross-tool portability
Readable Markdown over MCP	Shared decisions, runbooks, provenance, review, and multi-agent handoff	Requires an explicit write policy and ongoing curation

These choices are complementary. Keep high-volume conversational events and extracted preferences in the system optimized for them. Keep decisions that must survive vendors, agents, and embeddings in a readable source of truth. The self-hosted agent memory guide covers the operational trade-offs in more depth.

A production boundary that stays understandable

Use AgentCore short-term memory for session continuity; use long-term strategies for compressed recall and personalization; use Markdown for approved project truth. Log the source identifier when promoting a record, and pass only the relevant page excerpt back into the model. Do not mirror every chat turn into the wiki or every document paragraph into behavioral memory.

This architecture costs more thought than connecting one store, but failures become diagnosable. You can inspect the event, the extracted result, the promoted file, and the prompt separately. You can also replace one retrieval system without rewriting the knowledge itself.

Start syncing — $8/mo, or choose Self-hosted for teams from $10/seat/month.

Related Reading

• Persistent Memory for LLM Agents: A Production Architecture
• Vector Memory vs Readable Memory
• Shared Memory Across AI Tools
• Self-Hosted Agent Memory