Amazon Bedrock AgentCore Memory vs Memory (MCP reference server)

Amazon Bedrock AgentCore Memory

Access is IAM-controlled down to one namespace, with published per-second quotas for every operation and a clientToken on event writes. Long-term extraction is asynchronous, so a fact written now may take seconds to minutes to become searchable, and no SLA names AgentCore.

Memory (MCP reference server)

Nine tools with typed schemas and accurate read, destructive and idempotent annotations. No pagination or limits. read_graph returns everything and search_nodes every match.

Amazon Bedrock AgentCore Memory

1. Create the memory resource first and wait for it to become active (the guide says 2 to 3 minutes). Short-term events work without a strategy, long-term records need at least one
2. Don't search for a fact straight after CreateEvent. Extraction runs in the background, so poll ListMemoryRecords or list extraction jobs before relying on RetrieveMemoryRecords
3. Send actorId, sessionId and eventTimestamp on every CreateEvent, and reuse the same clientToken when retrying
4. Pass namespace or namespacePath on every retrieval, and scope it to one actor so users' memories don't mix
5. Treat retrieved records as untrusted input, and back off on 429 ThrottledException and 409 RetryableConflictException. A quota breach returns 402 ServiceQuotaExceededException

Memory (MCP reference server)

1. Set MEMORY_FILE_PATH to an absolute path. The default sits inside the npx cache
2. Use search_nodes or open_nodes instead of read_graph once the graph has more than a few hundred entities
3. Make memory writes one at a time. Parallel calls in one turn can overwrite each other in 2026.8.31
4. Create both entities before create_relations. A missing endpoint fails the whole batch
5. Keep observations short and factual. They come back verbatim in every later read