Amazon Bedrock AgentCore Memory vs Graphiti

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.

Graphiti

Apache-2.0, with FalkorDB, Neo4j or Amazon Neptune as the store. Every add runs LLM extraction, so ingestion costs tokens and time.

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

Graphiti

1. Set OPENAI_API_KEY (or another provider's key) and MODEL_NAME before starting the MCP server
2. Use search_memory_facts for facts and search_nodes for entities instead of reading whole episodes
3. Never call clear_graph to fix one fact. Use delete_episode or delete_entity_edge
4. Pass group_ids on every search and add so one user's graph doesn't leak into another's
5. Call get_status to check the database connection before a long ingest