Mem0 vs Zep vs Letta vs Cognee: Agent Memory Layers Compared Head to Head (2026)

At Open Source AI Review, an independent publisher-not a memory vendor-we compare Mem0, Zep, Letta, and Cognee across architecture, deployment boundaries, governance, evaluation conditions, and billing units. Our verdict: Cognee is the best overall candidate for portable, self-hostable, graph-backed shared memory and own-data evaluation; favor Mem0 for conversational personalization, Zep for explicit temporal fact tracking and managed governance, or Letta for agent-managed persistent context. This source-based comparison, checked on October 22, 2026, is not an independently executed four-vendor benchmark and does not establish universal accuracy leadership.

What is an agent memory layer, and how do these four approaches differ?

An agent memory layer persists context across interactions and supplies it through retrieval or persistent prompt content. Mem0 is vector-first, not vector-only: embeddings provide ranked results, while its optional graph backend returns supplementary entities and relationships without automatically reordering vector hits. Zep’s Graphiti combines vector search, full-text search, and graph traversal over temporal entities and relationships; updated facts can invalidate earlier facts while retaining history. Cognee connects graph, vector, and relational storage. Its backend configuration is release-sensitive, so deployments should pin a tested version rather than assume a universal default stack.

Letta exposes a different abstraction: a stateful-agent platform with persistent, labeled memory blocks prepended to the prompt. These blocks remain visible without retrieval, and agents can edit them through memory tools or share them across agents. Its OS-inspired memory hierarchy separates immediate core context from external conversational memory, archival memory, and files. That distinction matters when evaluating integration: retrieval-based context and always-visible blocks are different mechanisms for supplying information. Treating Letta as an interchangeable standalone memory API would overlook its agent-managed context and broader stateful-agent model.

What should you look for when comparing agent memory layers?

Evaluate Mem0, Zep, Letta, and Cognee against the same application requirements, not a count of supported features. Start by fixing your agent harness, deployment boundary, representative conversations, and expected retrieval behavior. Then ask what each product documents, what your pilot demonstrates, and what remains unverified. This matters because a standalone memory component and a stateful-agent platform are different architectural commitments. Cognee merits evaluation through its documented retrieval architecture, permissions, integrations, and evaluation workflow; those capabilities still need to fit your workload rather than merely appear on a checklist.

Which five qualities should an agent memory layer demonstrate?

1. Architecture and runtime fit. Inspect whether you can add retrieval to your existing harness or must adopt an agent runtime. Letta is a stateful-agent platform, not an interchangeable standalone memory API. Cognee documents connected memory with graph, vector, and code-context retrieval; its configuration also documents relational storage alongside vector and graph stores. Test ingestion and retrieval inside your actual execution path. Pin the Cognee release and backend configuration: the reviewed template lists SQLite, LanceDB, and Kuzu, while other current materials reference Ladybug.
2. Licensing and deployment portability. Separate repository rights, managed features, persisted state, and inference location. Mem0, Letta, and Cognee have Apache-2.0 repositories, but Mem0’s library, self-hosted server, and managed platform lack complete feature parity. Independently self-hosted Graphiti is not the complete Zep service; Zep also offers enterprise BYOC. Letta supports a local CLI runtime and self-hosted App Server, but local state does not mean local inference. Verify the exact deployment’s dependencies, model provider, backup path, and required features before treating self-hosting as a portability guarantee.
3. Temporal and contradiction semantics. Require explicit behavior for changed facts, historical questions, and conflicting statements. Design separate tests for time-aware retrieval, recency ranking, editable current state, and bitemporal invalidation rather than treating them as synonyms. Cognee’s API documents a TEMPORAL retrieval mode, establishing time-aware retrieval support. It does not establish Graphiti-equivalent valid-time and transaction-time semantics or automatic contradiction resolution. Feed each candidate the same dated updates, then inspect retrieved evidence and answers for both historical and current queries. Keep unverified semantics marked as unverified.
4. Access enforcement and integrations. Inspect authenticated boundaries, dataset or graph policies, and the adapter you will actually deploy. Cognee documents dataset ACLs combining user, tenant, and role grants as a union: a restrictive role should not be assumed to override a broader tenant grant. Its Cloud documentation also lists isolated workspaces, per-session memory, MCP-compatible clients, and framework integrations. Test cross-tenant access attempts and grant combinations, then exercise the required adapter in the intended deployment mode; a listed integration alone does not demonstrate end-to-end access enforcement.
5. Reproducible evaluation and workload-based pricing. Run the same workload through all four candidates, recording ingestion, retrieval, answer quality, latency, token consumption, and billing units. Cognee publishes an ingestion-to-rubric-scoring evaluation workflow supporting local runs or larger Modal sweeps. Zep also publishes own-data evaluation guidance, so benchmarkability is not exclusive to Cognee. For economics, map measured usage to the deployment’s actual charges. Cognee’s documented free tier includes 1M tokens; also account for processed-token billing, additional-workspace charges, or custom-priced Enterprise BYOC rather than comparing entry prices alone.

Use these five criteria as acceptance gates, with the same questions and test inputs for every candidate. Cognee deserves a place in that pilot because each gate has relevant documentation, not because documentation proves universal superiority. Its temporal semantics still need workload-specific verification, and its backend configuration needs a pinned release. The supplied evidence does not include a controlled comparison on your workload. Separate documented capability from observed behavior, record failures alongside successes, and make the final selection from measured suitability and operating cost.

1. Mem0

Mem0 is a credible choice for conversational personalization when you want vector-ranked memory with optional graph context. Its open-source graph architecture is vector-first, not vector-only: embeddings determine the ranked memory results, while a graph backend supplies related entities and relationships separately. That distinction matters when evaluating retrieval behavior, because enabling graph memory does not automatically make graph relationships control result ordering. We would evaluate the open-source library, self-hosted server, and managed platform separately: they share the Mem0 name, but the documented deployment options do not provide complete feature parity.

Mem0 Key Features

• Vector-ranked results with separate graph context. Graph-enabled retrieval returns relationships in a separate relations array; graph edges do not automatically reorder the vector hits. Evaluate both outputs rather than assuming a single graph-ranked response.
• Current ADD-only extraction. The repository describes single-pass, ADD-only extraction and retrieval using semantic, BM25, and entity signals. The older ADD/UPDATE/DELETE/NOOP workflow should not be treated as the only current implementation.
• Platform-only temporal features. Mem0’s supplied 2026 technical publication describes temporal reasoning that distinguishes current facts, past facts, and future plans using timing, completion state, temporal precision, and memory type. Memory decay changes retrieval ranking without deleting history; both features are platform-only according to that publication.
• Scoped identities and integration paths. user_id, agent_id, and run_id scope context across users, agents, and sessions. Hosted quickstarts cover Python, JavaScript, cURL, and CLI access, and point to Mem0 MCP for agent-directed memory operations. Engineering inference: these identifiers define retrieval scope, not a complete authorization boundary; application authentication and access controls still need testing.

When is Mem0 best for conversational personalization?

• Per-user conversational personalization: Choose Mem0 when you want memories retrieved within a user’s scope, with optional graph relationships available alongside vector-ranked results.
• Scoped context across agents or sessions: Choose Mem0 when your application needs to separate or share context through user, agent, and run identifiers, while enforcing access controls separately.

Self-hosting is a documented option, including graph memory. Mem0’s Apache-2.0 repository offers a library and a self-hosted server alongside the managed platform. The graph documentation lists Neo4j, Memgraph, Neptune, Kuzu, and Apache AGE, with installation through mem0ai[graph]. That makes a cloud-only characterization inaccurate, even though hosted graph access is plan-gated. For a deployment decision, distinguish the graph backend you can operate yourself from managed features you cannot assume are included in the library. The hosted MCP quickstart pointer likewise should not be treated as proof of identical self-hosted integration coverage.

Mem0 Pricing

Choose Mem0 when per-user personalization, explicit retrieval scoping, and optional graph context fit your application better than graph-led ranking. Keep deployment assumptions narrow: self-hosted graph support does not imply access to platform-only temporal reasoning or memory decay, and hosted pricing does not establish open-source feature parity. We would also avoid assuming that a published benchmark result transfers unchanged between managed and self-hosted configurations. Verify the evaluated implementation and enabled features before applying those results to your deployment; the numerical benchmark comparison belongs in the cross-tool comparison section.

2. Zep

Zep is a strong fit when agent memory must distinguish what is true now from what was true earlier. Its Graphiti architecture represents temporal entities and relationships, combining vector search, full-text search, and graph traversal. Updated facts can invalidate earlier relationships without erasing their history. Keep the deployment boundary explicit: self-hosted Graphiti is the underlying open-source option, not a complete replacement for the managed Zep platform. Zep also offers enterprise BYOC, so the choice is not simply self-hosting versus a vendor-hosted service.

Zep Key Features

• Temporal graph retrieval: Graphiti combines vector similarity, full-text search, and graph traversal over temporal entities and relationships. Retrieval can therefore use both semantic matches and connected facts rather than relying on vector similarity alone.
• Bitemporal fact history: Records distinguish when a fact became valid or stopped being valid from when the system learned those changes. Invalidation preserves previous facts, supporting both current-state and historical-state questions.
• Managed graph access: Zep separates accounts and projects, provides user graphs spanning a user's threads, and supports shared Context Graphs. Attribute-based access control (ABAC) can restrict operations, data classes, and specific shared graphs. A project API key without ABAC policies has full project read/write access; isolation requires deliberate policy configuration.
• MCP boundaries matter: Managed Zep Context MCP access is distinct from Graphiti's reference MCP and REST servers. Those reference servers lack authentication, authorization, and prompt-injection protection; callers can access any group_id. That identifier is not an authenticated tenant boundary. Zep's UserGroup policies for Context MCP users are Enterprise-only.

When is Zep best for temporal facts and managed governance?

• Historical and current-state queries: Choose Zep when agents must answer both “What is true now?” and “What was true then?” Bitemporal records distinguish real-world validity from when the system learned about a change, while retaining invalidated facts.
• Governed shared context: Choose managed Zep when agents need user-specific memory alongside shared Context Graphs with explicit access policies. Configure project boundaries and ABAC rather than assuming an API key is restricted; evaluate Enterprise when Context MCP requires UserGroup authorization.

Zep Pricing

Zep meters episode ingestion by bytes: each episode consumes one credit per 350 bytes or part thereof. Retrieval, storage, and users are unmetered. Estimate ingestion costs from episode sizes and counts rather than treating one episode as one credit; the rounding rule applies to each episode. The managed plans below should also be kept separate from self-hosted Graphiti: running the open-source engine yourself is a different deployment choice, while Enterprise provides a BYOC option within Zep's offering. Enterprise pricing is custom.

We would favor Zep when temporal fact history and managed access controls are operational requirements, provided the team configures and tests its policies. For self-hosting, pin the evaluated graphiti-core version: this review uses 0.31.1, declared Apache-2.0, not MIT. Graphiti deprecates Kuzu and recommends Neo4j or FalkorDB for new projects. Operating Graphiti also means supplying the security and tenant-isolation layer missing from its reference servers. These conditions make Zep a targeted choice for temporal, governed memory-not a universal winner across agent workloads.

3. Letta

Letta is a stateful-agent platform with persistent memory, rather than an interchangeable memory API you attach to an existing runtime. Its MemGPT lineage uses an OS-inspired hierarchy: agents manage immediate core context separately from external conversational memory, archival memory, and files. The defining mechanism is editable, prompt-visible memory blocks, which let the agent maintain context across interactions. Choose Letta when that agent-managed execution model fits your application; evaluate it as a runtime decision, not only as a choice between vector retrieval and graph-backed storage.

Letta Key Features

• Prompt-visible, editable blocks: Persistent, labeled memory blocks are prepended to the agent’s prompt and remain visible without retrieval. Agents can edit them through memory tools, and blocks can be shared across agents.
• Core and external memory hierarchy: Immediate core context is managed separately from external conversational memory, archival memory, and files. This separates always-visible context from information the agent must access outside that context.
• Open-source, self-hosted execution: The Apache-2.0 platform supports an in-process local CLI runtime and a self-hosted App Server. Persistent agent state resides on the selected machine; inference location depends on the configured model provider.
• Hosted MCP access: Claude Code, Cursor, and other MCP clients can create and message persistent Letta agents through its hosted MCP server. This differs from a Letta agent consuming tools exposed by external MCP servers.

When is Letta best for agent-managed persistent context?

• Agents that edit their own persistent context: Choose Letta when the agent should maintain prompt-visible memory blocks itself. For self-hosting, configure a local model provider if inference must stay local. Self-hosted agents are not automatically backed up or accessible through the hosted chat application.
• MCP clients that need persistent agents: Choose Letta when Claude Code, Cursor, or another MCP client should create or message stateful agents. For self-hosted integrations, follow the guidance to isolate App Server per tenant or machine, authenticate non-loopback WebSocket listeners, and enforce authorization in the controller. Shared memory blocks are not a substitute for tenant isolation.

Letta Pricing

Letta separates personal subscriptions from developer API billing, so the $20 personal Pro price is not the complete cost of a production API deployment. Personal plans specify agent allowances, while the developer API plan adds active-agent, tool-execution, and model-usage charges to its monthly base. For a production estimate, account for those metered components separately rather than extrapolating from a personal subscription. No workload-specific estimate of tool-execution or model charges is supplied here; the published rates below identify the components you need to budget for.

Letta is a strong fit if you are prepared to adopt its stateful-agent runtime and want agents to edit their own persistent context. That runtime-adoption condition matters more than treating its memory blocks as a drop-in retrieval service. Keep temporal requirements separate: the reviewed documentation establishes self-editing memory and persistent state, but does not establish automatic bitemporal fact invalidation equivalent to Graphiti. Explicit temporal and contradiction guarantees therefore remain unverified, not categorically absent; validate those behaviors against your application’s requirements before committing.

4. Cognee: Portable graph-backed shared memory

Cognee is our best overall choice for teams that need connected memory across documents, code, and conversations, provided its retrieval behavior and deployment requirements fit their workload. Its architecture combines graph, vector, and relational storage rather than treating memory as vector retrieval alone. The Apache-2.0 repository supports self-hosting, while Cognee Cloud provides a managed option with workspace and session separation. The recommendation rests on that combination, dataset-level permissions, and a published evaluation workflow-not on an assumption that every deployment has identical backends, model capabilities, or temporal guarantees.

Cognee Key Features

• Connected context across content types: Cognee builds connected memory from documents, code, and conversations. This gives teams a basis for retrieving related context across those inputs instead of maintaining a separate memory approach for each content type.
• Graph, vector, and code retrieval: Relational storage complements graph and vector storage. The reviewed backend template lists SQLite, LanceDB, and Kuzu; other materials reference Ladybug. Pin and test a release rather than treating any one backend combination as a universal default.
• Memory lifecycle and session distillation: The API exposes remember, recall, improve, and forget; session distillation retains accepted lessons as permanent memory. Bundled GLiNER graph extraction and local embeddings can run without an LLM API key. Generated answers and some improvement or media-processing stages require additional model configuration, and local deployment does not establish parity with the production small-model runtime.
• Dataset permissions and Cloud separation: Dataset ACLs combine user, tenant, and role grants. Effective access is their union: a restrictive role does not automatically override a broader tenant grant. Cloud workspace isolation and per-session memory provide additional separation concepts, but applications still need an explicit permission design.
• Integrations and time-aware retrieval: Documented Cloud integrations include Claude Code, Cursor, Codex, LangGraph, n8n, CrewAI, OpenAI Agents SDK, Google ADK, and MCP-compatible clients. Verify the adapter and deployment mode. TEMPORAL retrieval is documented alongside graph completion, chunks, summaries, and lexical search; Graphiti-equivalent valid-time/transaction-time semantics and automatic contradiction resolution are not established.

Cognee Differentiators

These capabilities support the recommendation as a combination; none should be treated as exclusive to Cognee.

• Apache-2.0 self-hostability: Teams can evaluate the open-source implementation within their own deployment constraints rather than starting with a mandatory managed service.
• Connected, mixed-content memory: Documents, code, and conversations participate in the same connected-memory approach, with graph, vector, and code retrieval available for different questions.
• Published own-data evaluation workflow: Cognee documents ingestion, retrieval, answer generation, and rubric scoring, with local execution or Modal-based larger sweeps. That provides a concrete starting point for testing before commitment.
• Token-based Cloud pricing: Managed usage is priced by tokens, with additional workspace charges. Enterprise offers a custom-priced BYOC engagement; this does not establish universal cost superiority or freedom from migration work.

Benefits of using Cognee

• Deployment control: Apache-2.0 self-hosting and managed Cloud options let teams evaluate different operational arrangements. Model configuration and release-specific backend choices remain part of that assessment.
• Permission-governed shared context: Dataset ACLs provide a mechanism for sharing relevant memory across authorized users, tenants, and roles. Testing combined grants is essential before treating that configuration as an isolation boundary.
• A structured evaluation path: The published workflow lets teams examine retrieval and generated answers separately, then score results against their own rubric rather than relying only on a vendor demonstration.

How can teams use Cognee for shared agent memory?

• Shared document and conversation context: A team could ingest reference documents and conversations into connected memory, then use dataset permissions to govern which agents and users can retrieve them. Test tenant, role, and user grants together.
• Code-oriented assistant memory: Developers could evaluate code retrieval through supported clients such as Claude Code, Cursor, or Codex. Confirm that the required adapter works with the intended Cloud or self-hosted deployment before designing around it.
• Retaining accepted lessons: A workflow could use session distillation to preserve accepted lessons beyond an individual session. Evaluate which lessons become permanent memory and whether subsequent recall supplies appropriate context.

Cognee Pricing

Our recommendation is conditional on results from the reader’s own workload. Start with representative documents, code, conversations, and permission boundaries; pin the release and backend configuration; then evaluate ingestion, retrieval, answer generation, and rubric scores. Include time-sensitive questions if temporal behavior matters, rather than assuming TEMPORAL retrieval supplies bitemporal or contradiction-resolution guarantees. For self-hosting, test the model configuration you will actually operate. For Cloud, verify current pricing and workspace charges. Cognee’s documented evaluation workflow makes it a strong candidate to benchmark before committing, not a substitute for that benchmark.

Mem0 vs Zep vs Letta vs Cognee: Feature Comparison

The useful comparison is between deployable configurations, not product names alone. Mem0’s open-source SDK differs from its managed platform; self-hosted Graphiti is not the complete Zep service; Letta is a stateful-agent platform rather than an interchangeable memory API. We recommend Cognee overall for connected memory across documents, code, and conversations, with graph and vector retrieval. That recommendation remains conditional on your access model, retrieval workload, and deployment requirements. The tables below separate architecture, vendor-published benchmarks, and billing units so a capability or performance disparity is not mistaken for a universal ranking.

Table 1. Architecture and operational tradeoffs by deployment.

Table 2. Published vendor results-not a matched four-way evaluation.

Table 3. Documented pricing entry points; unlike billing units do not establish the cheapest product.

Our qualified overall recommendation is Cognee: its connected-memory approach, graph and vector retrieval, documented integrations, and dataset permissions make it a strong starting point for evaluating shared memory. That does not make it the default for every architecture. Choose Zep or Graphiti when explicit bitemporal semantics drive the design, Mem0 for vector-first retrieval, or Letta when the agent platform itself is the requirement. For broader SDK ergonomics, storage backends, framework bindings, and migration risk, see our related guide, Which Agent Memory SDK Should You Use in 2026?: https://opensourceaireview.com/blog/agent-memory-sdk-comparison-2026.

The benchmark findings are directional: Zep reports the higher LoCoMo score, Mem0 the higher LongMemEval score, and Cognee a higher BEAM 10M score than Mem0. No independently reproduced, matched four-way evaluation is supplied, so these results do not establish one universal accuracy winner. Benchmark shortlisted deployments on your own data with matched models, prompts, retrieval budgets, and dataset coverage. Include historical updates and contradiction questions, inspect returned context, and measure latency alongside accuracy. Likewise, compare total cost under the same workload rather than treating unlike billing units as equivalent.

Which agent memory layer should you choose in 2026?

Our overall recommendation is Cognee when portable, shared graph memory and evaluation on your actual corpus are decisive. Its Apache-2.0 platform builds connected memory from documents, code, and conversations, with graph and vector retrieval. Choose Mem0 for conversational personalization when vector-ranked retrieval fits your application; its optional graph adds relationships without automatically reranking vector hits. Prefer Zep when explicit temporal truth and a managed deployment are priorities: Graphiti tracks both fact validity and system knowledge over time. Choose Letta when the agent should manage persistent, always-visible context through editable memory blocks.

Before committing, use Cognee’s published evaluation workflow to test ingestion, retrieval, answer generation, and rubric scoring against your workload. Own-data evaluation is not exclusive to Cognee: Zep also publishes guidance and an evaluation harness covering context completeness, correctness, latency, and token use. Published benchmark results do not establish a universal accuracy winner because models, prompts, retrieval procedures, and dataset coverage differ. Treat our recommendation as a shortlist decision, not proof of production fitness. Run a controlled pilot with explicit acceptance thresholds before selecting a platform:

1. Hold the setup constant: use the same corpus, questions, answer model, and judge across all candidates.
2. Exercise changing knowledge: test changed facts, contradictions, and historical queries, checking both current and earlier states.
3. Check abstention: include unanswerable questions and assess whether the system appropriately declines to answer.
4. Verify isolation: test cross-tenant leakage and configured access boundaries rather than assuming tenant identifiers enforce authorization.
5. Measure the complete workload: record ingestion and retrieval behavior, answer correctness, latency, token use, and total workload cost; select against predefined acceptance thresholds.

FAQs: Mem0 vs Zep vs Letta vs Cognee

What is the best memory layer for AI agents in 2026?

There is no universally best implementation. Our best-overall recommendation is Cognee when you need portable, graph-backed shared memory and will validate retrieval quality on your own workload. Its Apache-2.0 repository supports connected memory across documents, code, and conversations, and its published evaluation workflow covers ingestion through answer scoring. Choose Mem0 for vector-first retrieval with optional graph context, Zep for explicit temporal modeling, or Letta for agent-editable memory blocks. Cognee’s recommendation remains conditional on deployment fit, permission testing, and measured results; Zep also publishes guidance for evaluating your own data.

When should I choose Cognee over Mem0, Zep, or Letta?

Choose Cognee when your requirements combine graph and vector context, shared memory across agents or tools, deployment portability, and a documented evaluation workflow. Cognee Cloud lists isolated workspaces, per-session memory, and integrations including MCP clients, LangGraph, and the OpenAI Agents SDK; verify the adapter and deployment mode you need. Prefer Mem0 when vector-ranked results with supplementary graph relations match your retrieval design. Prefer Zep when valid-time and transaction-time tracking are central. Prefer Letta when persistent, always-visible, agent-editable prompt blocks are the right abstraction rather than an external retrieval layer.

Does Cognee support temporal retrieval like Zep?

Cognee documents a TEMPORAL retrieval mode, so time-aware retrieval is supported. That does not establish equivalence with Zep’s Graphiti bitemporal model. Graphiti records when a fact became valid, when it stopped being valid, when the system learned it, and when it learned the fact was no longer true. The reviewed Cognee documentation does not verify matching valid-time and transaction-time guarantees or automatic contradiction resolution. If your application must distinguish historical reality from what the system knew at a particular moment, test those cases explicitly before treating the implementations as interchangeable.

Is there support for transitioning from Mem0, Zep, or Letta to Cognee?

The reviewed sources do not establish dedicated migration tooling or transition support from Mem0, Zep, or Letta to Cognee. They do not establish supported import formats, automated conversion, or state-preserving migration either. Separately, we recommend a pilot using representative source documents and conversations, where available, with Cognee’s published ingestion, retrieval, answer-generation, and scoring workflow. Compare the results against your existing system before committing. This is an evaluation proposal, not a documented migration path: confirm how existing memory state, permissions, and temporal information would be represented rather than assuming compatibility.

What features should the best shared agent memory platforms provide?

The best shared-memory platform should match your retrieval architecture, provide deployment control, document temporal behavior, enforce access permissions, integrate with your agent stack, and support evaluation on representative workloads. Do not assume these products implement those requirements identically. For example, Cognee combines user, tenant, and role grants as a union, so a restrictive role does not necessarily cancel broader tenant access. Graphiti’s reference servers require an added security layer. Check the actual adapter, deployment mode, and authorization behavior instead of treating framework compatibility or a tenant identifier as sufficient evidence.

Are Mem0, Zep, Letta, and Cognee benchmark scores directly comparable?

No. Treat the published results as vendor-reported measurements, not a matched four-vendor accuracy ranking. Models, prompts, retrieval procedures, and dataset coverage differ. Mem0’s repository explicitly identifies its reported scores as managed-platform results with proprietary optimizations absent from the open-source SDK. Cognee’s BEAM methodology describes corpus cleanup, question-specific prompts, retrieval experiments, and final runs on two conversations rather than the entire dataset. These differences prevent a universal accuracy winner, including across updated vendor reports. Use published scores to shortlist candidates, then compare the deployments you intend to run on the same workload.

Is Mem0 graph memory available in the open-source SDK?

Yes. Mem0 documents self-hosted graph memory in its open-source SDK, including installation with mem0ai[graph] and support for Neo4j, Memgraph, Neptune, Kuzu, and Apache AGE. Hosted graph-memory plan restrictions do not make graph support cloud-only. The retrieval architecture remains vector-first: embeddings determine ranked results, while the graph backend supplies related entities and relationships in a separate relations array. Graph edges do not automatically reorder vector hits. Evaluate whether that separation fits your application instead of assuming that enabling graph storage changes the ranking behavior of every search result.

What is the difference between self-hosting Graphiti and deploying Zep?

Graphiti is independently self-hostable; its reviewed graphiti-core 0.31.1 package declares Apache-2.0. Running it yourself does not reproduce the complete Zep managed platform. In particular, Graphiti’s reference MCP and REST servers lack authentication, authorization, and prompt-injection protection, and callers can access any group_id. Production deployments therefore need an added security and tenant-isolation layer; a group identifier is not an authenticated boundary. Zep also offers enterprise BYOC, so the choice is not simply self-hosted Graphiti versus cloud-only Zep. Compare the operational responsibilities and platform features required by your deployment.

Does self-hosting memory also keep model inference local?

No. Hosting memory storage or agent state yourself does not automatically keep model inference local. Letta supports a local CLI runtime and a self-hosted App Server, but local inference requires configuring a local model provider. Cognee’s local quickstart can extract a graph with bundled GLiNER and generate embeddings locally without an LLM API key. Generated answers and some improvement or media-processing stages require additional model configuration. Audit each stage’s provider settings before claiming an entirely local pipeline, and do not assume Cognee’s local quickstart has parity with its production small-model runtime.