Mem0 vs Zep

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Mem0✓fullprobed9/10

   A probe confirms docs.mem0.ai/llms.txt returns HTTP 200 with a proper agent-oriented summary of Mem0, and the docs also expose an OpenAPI spec, MCP server, and CLI that an agent can consume directly. Missing for 10: independent/community confirmation that an agent successfully used llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mem0.ai/llms.txt # Mem0 > Mem0 is a memory layer for LLM agents - persistent, self-improving conte…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.mem0.ai/platform/mem0-mcp”
   • [probe] “official CLI documented at https://docs.mem0.ai/platform/cli”

   proof ↗⚑ flag

   Zep✓fullprobed9/10

   Zep hosts an llms.txt file at help.getzep.com/llms.txt (confirmed HTTP 200 via direct probe) with a clear summary of the product, and also runs a docs MCP server that completed a live keyless JSON-RPC handshake, giving agents multiple direct machine-readable entry points into the docs. Missing for 10: no independent/community confirmation that agents actually use these entry points successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://help.getzep.com/llms.txt # Welcome to Zep! > Zep delivers agent memory at enterprise scale — a governed…”
   • [probe] “PROBE runtime (recorded 2026-09-05): Zep's documentation MCP server at https://help.getzep.com/_mcp/server completed a full keyless JSON-RPC…”
   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Mem0
   Mem0✓fullprobed8/10

   Mem0 is fundamentally API/SDK-first and documents non-interactive setup: a terminal-only account/API-key flow explicitly designed for coding agents with no email or dashboard, a CLI for add/search/list/update/delete, and a self-hostable Docker/REST stack with API keys and audit logs — all of which are naturally scriptable in CI. missing for 10: an explicit CI/CD pipeline example or GitHub Actions integration doc, and independent (non-vendor) confirmation of headless CI usage.

   • [claimed-docs] “a coding agent creates its own account from the terminal and starts storing memories immediately”
   • [claimed-docs] “a coding agent creates its own account from the terminal and starts storing memories immediately.”
   • [claimed-docs] “Let an AI agent create its own Mem0 account and API key in four commands, with no email or dashboard needed.”
   • [claimed-docs] “Four terminal commands create an account and API key. No email, no dashboard.”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “As a self-hosted server. A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   Zep~partialprobed6/10

   Zep is fundamentally API/SDK-driven (thread.add_messages, graph.edge.delete calls) and ships a full-access CLI (zepctl) for managing projects, users, threads, and data from the terminal — both of which are inherently scriptable/headless and usable in CI pipelines. However, there is no explicit documentation or example of CI/CD integration, automated testing, or headless deployment guidance. Missing for 10: explicit CI/CD pipeline examples, headless automation docs, non-interactive auth/service-account setup guidance for CI.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “official CLI documented at https://help.getzep.com/zepctl-cli”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Zep
   Mem0✓fullprobed8/10

   Mem0 documents an official hosted MCP server that exposes memory tools (add/search/update) to any agent, with a one-command connection setup, corroborated by a probe hit confirming the docs page exists. Missing for 10: independent/hands-on third-party verification of the MCP server working in practice beyond vendor docs.

   • [claimed-docs] “The Mem0 MCP server hands your agent a set of memory tools, so it can decide for itself when to save something, look something up, or update…”
   • [claimed-docs] “Connect any AI client to Mem0 using Model Context Protocol in minutes”
   • [claimed-docs] “Point your clients at the hosted server with a single command”
   • [probe] “official MCP server documented at https://docs.mem0.ai/platform/mem0-mcp”

   proof ↗⚑ flag

   Zep✓fullprobed9/10

   Zep documents and runtime-verifies an official Memory MCP server that lets end users connect Claude, ChatGPT, Cursor, Codex and other MCP clients to their agent memory, with a live OAuth-gated endpoint confirmed at api.getzep.com/mcp. missing for 10: independent third-party (non-vendor) hands-on review of the MCP client connection experience beyond Zep's own docs/probe.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [probe] “official MCP server documented at https://help.getzep.com/memory-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Mem0✓fullprobed8/10

   Mem0 documents an official CLI that lets users add, search, list, update, and delete memories directly from the terminal, explicitly for both humans and AI agents, plus a related agent-signup flow via terminal commands. missing for 10: independent/hands-on verification of the CLI beyond vendor docs, and more detail on CLI command coverage/versioning.

   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal. It works with the Mem0 Platfor”
   • [claimed-docs] “Manage memories from your terminal, for both humans and AI agents.”
   • [claimed-docs] “Let an AI agent create its own Mem0 account and API key in four commands, with no email or dashboard needed.”
   • [probe] “official CLI documented at https://docs.mem0.ai/platform/cli”

   proof ↗⚑ flag

   Zep✓fullprobed8/10

   Zep documents zepctl, an official CLI providing full administrative access to Zep projects (managing users, threads, Context Graphs, and data operations from the terminal), independently confirmed via probe at the documented URL. missing for 10: no independent/community hands-on usage reports of zepctl, and no detail on installation/distribution channels.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [probe] “official CLI documented at https://help.getzep.com/zepctl-cli”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Mem0✓fullprobed9/10

   Mem0 provides a well-documented REST/SDK API (openapi.json confirmed live, quickstart with Python/JS SDKs, add/search operations), plus a CLI and MCP server enabling agents to programmatically create accounts and drive memory operations without human intervention. Coverage spans platform and self-hosted API surfaces with concrete request/response examples. Missing for 10: independent third-party benchmark or hands-on verification of API robustness beyond vendor docs.

   • [claimed-docs] “In about five minutes you will get an API key, store your first memory, and search it back.”
   • [claimed-docs] “get an API key, then save and search a memory in Python or JavaScript”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “a coding agent creates its own account from the terminal and starts storing memories immediately.”
   • [claimed-docs] “Let an AI agent create its own Mem0 account and API key in four commands, with no email or dashboard needed.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.mem0.ai/platform/mem0-mcp”
   • [probe] “official CLI documented at https://docs.mem0.ai/platform/cli”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”

   proof ↗⚑ flag

   Zep✓fullprobed9/10

   Zep documents a full REST/SDK API (thread.add_messages, graph.edge.delete, get_user_context, etc.) with quick-start guides, plus a CLI (zepctl) providing full programmatic/administrative access, and runtime probes confirm live endpoints (MCP server, docs API) behaving as documented. This is clearly a documented, agent-drivable public API surface with concrete code examples and independent runtime verification. Missing for 10: no independent third-party API reference/benchmark beyond vendor docs and probes.

   • [claimed-docs] “Add agent memory to your app in three lines of code.”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “official CLI documented at https://help.getzep.com/zepctl-cli”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Zep
   Mem0~partialclaimed5/10

   Mem0 supports per-user/agent API keys and lets an agent self-provision its own account and key via CLI, plus entity-scoped memory (user_id/agent_id/app_id/session_id) to isolate data access, which gives some least-privilege-like scoping. However there is no documented fine-grained permission model (e.g., read-only vs write, scope restrictions per key) beyond per-user key issuance and an audit log. Missing for 10: explicit permission/scope levels on API keys, revocation/rotation controls, and independent verification of least-privilege enforcement.

   • [claimed-docs] “a coding agent creates its own account from the terminal and starts storing memories immediately”
   • [claimed-docs] “a coding agent creates its own account from the terminal and starts storing memories immediately.”
   • [claimed-docs] “Let an AI agent create its own Mem0 account and API key in four commands, with no email or dashboard needed.”
   • [claimed-docs] “The self-hosted bundle ships the REST API and a web dashboard together... per-user API keys and a request audit log.”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Mem0's Platform API lets you separate memories for different users, agents, and apps.”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”

   proof ↗⚑ flag

   Zep✓fullprobed8/10

   Zep explicitly documents ABAC policies attached to API keys and UserGroups to enable least-privilege access for agents and Memory MCP users (zep-docs-25, zep-docs-38, zep-docs-31, zep-docs-12), and this is corroborated at runtime by the Memory MCP endpoint being IdP-gated with OAuth-protected-resource metadata rather than open access (zep-probe-rt-2). Missing for 10: no worked example showing granular scope definitions (e.g. per-thread or per-action policy syntax) or independent third-party audit of the ABAC enforcement.

   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Mem0
   Mem0✓fullprobed8/10

   Mem0 provides official Python/JavaScript SDKs with quickstart docs, an OpenAPI-backed REST API, and documented setup guides for 22+ frameworks (LangChain, CrewAI, LlamaIndex, Vercel AI SDK), all core to AI-native agentic workflows. Missing for 10: independent hands-on developer reviews specifically validating SDK ergonomics/reliability beyond vendor docs.

   • [claimed-docs] “In about five minutes you will get an API key, store your first memory, and search it back.”
   • [claimed-docs] “Setup guides for 22 tools, including LangChain, CrewAI, LlamaIndex, and the Vercel AI SDK.”
   • [claimed-docs] “get an API key, then save and search a memory in Python or JavaScript”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “Set up your Mem0 Platform account, install the SDK, and store your first memory in under five minutes.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   Zep~partialprobed6/10

   Docs show official SDK method calls (client.graph.edge.delete, thread.add_messages, three-line quick start) and a real pip-installable OSS engine (graphiti-core) confirmed via probe, indicating an official Python SDK/client exists and works. However, there's no explicit documentation of the full SDK ecosystem (e.g., multiple language SDKs, GitHub repo for the client library itself) or independent developer corroboration of building against these SDKs. Missing for 10: explicit multi-language SDK listing, dedicated SDK GitHub repo evidence, third-party developer confirmation of SDK integration.

   • [claimed-docs] “Add agent memory to your app in three lines of code.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Mem0
   Mem0✓fullclaimed8/10

   Mem0 documents webhooks explicitly, letting users configure HTTP POST callbacks for memory created/updated/deleted/categorized events, which is exactly a webhook subscription mechanism for agentic event-driven workflows. Missing for 10: no independent/hands-on corroboration of webhook reliability and no detail on payload schema or retry/security guarantees.

   • [claimed-docs] “Webhooks enable real-time notifications for memory events in your Mem0 project.”
   • [claimed-docs] “You can configure webhooks to send HTTP POST requests to your specified URLs whenever memories are created, updated, deleted, or categorized…”
   • [claimed-docs] “Configure and manage webhooks to receive real-time notifications about memory events”
   • [claimed-docs] “Webhooks enable real-time notifications for memory events in your Mem0 projec”

   proof ↗⚑ flag

   Zep—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms; Zep's docs cover MCP servers, CLI, SDKs, and API access but nothing about outbound event notifications or webhook subscriptions.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Zep
   Mem0~partialclaimed4/10

   Mem0 automatically extracts facts from conversations and builds a graph linking people, places, and concepts, and reranks results by semantic relevance — these are forms of AI-generated structuring of raw data, but there is no documented feature that proactively surfaces 'insights' or 'suggestions' to the end user (e.g., a dashboard summary or recommendation engine); the product is positioned as memory storage/retrieval infrastructure for agents rather than an insight-generation tool. missing for 10: explicit insights/suggestions surfacing feature, evidence of proactive recommendations, independent corroboration that graph connections are presented as user-facing insights.

   • [claimed-docs] “Mem0 pulls the individual facts out of the conversation and stores each one separately”
   • [claimed-docs] “Mem0 Platform builds a native graph linking people, places, and concepts across your memories, with no external graph database to provision.”
   • [claimed-docs] “Mem0 Platform builds a native graph linking people, places, and concepts across your memories”
   • [claimed-docs] “Reorders results using deep semantic understanding to put the most relevant memories first.”
   • [claimed-docs] “You ask entity-centric questions like "what do we know about Alice?" and expect facts pulled from many different conversations”

   proof ↗⚑ flag

   Zep~partialclaimed5/10

   Zep does generate AI-derived artifacts from ingested data — thread summaries (natural-language summaries incrementally updated by Zep) and entity/relation extraction into the Context Graph — which qualify as AI-generated insights from user data. However, there is no evidence of proactive 'suggestions' or recommendation-style outputs, nor any user-facing dashboard/UI surfacing these insights to an end user; the artifacts are primarily consumed programmatically by the calling agent/app rather than presented as insights inside a product experience. Missing for 10: evidence of suggestion/recommendation generation, and evidence of a UI or interface that surfaces these AI-generated insights directly to a human/ai-native user.

   • [claimed-docs] “A thread summary is a natural-language summary of the messages in a single thread, generated and incrementally updated by Zep.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”
   • [claimed-docs] “Custom Entity/Edge Types | Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Co…”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Mem0
   Mem0~partialclaimed6/10

   Mem0 supports natural-language queries for its 'search' operation and exposes memory tools via MCP so an agent can decide in natural language when to save/retrieve/update memories, which covers the core NL-driven interaction pattern. However, other operations (add, update, delete, CLI commands) are structured API/CLI calls rather than free-form natural-language commands, so full conversational control of the product isn't evidenced. Missing for 10: a unified NL command interface covering all memory operations (not just search), and independent hands-on evidence of agents operating purely via natural language.

   • [claimed-docs] “Mem0's search operation lets agents ask natural-language questions and get back the memories that matter most.”
   • [claimed-docs] “Mem0's search operation lets agents”
   • [claimed-docs] “The Mem0 MCP server hands your agent a set of memory tools, so it can decide for itself when to save something, look something up, or update…”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “Manage memories from your terminal, for both humans and AI agents.”

   proof ↗⚑ flag

   Zep~partialprobed5/10

   Zep exposes an MCP server so agents/AI clients can invoke memory operations via natural-language-driven tool calls, and the Memory MCP endpoint is confirmed live/IdP-gated in a runtime probe, which supports natural-language operation through an AI assistant. However, the primary administrative surface is zepctl, a traditional structured CLI, not a natural-language command interface, and there is no documented natural-language command parser or chat-driven admin console. missing for 10: evidence of natural-language command parsing/execution outside MCP-client pass-through, first-party NL command examples, independent hands-on confirmation of NL-driven operation.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Mem0
   Mem0~partialprobed4/10

   An OpenAPI spec is exposed (mem0-probe-2) and quickstart docs include copyable Python/JS code snippets for add/search calls (mem0-docs-25, mem0-docs-35), which is consistent with an API reference, but there is no evidence of an interactive, in-browser 'try it now' console or runnable-example sandbox tied to that OpenAPI spec. Missing for 10: explicit interactive API explorer/playground UI, evidence of live request execution from docs, and independent confirmation that examples are runnable rather than just illustrative code blocks.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”
   • [claimed-docs] “get an API key, then save and search a memory in Python or JavaScript”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “Set up your Mem0 Platform account, install the SDK, and store your first memory in under five minutes.”

   proof ↗⚑ flag

   Zep—none0/10

   Zep's docs pages show static code snippets (e.g., zep-docs-21, zep-docs-29) but there is no evidence of an interactive, runnable API reference (e.g., embedded sandbox, 'try it' console, Postman/Swagger integration) anywhere in the evidence pack.

   ⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Mem0
   Mem0✓fullprobed9/10

   A direct probe confirms https://docs.mem0.ai/openapi.json returns HTTP 200 and contains an 'openapi' key, i.e. a machine-readable OpenAPI spec is downloadable, and the API is documented elsewhere for developers. Missing for 10: no explicit vendor-side documentation page linking/describing the spec's versioning or completeness beyond the raw probe.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”
   • [claimed-docs] “In about five minutes you will get an API key, store your first memory, and search it back.”
   • [claimed-docs] “get an API key, then save and search a memory in Python or JavaScript”

   proof ↗⚑ flag

   Zep—none0/10

   Zep is an API-first service with SDKs, a CLI (zepctl), and MCP servers, so a downloadable OpenAPI spec would be a natural artifact — but no evidence pack item mentions an OpenAPI/Swagger spec, API reference export, or machine-readable schema file being available for download.

   ⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Mem0—none0/10

   No evidence pack items mention a sandbox, staging, or test-mode environment distinct from production for Mem0's Platform API; self-hosting (mem0-docs-4, mem0-docs-21) offers infrastructure control but is not described as a sandbox/test environment feature. This is a fair capability to expect from an API-based memory platform, but nothing in the docs or community evidence documents it.

   ⚑ flag

   Zep—none0/10

   No evidence of a dedicated sandbox/staging environment, test API keys, or non-production project mode for Zep's memory platform; the only related items are deployment options (Cloud vs VPC) and the standalone open-source Graphiti library, neither of which document a sandbox for testing against production-like data safely.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Mem0—none0/10

   The evidence pack shows quickstart docs, an OpenAPI spec, and various feature docs, but nothing about API versioning scheme or a documented deprecation policy. No changelog, version headers, or deprecation notices are mentioned anywhere in the pack.

   ⚑ flag

   Zep—none0/10

   The evidence pack covers Zep's features (memory, graph, MCP, CLI) but contains no mention of API versioning scheme or a documented deprecation policy for breaking changes. This is a fair axis for an API-first product, but no evidence supports it.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Zep
   Mem0~partialclaimed3/10

   Mem0's CLI and API document per-item add/search/list/update/delete, and the Memory Export feature lets users pull structured exports of memories at once, which is the closest evidence to a bulk operation, but there is no documented batch-add, bulk-delete, or multi-item transactional endpoint. missing for 10: explicit batch/bulk add or delete API, documented multi-item transaction support, evidence of performance/testing at scale for bulk operations.

   • [claimed-docs] “The Memory Export feature allows you to create structured exports of memories using customizable Pydantic schemas.”
   • [claimed-docs] “create structured exports of memories using customizable Pydantic schemas”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”

   proof ↗⚑ flag

   Zep~partialclaimed4/10

   Zep supports some bulk-style operations — deleting a User removes all associated threads/artifacts in one API call, and the zepctl CLI gives scriptable full access to manage users, threads, and graphs from the terminal — but there is no documented batch/bulk create-ingest API for processing many items in a single call. missing for 10: explicit bulk ingest/create endpoints, batch size limits or throughput guidance, and independent evidence of large-scale bulk operations being exercised in practice.

   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Mem0
   Mem0~partialclaimed4/10

   Mem0's webhooks let external systems receive real-time HTTP POST notifications when memories are created, updated, deleted, or categorized, which is the closest thing to event-driven automation — but this is a fixed notification hook, not a user-defined 'rules engine' that lets AI-native users specify custom conditions/actions to trigger. Missing for 10: no evidence of a rules/conditions builder, no support for arbitrary trigger logic beyond CRUD events, and no in-product action execution (only outbound POSTs for external systems to act on).

   • [claimed-docs] “Webhooks enable real-time notifications for memory events in your Mem0 project.”
   • [claimed-docs] “You can configure webhooks to send HTTP POST requests to your specified URLs whenever memories are created, updated, deleted, or categorized…”
   • [claimed-docs] “Configure and manage webhooks to receive real-time notifications about memory events”
   • [claimed-docs] “Webhooks enable real-time notifications for memory events in your Mem0 projec”

   proof ↗⚑ flag

   Zep—none0/10

   Zep is a memory/context-graph layer with search, retrieval, MCP access, and governance policies, but no evidence describes a rules engine or event-trigger mechanism that automatically fires actions on defined conditions/events. Governance features (ABAC/RBAC) restrict access rather than trigger automated actions.

   ⚑ flag

Forgetting

1. platform-engineerDelete a user's memories on demand — single memory, per-entity, or full erasure — to satisfy privacy requirements

   weight 2 · round to Zep
   Mem0~partialclaimed6/10

   Mem0 documents a CLI and API that can add, search, list, update, and delete memories, and its entity-scoped memory model (user_id/agent_id/app_id) lets memories be scoped so a target audience can be identified for deletion. However, the evidence never explicitly documents a bulk 'delete all memories for a user_id' or full-erasure/right-to-be-forgotten endpoint distinct from per-memory delete, and expiration is explicitly called out as non-deletion ('Nothing is deleted'). Missing for 10: explicit bulk/per-entity erasure API or docs (e.g., delete_all by user_id), compliance-oriented erasure guarantees, and independent confirmation that full erasure actually removes underlying data/embeddings.

   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal. It works with the Mem0 Platfor”
   • [claimed-docs] “Manage memories from your terminal, for both humans and AI agents.”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”
   • [claimed-docs] “Mem0's Platform API lets you separate memories for different users, agents, and apps.”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted.”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted. Works on Platform and Op…”

   proof ↗⚑ flag

   Zep✓fullclaimed9/10

   Zep documents multiple granularities of deletion: single edge deletion via client.graph.edge.delete (with cascading edge deletion when a node is deleted), and full user erasure via a single API call that deletes all threads and graph data, explicitly framed as satisfying Right To Be Forgotten/privacy regulation requirements. This covers single-memory, per-entity (node/edge), and full-erasure use cases directly relevant to a platform-engineer's data-lifecycle needs. Missing for 10: no independent/hands-on confirmation of deletion behavior beyond first-party docs, and no explicit documented API for bulk per-entity-type deletion across a graph (only node/edge-level and full-user-level are shown).

   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”

   proof ↗⚑ flag

2. developerMake memories expire or decay — via TTL, expiration dates, or recency weighting — so stale facts stop surfacing

   weight 2 · round to Mem0
   Mem0✓fullclaimed7/10

   Mem0 documents a first-class expiration_date feature that stops memories from surfacing once the date passes without deleting them, working on both Platform and Open Source (mem0-docs-11, mem0-docs-19, mem0-docs-37, mem0-docs-50, mem0-docs-58). This directly satisfies the 'expiration date' part of the story. Missing for 10: explicit TTL (duration-based) configuration syntax, recency-weighting/decay scoring in search ranking, and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Set an expiration_date on a memory and Mem0 stops surfacing it once that date passes”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted.”
   • [claimed-docs] “Set an expiration_date on a memory and Mem0 stops surfacing it once that date passes, so you don't need a cleanup job hunting for rows to de…”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted. Works on Platform and Op…”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes.”

   proof ↗⚑ flag

   Zep~partialclaimed4/10

   Zep's underlying Graphiti engine is a temporal knowledge graph that tracks how facts change over time, which implies automatic invalidation of superseded facts as new information arrives — a decay-like mechanism rather than explicit TTL. However, no evidence describes explicit TTL settings, expiration dates, or recency-weighted retrieval; only manual node/edge deletion APIs are documented for removing stale data. Missing for 10: explicit TTL/expiration-date configuration, documented recency-weighting in search/ranking, and confirmation that fact invalidation actually suppresses surfacing of stale facts in retrieval.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”

   proof ↗⚑ flag

Portability

1. platform-engineerExport memories in a machine-readable format so the memory store is portable and not a lock-in trap

   weight 2 · round to Mem0
   Mem0✓fullclaimed7/10

   Mem0 documents a dedicated Memory Export feature that creates structured exports of memories using customizable Pydantic schemas, and separately offers a self-hosted open-source deployment giving full ownership of the data and stack, both directly addressing the portability/lock-in concern. Missing for 10: no independent/hands-on verification of export fidelity or completeness, and no documented bulk import/migration tooling to move exported data between Platform and self-hosted stores.

   • [claimed-docs] “The Memory Export feature allows you to create structured exports of memories using customizable Pydantic schemas.”
   • [claimed-docs] “create structured exports of memories using customizable Pydantic schemas”
   • [claimed-docs] “Export memories in a structured format using customizable Pydantic schemas”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”

   proof ↗⚑ flag

   Zep~partialprobed4/10

   Zep exposes a graph API (JSON data model, node/edge delete by UUID) and a zepctl CLI described as having 'full access... to manage users, threads, Context Graphs, and data operations from the terminal,' which implies some programmatic read/write access to graph data, and the underlying Graphiti engine is open-source and pip-installable, reducing lock-in. However, no evidence explicitly documents a bulk 'export' command, a defined export file format, or a documented data-portability workflow for moving a full Context Graph out of Zep. Missing for 10: an explicit export/dump feature or format, documentation confirming zepctl or API supports full-graph export, and independent verification of successful export/import round-trips.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”

   proof ↗⚑ flag

Self host

1. developerRun the memory layer fully locally — embedded in-process or against local models — without any cloud dependency

   weight 1 · round drawn
   Mem0~partialclaimed5/10

   Mem0's open-source docs clearly support self-hosting the memory engine (Docker REST server, dashboard, own infrastructure) rather than relying on the Platform SaaS, per mem0-docs-4/21/22/46/28/54. However, none of the evidence confirms an embedded in-process mode or explicit support for local embedding/LLM backends (e.g., Ollama) that would eliminate all cloud calls — the quickstart and core examples default to hosted API keys and cloud model calls. Missing for 10: explicit documentation of local/offline model backends, confirmation that vector store and embedder can run fully in-process without any external API calls, and independent verification of a no-cloud-dependency deployment.

   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log”
   • [claimed-docs] “The self-hosted bundle ships the REST API and a web dashboard together... per-user API keys and a request audit log.”

   proof ↗⚑ flag

   Zep~partialprobed5/10

   Zep's open-source engine Graphiti can be pip-installed and imported with no API key and used to build/query a Context Graph 'locally' in-process, giving a genuine local path, but the main Zep memory service (the one with threads, users, MCP server, zepctl) is documented as deployed via Cloud or 'Your VPC', not as an embeddable local-only runtime, and there is no evidence of configuring it against local LLMs/embedding models. Missing for 10: explicit support for local/self-hosted LLM or embedding models, confirmation that the full Zep memory layer (not just Graphiti) can run fully offline/in-process, and any docs on air-gapped or no-cloud-dependency operation.

   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”

   proof ↗⚑ flag

2. platform-engineerSelf-host the memory layer from open-source code (e.g. via Docker) on infrastructure I control

   weight 3 · round to Mem0
   Mem0✓fullclaimed7/10

   Mem0 docs explicitly describe an open-source self-hosted bundle ('same memory engine as the Platform, running on your own infrastructure') delivered as a Docker stack with REST API, dashboard, per-user API keys, and audit log, giving platform engineers full infra control. Missing for 10: independent/hands-on confirmation of the Docker deployment working in practice and details on infra requirements (e.g., DB/vector store provisioning) beyond first-party docs.

   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “The self-hosted bundle ships the REST API and a web dashboard together... per-user API keys and a request audit log.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”
   • [claimed-docs] “As a self-hosted server. A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log”

   proof ↗⚑ flag

   Zep~partialprobed4/10

   Zep explicitly offers a 'Your VPC' deployment option alongside cloud (zep-docs-17), and its underlying open-source engine Graphiti is pip-installable and runs locally with no API key (zep-probe-rt-3), showing some self-hostable OSS components exist. However, there is no Docker Compose file, self-hosting guide, or explicit instructions for standing up the full commercial 'memory layer' (threads/users/MCP server) on infrastructure a platform engineer controls — the evidence conflates the OSS Graphiti library with the hosted Zep service. Missing for 10: explicit Docker/self-host deployment docs for the full Zep memory service, confirmation that the main product (not just Graphiti) is open-source, and any hands-on report of a successful self-hosted deployment.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”

   proof ↗⚑ flag

Knowledge graph

1. ml-engineerStore memories as a knowledge graph of entities and relationships so multi-hop and entity-centric questions are answerable

   weight 3 · round to Zep
   Mem0✓fullclaimed8/10

   Mem0 Platform explicitly builds a native graph linking entities, places, and concepts across memories with no external graph database required, directly supporting multi-hop and entity-centric queries like what do we know about Alice. Docs describe automatic graph construction without schema definition, replacing earlier Neo4j-based integration. missing for 10: independent or hands-on verification of graph memory multi-hop retrieval accuracy, and no benchmark showing entity-relationship correctness

   • [claimed-docs] “Mem0 Platform automatically organizes your memories into a graph... with no external graph database to provision.”
   • [claimed-docs] “Graph Memory is built in. There is no Neo4j, Memgraph, or other graph store to deploy, no connection strings to manage, and nothing to enabl…”
   • [claimed-docs] “Earlier versions connected an external graph database (Neo4j and others) and exposed a relations field. Mem0 now builds the graph itself fro…”
   • [claimed-docs] “You ask entity-centric questions like "what do we know about Alice?" and expect facts pulled from many different conversations”
   • [claimed-docs] “Mem0 Platform builds a native graph linking people, places, and concepts across your memories, with no external graph database to provision.”
   • [claimed-docs] “You previously used an external graph store and want the same cross-memory connections with zero infrastructure”
   • [claimed-docs] “Mem0 Platform automatically organizes your memories into a graph... without you defining any schema.”
   • [claimed-docs] “Mem0 Platform builds a native graph linking people, places, and concepts across your memories”

   proof ↗⚑ flag

   Zep✓fullprobed9/10

   Zep explicitly builds a Context Graph (temporal knowledge graph via Graphiti) from chat/business data, with entities and relationships, custom entity/edge types, edge/node deletion, and hybrid semantic+BM25 search across nodes/edges/episodes enabling multi-hop and entity-centric retrieval; the underlying Graphiti engine is verified installable and open-source with independent GitHub corroboration. Missing for 10: no explicit hands-on multi-hop query benchmark or third-party validation of entity-centric answer accuracy beyond vendor docs.

   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Context Graph.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”

   proof ↗⚑ flag

2. ml-engineerTrack when facts became valid or invalid (temporal reasoning) so the memory distinguishes current from outdated information

   weight 2 · round to Zep
   Mem0~partialclaimed4/10

   Mem0 supports manual expiration_date so a memory stops surfacing after a set date, and it can update existing facts, but there is no documented capability to automatically detect when a fact becomes invalid/outdated (e.g., contradiction detection, temporal versioning, or 'valid from/until' metadata) — the expiration mechanism is a manual TTL, not temporal reasoning. Missing for 10: automatic invalidation of superseded facts, tracking validity windows for graph relations, and any evidence of reasoning about fact recency versus outdatedness.

   • [claimed-docs] “Set an expiration_date on a memory and Mem0 stops surfacing it once that date passes”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted.”
   • [claimed-docs] “Set an expiration_date on a memory and Mem0 stops surfacing it once that date passes, so you don't need a cleanup job hunting for rows to de…”
   • [claimed-docs] “Set an `expiration_date` on a memory and Mem0 stops surfacing it once that date passes”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted. Works on Platform and Op…”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes.”
   • [claimed-docs] “Earlier versions connected an external graph database (Neo4j and others) and exposed a relations field. Mem0 now builds the graph itself fro…”

   proof ↗⚑ flag

   Zep✓fullprobed8/10

   Zep's Context Graph is built on Graphiti, explicitly described as a temporal knowledge graph that 'tracks how facts change over time' and maintains provenance, directly matching the ml-engineer's need to distinguish current vs outdated facts; this is corroborated by GitHub docs, the Zep team's own explanation of moving from static fact extraction to a temporal graph to fix hallucination/staleness issues, and a runtime probe confirming the open-source Graphiti engine is real and installable. Missing for 10: explicit documentation of valid_at/invalid_at timestamp fields or an API example showing querying facts as of a point in time, and independent hands-on verification of temporal query accuracy.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents.”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”

   proof ↗⚑ flag

Schema customization

1. ml-engineerCustomize the memory schema — entity types, edge types, or ontology — to match my domain

   weight 1 · round to Zep
   Mem0—none0/10

   Mem0's docs explicitly state Graph Memory is fully automatic and built 'without you defining any schema' (mem0-docs-42), with no external graph DB, connection strings, or relations field to configure (mem0-docs-23, mem0-docs-24). There is no evidence of any API, config, or ontology mechanism letting an ml-engineer define custom entity or edge types.

   • [claimed-docs] “Mem0 Platform automatically organizes your memories into a graph... without you defining any schema.”
   • [claimed-docs] “Graph Memory is built in. There is no Neo4j, Memgraph, or other graph store to deploy, no connection strings to manage, and nothing to enabl…”
   • [claimed-docs] “Earlier versions connected an external graph database (Neo4j and others) and exposed a relations field. Mem0 now builds the graph itself fro…”
   • [claimed-docs] “Mem0 Platform builds a native graph linking people, places, and concepts across your memories, with no external graph database to provision.”

   proof ↗⚑ flag

   Zep✓fullclaimed8/10

   Zep explicitly supports Custom Entity/Edge Types via Pydantic-like classes to customize creation/retrieval of entities and relations in the Context Graph (zep-docs-3, zep-docs-33), and the underlying Graphiti engine documents support for both prescribed and learned ontology (zep-gh-1). This directly matches the ML-engineer story of customizing entity/edge types to fit a domain. Missing for 10: no independent hands-on example showing a full custom ontology in production use, and no detail on limits/complexity of ontology customization beyond entity/edge type classes.

   • [claimed-docs] “Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Context Graph.”
   • [claimed-docs] “Custom Entity/Edge Types | Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Co…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”

   proof ↗⚑ flag

Agent memory

1. ai-native userMy agent can manage its own memory mid-conversation — adding, searching, updating, and deleting memories through tools or API calls it invokes itself

   weight 3 · round to Mem0
   Mem0✓fullprobed8/10

   Mem0 documents an MCP server that hands agents add/search/update memory tools they can invoke themselves, a CLI supporting add/search/list/update/delete, and a flow for a coding agent to self-provision an account and start storing memories mid-session — directly matching the story of self-directed, tool-invoked memory management. Missing for 10: independent/hands-on verification that agents reliably invoke delete/update mid-conversation in practice, and explicit API-level delete examples beyond CLI mentions.

   • [claimed-docs] “The Mem0 MCP server hands your agent a set of memory tools, so it can decide for itself when to save something, look something up, or update…”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “a coding agent creates its own account from the terminal and starts storing memories immediately.”
   • [claimed-docs] “Let an AI agent create its own Mem0 account and API key in four commands, with no email or dashboard needed.”
   • [probe] “official MCP server documented at https://docs.mem0.ai/platform/mem0-mcp”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”

   proof ↗⚑ flag

   Zep~partialprobed7/10

   Zep exposes API/SDK calls the agent (or an MCP-connected agent) can invoke itself to add memories (thread.add_messages), search the graph (semantic+BM25, scope=auto), and delete edges/nodes (graph.edge.delete), and the Memory MCP Server is confirmed live and functioning for end-user agent memory access (zep-docs-6, zep-probe-2, zep-probe-rt-2). However, no explicit 'update' operation on existing memories is documented (only add/delete), and the MCP server is gated behind OAuth per the runtime probe, meaning autonomous mid-conversation self-service isn't fully frictionless. Missing for 10: an explicit update-memory API/tool, and clearer evidence the agent (not just external MCP clients) autonomously triggers add/search/delete without human-configured auth setup.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [probe] “official MCP server documented at https://help.getzep.com/memory-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

   proof ↗⚑ flag

2. ai-native userThe memory layer decides for itself what is worth remembering — extracting salient facts from raw conversation and consolidating them in the background

   weight 2 · round to Zep
   Mem0~partialcommunity7/10

   Docs show Mem0 automatically extracts individual facts from raw conversation and organizes them into a graph without user-defined schema (mem0-docs-26, mem0-docs-8, mem0-docs-38, mem0-docs-42), and the search/retrieval flow lets the system decide what's salient (mem0-docs-7, mem0-docs-43). However, evidence of true background 'self-improving' consolidation (deduping, merging over time) is thin, and one independent report notes Mem0 doesn't implicitly learn behavioral patterns beyond stored facts (mem0-comm-7), tempering the 'decides for itself' framing. Missing for 10: explicit documentation/evidence of background consolidation jobs or memory merging over time, and independent hands-on validation of extraction quality.

   • [claimed-docs] “Mem0 pulls the individual facts out of the conversation and stores each one separately”
   • [claimed-docs] “Store facts once, then retrieve them by query”
   • [claimed-docs] “Mem0 Platform automatically organizes your memories into a graph... with no external graph database to provision.”
   • [claimed-docs] “Mem0 Platform builds a native graph linking people, places, and concepts across your memories, with no external graph database to provision.”
   • [claimed-docs] “Mem0 Platform automatically organizes your memories into a graph... without you defining any schema.”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [community] “We looked at Mem0, Letta/MemGPT, and similar memory solutions. They all solve storing facts from conversations - key-value memory with seman…”

   proof ↗⚑ flag

   Zep✓fullcommunity8/10

   Zep automatically ingests raw chat messages into a temporal knowledge graph (zep-docs-20, zep-gh-1/2/3), extracting facts/entities/relations without manual tagging, and separately generates and incrementally updates natural-language thread summaries in the background (zep-docs-8). Community commentary confirms this is a deliberate design evolution from naive LLM fact-extraction toward a more robust temporal graph approach for salience and consolidation (zep-comm-1). Missing for 10: independent benchmark or hands-on evidence of extraction accuracy/salience quality, and detail on exactly how 'importance' is scored versus simply ingesting everything.

   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “A thread summary is a natural-language summary of the messages in a single thread, generated and incrementally updated by Zep.”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”

   proof ↗⚑ flag

Benchmarks

1. ml-engineerSee published memory-quality benchmark results (e.g. LongMemEval, LoCoMo) backing the product's recall-accuracy claims

   weight 2 · round drawn
   Mem0—none0/10

   No evidence of any published benchmark results (LongMemEval, LoCoMo, or similar) or recall-accuracy metrics anywhere in the docs or community sources; the pack only covers feature descriptions and setup guides. missing for 10: any benchmark citation, LongMemEval/LoCoMo results, accuracy/recall metrics, third-party evaluation.

   ⚑ flag

   Zep—none0/10

   The evidence pack contains no mention of published benchmark results such as LongMemEval or LoCoMo, nor any recall-accuracy benchmark comparison; it only covers performance latency claims (sub-200ms retrieval) and general architecture/feature docs. missing for 10: any citation to LongMemEval/LoCoMo results, any third-party or first-party benchmark study, or recall-accuracy metrics.

   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code... in under 200ms.”

   proof ↗⚑ flag

Core memory

1. developerAdd memories from conversations and retrieve them later with semantic search, so context persists across sessions

   weight 3 · round to Zep
   Mem0✓fullcommunity8/10

   Docs clearly describe the core add/search workflow (client.add, search by natural language, scoping by user/session) that persists memories across sessions, and this is corroborated by community reports of using it in production for exactly this purpose. Missing for 10: independent benchmarking of recall/semantic-search quality and long-term persistence beyond vendor docs.

   • [claimed-docs] “Store facts once, then retrieve them by query”
   • [claimed-docs] “Mem0's search operation lets agents ask natural-language questions and get back the memories that matter most.”
   • [claimed-docs] “Mem0 pulls the individual facts out of the conversation and stores each one separately”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [claimed-docs] “Retrieve relevant memories from Mem0 using powerful semantic and filtered search capabilities.”
   • [community] “Congrats on the launch. Adding a memory layer to LLMs is a real painpoint. I've been experimenting with mem0 and it solves a real problem th…”
   • [community] “Memory is extremely useful and almost a requirement when it comes to building next level agents and Mem0 is probably the best designed/easie…”
   • [community] “We looked at Mem0, Letta/MemGPT, and similar memory solutions. They all solve storing facts from conversations - key-value memory with seman…”

   proof ↗⚑ flag

   Zep✓fullprobed9/10

   Zep's docs directly cover the story: adding messages persists them into a user-level knowledge graph (thread.add_messages), retrieval via semantic + BM25 hybrid graph search with sub-200ms context blocks, and cross-session persistence via Threads/Users tied to a Context Graph. This is corroborated by runtime probes confirming the memory endpoints are live and by community discussion of the underlying Graphiti engine's design rationale. Missing for 10: independent hands-on benchmarking of recall quality/accuracy across long sessions beyond vendor-stated latency claims.

   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search. Semantic search finds conceptual matches, and full-text search fin…”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

   proof ↗⚑ flag

2. developerRely on the memory layer to update, supersede, or merge memories when new information contradicts what was stored

   weight 2 · round to Zep
   Mem0~partialclaimed5/10

   Docs confirm an 'update' operation exists (CLI and API can update/delete memories) and webhooks fire on update events, implying the system does modify stored memories over time, but there is no explicit documentation describing automatic contradiction detection, superseding, or merging logic when new facts conflict with old ones. missing for 10: explicit description of conflict/contradiction detection, merge algorithm details, and independent hands-on evidence that Mem0 correctly resolves contradictory facts.

   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal. It works with the Mem0 Platfor”
   • [claimed-docs] “Manage memories from your terminal, for both humans and AI agents.”
   • [claimed-docs] “You can configure webhooks to send HTTP POST requests to your specified URLs whenever memories are created, updated, deleted, or categorized…”
   • [claimed-docs] “Configure and manage webhooks to receive real-time notifications about memory events”
   • [claimed-docs] “Mem0 pulls the individual facts out of the conversation and stores each one separately”

   proof ↗⚑ flag

   Zep✓fullcommunity8/10

   Zep's Graphiti-based temporal knowledge graph explicitly tracks how facts change over time and maintains provenance, and Zep's own team describes moving away from naive fact-extraction to a temporal graph specifically to handle contradiction/reconciliation issues, with edge/node deletion APIs supporting explicit correction. missing for 10: no explicit documented API or hands-on example showing automatic detection/supersession of a contradicting fact (e.g., 'address changed from X to Y' auto-invalidating the old edge) or independent benchmark validating merge/supersede accuracy.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”

   proof ↗⚑ flag

Retrieval controls

1. developerSteer retrieval with metadata filters, keyword/hybrid search modes, or reranking instead of accepting a single fixed similarity search

   weight 2 · round drawn
   Mem0~partialclaimed6/10

   Mem0 docs confirm metadata-style filtering (user/agent/app/session scoping) and a dedicated reranking feature ('Advanced memory search with intelligent reranking') alongside 'semantic and filtered search capabilities', showing retrieval can be steered beyond plain similarity search. However, there is no documented keyword or hybrid (lexical+vector) search mode, and no independent benchmark validating reranking quality. Missing for 10: explicit keyword/hybrid search mode, third-party evidence of retrieval-tuning effectiveness.

   • [claimed-docs] “Reorders results using deep semantic understanding to put the most relevant memories first.”
   • [claimed-docs] “Reranking Reorders results using deep semantic understanding to put the most relevant memories first.”
   • [claimed-docs] “Advanced memory search with intelligent reranking for precise results”
   • [claimed-docs] “Retrieve relevant memories from Mem0 using powerful semantic and filtered search capabilities.”
   • [claimed-docs] “Mem0's Platform API lets you separate memories for different users, agents, and apps.”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”

   proof ↗⚑ flag

   Zep~partialclaimed6/10

   Zep's docs confirm hybrid retrieval (semantic similarity + BM25 full-text) and a configurable 'scope' that composes across edges/nodes/episodes/summaries, showing retrieval is not a single fixed similarity search. However, there is no documented support for explicit metadata-based filtering or a dedicated reranking step/model in the search API. Missing for 10: metadata filter parameters in search calls, explicit reranking option/model, independent confirmation of these controls in practice.

   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search. Semantic search finds conceptual matches, and full-text search fin…”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Zep
   Mem0~partialprobed6/10

   Mem0 is API/CLI/MCP-first: docs show a full REST API (OpenAPI spec), a CLI that can add/search/list/update/delete memories, and an MCP server exposing memory tools to agents, suggesting core operations (add, search, update, delete, scope by user/agent, webhooks, export, expiration) are all reachable via API rather than only through the dashboard. However, the dashboard is described as offering audit logs and API-key management, and there's no explicit evidence enumerating every UI-only feature and confirming full parity, so full API/UI equivalence isn't directly demonstrated. Missing for 10: an explicit comparison or docs statement confirming every dashboard feature (e.g., audit log viewing, key management, graph visualization) is also exposed via API, and independent confirmation of parity.

   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mem0.ai/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.mem0.ai/platform/mem0-mcp”
   • [probe] “official CLI documented at https://docs.mem0.ai/platform/cli”
   • [claimed-docs] “The self-hosted bundle ships the REST API and a web dashboard together... per-user API keys and a request audit log.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”

   proof ↗⚑ flag

   Zep~partialclaimed7/10

   Zep is fundamentally API/SDK-driven (thread.add_messages, graph.edge.delete, etc.) and zepctl/CLI is documented as providing 'full access to Zep, enabling you to manage users, threads, Context Graphs, and data operations from the terminal,' implying strong API/CLI parity with the dashboard UI. However, there is no explicit confirmation that every dashboard-only feature (e.g., RBAC/ABAC policy configuration, analytics views) is fully API-exposed. Missing for 10: explicit parity statement or docs enumerating dashboard-only features and confirming API equivalents, independent verification of full CLI/API coverage.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Mem0
   Mem0~partialclaimed6/10

   Mem0 offers a Memory Export feature using customizable Pydantic schemas, a CLI to list/export memories, and self-hosted open-source deployment giving full data ownership, which together support exporting and leaving with your data. However, the export feature is schema-based/structured rather than a documented fully-open standard format, and there's no explicit bulk 'export all data and delete account' workflow or independent confirmation of export completeness. missing for 10: evidence of a full bulk export in a standard open format (e.g., JSON/CSV dump of entire account), confirmation of data portability across the graph/vector layers, and independent/hands-on verification that exports are complete and truly open.

   • [claimed-docs] “The Memory Export feature allows you to create structured exports of memories using customizable Pydantic schemas.”
   • [claimed-docs] “create structured exports of memories using customizable Pydantic schemas”
   • [claimed-docs] “Export memories in a structured format using customizable Pydantic schemas”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “Manage memories from your terminal, for both humans and AI agents.”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”

   proof ↗⚑ flag

   Zep~partialprobed4/10

   Zep exposes API/CLI access to graph data (zepctl, client.graph.edge.delete, thread/user APIs) and its underlying Graphiti engine is open-source and locally installable, giving some data portability, but there is no documented bulk 'export all my data' feature or standard export format. missing for 10: explicit data-export/portability feature or format documentation, evidence of a full account-data export tool, independent confirmation of successful full export.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Zep
   Mem0~partialclaimed4/10

   Docs confirm a genuine 'Mem0 Open Source' offering that runs on your own infrastructure and gives you 'the stack, the data, and every component,' implying source availability, but no evidence pack item names the actual license (e.g., Apache/MIT) or links to a public repository for verification. missing for 10: explicit license name, link to source repository, independent confirmation of license terms.

   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”

   proof ↗⚑ flag

   Zep~partialprobed5/10

   Zep's underlying temporal knowledge-graph engine, Graphiti, is confirmed open-source on GitHub (30.6k stars) and independently verified as pip-installable with no API key required, satisfying an open-license read for the core Context Graph technology. However, the full Zep product itself (the hosted memory service, zepctl CLI, Memory MCP server) is offered as a commercial Cloud/VPC deployment with no evidence of its own source being under an open license. Missing for 10: confirmation that Zep's actual service/CLI code (not just the Graphiti dependency) is open-licensed, and any repo/license file for Zep itself.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents.”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Deploy anywhere CloudYour VPC”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Mem0
   Mem0✓fullclaimed8/10

   Mem0 documents a distinct Open Source self-hosted bundle that runs the same memory engine as the Platform, deployable via Docker with REST API, dashboard, per-user API keys, and audit log, giving full ownership of stack and data. Missing for 10: independent/hands-on verification of self-hosting (all evidence is first-party docs) and details on feature parity limits (e.g., graph memory) between Platform and self-hosted version.

   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “The self-hosted bundle ships the REST API and a web dashboard together... per-user API keys and a request audit log.”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”
   • [claimed-docs] “As a self-hosted server. A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log”

   proof ↗⚑ flag

   Zep~partialprobed5/10

   Zep offers a 'Your VPC' deployment option alongside Cloud (zep-docs-17), suggesting self-hosting is possible, and the underlying Graphiti temporal knowledge-graph engine that powers Zep's Context Graphs is genuinely open-source and pip-installable with no API key (zep-probe-rt-3, zep-gh-1/2/3). However, the full Zep product (users/threads API, zepctl, governance, Memory MCP server) is only ever described as a commercial Cloud/VPC deployment, not as an openly licensed self-hostable package — VPC deployment likely requires an enterprise contract rather than free self-hosting. Missing for 10: explicit open-source license or self-host instructions for the full Zep service (not just the Graphiti sub-component), pricing/terms for VPC self-hosting, and any community confirmation of successfully self-hosting core Zep.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

   proof ↗⚑ flag

Pricing

1. platform-engineerSee published pricing with a free tier and per-unit rates so I can project memory costs before committing

   weight 2 · round drawn
   Mem0—none0/10

   No evidence in the pack mentions pricing, free tier, or per-unit rates anywhere in the docs, community, or probes; all citations concern product features (memory ops, MCP, CLI, graph memory) rather than pricing plans.

   ⚑ flag

   Zep—none0/10

   The only pricing-related evidence (zep-docs-17) shows a 'Deploy anywhere / Cloud / Your VPC' snippet from the pricing page but contains no mention of a free tier, per-unit rates, or any cost figures that would let a platform engineer project costs. Missing for 10: published free-tier details, per-unit/usage pricing rates, and any cost calculator or tier breakdown.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Zep
   Mem0~partialclaimed4/10

   Mem0 does not document any explicit region/residency selection for its hosted Platform, but the Open Source self-hosted option lets users run 'on your own infrastructure' and 'own the stack, the data, and every component,' which indirectly lets a user choose where data lives by choosing their own hosting location. Missing for 10: explicit region-selection controls in the hosted Platform, documented data-residency guarantees, and any compliance/geo-location settings.

   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack, the data, and every compo…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “Mem0 Open Source is the same memory engine as the Platform, running on your own infrastructure. You own the stack”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”

   proof ↗⚑ flag

   Zep~partialclaimed5/10

   Zep's pricing page states 'Deploy anywhere: Cloud, Your VPC' (zep-docs-17), implying customers can self-host in their own VPC and thus control where data resides, and the open-source Graphiti engine can be run entirely locally (zep-docs-15). However, there is no documentation of a region-selection feature within Zep Cloud itself or explicit data-residency guarantees for hosted customers. Missing for 10: explicit region/residency options in the managed cloud offering, documented list of supported regions, and any compliance certification tied to region choice.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Mem0—none0/10

   No evidence anywhere in the pack addresses opting out of AI-model-training use of data, data-training policies, or contractual/privacy commitments about training; the docs focus entirely on memory storage/retrieval features. This is a fair privacy-posture question for a data-storing SaaS product, but nothing in the evidence confirms or denies such a control exists, so it defaults to none.

   ⚑ flag

   Zep—none0/10

   The evidence pack covers RTBF/deletion, access control, and MCP/CLI tooling, but contains no statement about Zep's or its LLM providers' use of customer data for model training, nor any opt-out/no-training guarantee. Since Zep processes conversational data through LLMs, this is a fair privacy-posture question, but no evidence addresses it.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Zep
   Mem0~partialclaimed6/10

   Mem0 documents CLI/API delete and update operations, expiration_date to stop surfacing memories, and self-hosted deployments giving 'full control over your infrastructure and data', plus audit logs for tracking changes — all supporting retention/deletion control. However, expiration explicitly states 'nothing is deleted' (soft suppression, not erasure), and there's no documented hard-delete/right-to-be-forgotten workflow, data export-then-purge guarantee, or retention policy enforcement (e.g., GDPR compliance statements). missing for 10: explicit hard-delete/purge guarantees, compliance-grade retention policy documentation, independent verification that deletion is permanent.

   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “lets you add, search, list, update, and delete memories directly from the terminal”
   • [claimed-docs] “Manage memories from your terminal, for both humans and AI agents.”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted.”
   • [claimed-docs] “Set an expiration date on a Mem0 memory and it stops surfacing in search once that date passes. Nothing is deleted. Works on Platform and Op…”
   • [claimed-docs] “Set an expiration_date on a memory and Mem0 stops surfacing it once that date passes, so you don't need a cleanup job hunting for rows to de…”
   • [claimed-docs] “Self-host Mem0 with full control over your infrastructure and data”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”

   proof ↗⚑ flag

   Zep✓fullclaimed8/10

   Zep documents user-level deletion (single API call deletes all threads/artifacts) explicitly framed for Right To Be Forgotten/privacy compliance, plus granular deletion of individual edges/nodes and cascading edge deletion. This is corroborated by concrete API examples (client.graph.edge.delete) and admin CLI (zepctl) for data operations. Missing for 10: no documented data-retention policy/TTL configuration or independent third-party audit of deletion completeness.

   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Mem0—none0/10

   No evidence in the pack discusses telemetry, usage tracking, or any opt-out/privacy configuration setting for Mem0; the docs cover memory features, self-hosting, MCP, and CLI but never mention telemetry controls.

   ⚑ flag

   Zep—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Zep itself; the closest topics are RTBF/user-deletion and access control, which do not cover product telemetry opt-out.

   ⚑ flag

Latency

1. platform-engineerSee documented retrieval-latency targets or measured numbers (e.g. p50/p95) backing the product's speed claims

   weight 2 · round to Zep
   Mem0—none0/10

   No evidence pack items mention latency numbers, p50/p95 metrics, or any documented performance/speed targets for retrieval; docs focus on features (search, graph memory, reranking) but never quantify speed.

   ⚑ flag

   Zep~partialclaimed5/10

   Zep's docs make an explicit performance claim ('sub-200ms context retrieval regardless of graph size or number of graphs') and reference it in the quick-start guide, giving platform engineers a concrete latency target to plan against. However, there is no documented p50/p95 breakdown, benchmark methodology, or dataset/scale disclosure, and no independent hands-on measurement corroborates the figure. Missing for 10: percentile (p50/p95) breakdowns, benchmark methodology/conditions, and independent/third-party latency verification.

   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code... in under 200ms.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”

   proof ↗⚑ flag

Scale

1. platform-engineerIngest at scale with async or batch processing and check the status of background memory operations

   weight 2 · round drawn
   Mem0—none0/10

   The evidence pack shows single add/search operations, CLI, webhooks, and quickstart flows, but nothing about async/batch ingestion APIs or a way to poll/check status of background memory operations. This is a fair capability for a memory platform at scale, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Store facts once, then retrieve them by query”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [claimed-docs] “The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal.”
   • [claimed-docs] “Webhooks enable real-time notifications for memory events in your Mem0 project.”

   proof ↗⚑ flag

   Zep—none0/10

   The evidence pack describes single-message ingestion (thread.add_messages) and various data types, but nowhere documents a batch/async ingestion API or a way to poll status of background memory-processing jobs. Missing for 10: batch ingestion endpoint, async job submission, job status/polling API.

   ⚑ flag

Agent memory

1. ai-native userConnect off-the-shelf assistants (Claude, ChatGPT, Cursor) to the same memory so every tool I use shares what it knows about me

   weight 2 · round to Zep
   Mem0✓fullprobed8/10

   Mem0 documents an official MCP server that lets any MCP-compatible client (Claude, Cursor, etc.) connect to the same hosted memory store, plus explicit plugins for Claude Code, Cursor, and Codex, and a one-command way to point multiple clients at the hosted server, all backed by user/agent/app-scoped memory so different tools share the same persistent memory. Missing for 10: independent hands-on confirmation that ChatGPT specifically integrates via MCP/plugin (only Claude/Cursor/Codex are named) and no third-party report validating cross-tool memory sharing in practice.

   • [claimed-docs] “The Mem0 MCP server hands your agent a set of memory tools, so it can decide for itself when to save something, look something up, or update…”
   • [claimed-docs] “Plugins that let Claude Code, Cursor, Codex, and other harnesses remember your project.”
   • [claimed-docs] “Connect any AI client to Mem0 using Model Context Protocol in minutes”
   • [claimed-docs] “Point your clients at the hosted server with a single command”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”
   • [probe] “official MCP server documented at https://docs.mem0.ai/platform/mem0-mcp”

   proof ↗⚑ flag

   Zep✓fullprobed9/10

   Zep documents an official Memory MCP Server explicitly enabling Claude, ChatGPT, Claude Code, Codex, Cursor, and others to connect to a shared end-user memory graph, with a runtime probe confirming the endpoint is live and IdP-gated as documented. This directly satisfies the story of connecting multiple off-the-shelf assistants to shared memory; missing for 10: independent hands-on multi-assistant test showing simultaneous cross-tool memory sharing in practice.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [probe] “official MCP server documented at https://help.getzep.com/memory-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

   proof ↗⚑ flag

Frameworks

1. developerDrop the memory layer into agent frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK via documented first-party integrations

   weight 2 · round drawn
   Mem0~partialclaimed6/10

   Docs reference setup guides covering 22 tools including LangChain, CrewAI, LlamaIndex, and the Vercel AI SDK, which directly supports the story, but the evidence pack only gives a top-level index reference rather than detailed per-framework integration docs or independent confirmation that these integrations work as advertised. Missing for 10: concrete per-framework code samples/docs excerpts (e.g. LangGraph-specific), independent/hands-on verification of the integrations, and any community confirmation of successful use with these specific frameworks.

   • [claimed-docs] “Setup guides for 22 tools, including LangChain, CrewAI, LlamaIndex, and the Vercel AI SDK.”

   proof ↗⚑ flag

   Zep~partialclaimed6/10

   Zep docs explicitly reference 'agent frameworks' integrations (zep-docs-14, zep-docs-24) that persist and retrieve conversation data, and community/HN threads confirm real-world adoption, but the evidence pack never names or links specific first-party integration docs for LangChain, LangGraph, CrewAI, or Vercel AI SDK—only generic 'supported frameworks' language. missing for 10: named/linked docs pages for LangChain, LangGraph, CrewAI, or Vercel AI SDK integrations, and independent confirmation these integrations work as advertised.

   • [claimed-docs] “Zep provides agent memory for agents that you build with supported frameworks.”
   • [claimed-docs] “Zep provides agent memory for agents that you build with supported frameworks. The integrations persist conversation turns and retrieve data…”
   • [claimed-docs] “Add agent memory to your app in three lines of code.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”

   proof ↗⚑ flag

2. developerWire memory into real-time voice pipelines (e.g. LiveKit, Pipecat, ElevenLabs) with documented integrations fast enough for live conversation

   weight 1 · round drawn
   Mem0—none0/10

   The evidence pack lists integrations for LangChain, CrewAI, LlamaIndex, Vercel AI SDK, and coding-agent harnesses (Claude Code, Cursor, Codex), but never mentions LiveKit, Pipecat, ElevenLabs, or any real-time voice pipeline integration or latency guarantees for live conversation use.

   • [claimed-docs] “Setup guides for 22 tools, including LangChain, CrewAI, LlamaIndex, and the Vercel AI SDK.”
   • [claimed-docs] “Plugins that let Claude Code, Cursor, Codex, and other harnesses remember your project.”

   proof ↗⚑ flag

   Zep—none0/10

   The evidence pack shows generic 'agent framework' memory integrations, an MCP server, and a CLI, but contains no mention of LiveKit, Pipecat, ElevenLabs, or any real-time voice pipeline integration or documentation. This is an applicable axis for a memory SDK, but no supporting evidence exists.

   ⚑ flag

Sdks

1. developerBuild against official SDKs in at least Python and TypeScript with equivalent memory APIs

   weight 2 · round to Mem0
   Mem0~partialclaimed6/10

   Docs indicate both Python and JavaScript/TypeScript SDKs exist and expose the same core operations (add, search) via a common quickstart flow, and code snippets show `client.add()` usage. However, there is no dedicated documentation confirming feature parity between the two SDKs, no independent/hands-on verification of the TypeScript SDK, and most of the pack is Python-centric examples. Missing for 10: explicit TypeScript SDK reference/API docs, confirmation of full method parity across languages, and independent developer corroboration of TS SDK usage.

   • [claimed-docs] “get an API key, then save and search a memory in Python or JavaScript”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “Set up your Mem0 Platform account, install the SDK, and store your first memory in under five minutes.”
   • [claimed-docs] “Setup guides for 22 tools, including LangChain, CrewAI, LlamaIndex, and the Vercel AI SDK.”

   proof ↗⚑ flag

   Zep~partialclaimed3/10

   Code examples in docs (e.g. client.graph.edge.delete, thread.add_messages()) show a Python-style SDK, but the evidence pack never mentions a TypeScript/JavaScript SDK or confirms parity between two language SDKs. Missing for 10: explicit TypeScript SDK docs/install instructions, side-by-side API parity confirmation, and any independent corroboration of both SDKs.

   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call. This optimization eliminates the need for a se…”

   proof ↗⚑ flag

Context assembly

1. developerRetrieve a token-budgeted, prompt-ready context block assembled from relevant memories in one call

   weight 2 · round to Zep
   Mem0~partialclaimed4/10

   Mem0's search operation retrieves and reranks relevant memories in a single call (mem0-docs-7, mem0-docs-10, mem0-docs-56), and quickstart flow shows add/search used to fetch context before the next model call (mem0-docs-43). However, there is no evidence of token-budget control, truncation, or an explicit prompt-ready formatted context block being assembled — search returns raw memory results, not a pre-packaged prompt string sized to a token limit. Missing for 10: token-budget parameter or context-length control, explicit prompt-template/context-block formatting output, and any independent confirmation of this packaging behavior.

   • [claimed-docs] “Mem0's search operation lets agents ask natural-language questions and get back the memories that matter most.”
   • [claimed-docs] “Reorders results using deep semantic understanding to put the most relevant memories first.”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [claimed-docs] “Retrieve relevant memories from Mem0 using powerful semantic and filtered search capabilities.”
   • [claimed-docs] “Advanced memory search with intelligent reranking for precise results”

   proof ↗⚑ flag

   Zep✓fullcommunity8/10

   Zep's docs describe a single-call 'Context Block' — via `scope="auto"` graph search or returned directly from `thread.add_messages()` — that composes relevant edges, nodes, episodes, and summaries into one prompt-ready block, with sub-200ms retrieval regardless of graph size, and prior HN commentary confirms the long-term-state/token-count design intent. missing for 10: explicit documentation of a configurable token budget/limit parameter and independent hands-on benchmarking of the assembled context block's quality.

   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call. This optimization eliminates the need for a se…”
   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [community] “Zep team clarified differentiation: 'Many long-term memory services focus on vector search over documents... Zep is different, we focus on t…”

   proof ↗⚑ flag

2. developerGet summaries of past sessions or threads so an agent can pick up where the last conversation left off

   weight 3 · round to Zep
   Mem0~partialprobed6/10

   Mem0's core design explicitly targets cross-session continuity — memories persist and are scoped by session/user/agent, and search retrieves the relevant facts before the next model call so an agent can resume context (mem0-docs-30, mem0-docs-43, mem0-probe-1). However, Mem0 stores discrete extracted facts rather than producing an actual 'summary' of a past thread/session, so the story's specific 'summary' framing is only approximated by fact retrieval, not a dedicated summarization feature. Missing for 10: an explicit session/thread summarization API or feature, and independent hands-on evidence that retrieved facts effectively reconstruct 'where we left off' in practice.

   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [claimed-docs] “Mem0 sits between your application and your model”
   • [claimed-docs] “Mem0's search operation lets agents ask natural-language questions and get back the memories that matter most.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mem0.ai/llms.txt # Mem0 > Mem0 is a memory layer for LLM agents - persistent, self-improving conte…”

   proof ↗⚑ flag

   Zep✓fullclaimed9/10

   Zep documents thread summaries that are auto-generated and incrementally updated per thread, plus a Context Block retrievable via thread.add_messages()/get_user_context() combining summaries, edges, nodes, and episodes so an agent can resume with full prior context. This directly supports resuming past sessions/threads with sub-200ms retrieval performance documented. Missing for 10: independent hands-on verification of summary quality/accuracy over long conversations beyond vendor docs.

   • [claimed-docs] “A thread summary is a natural-language summary of the messages in a single thread, generated and incrementally updated by Zep.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call. This optimization eliminates the need for a se…”
   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”

   proof ↗⚑ flag

Ingestion

1. developerIngest documents, JSON, and business data into memory — not just chat transcripts

   weight 2 · round to Zep
   Mem0—none0/10

   All evidence describes Mem0's add/search API in terms of conversation messages (client.add(messages, user_id=...)) and fact extraction from chat turns; there is no mention of ingesting documents, PDFs, JSON payloads, or arbitrary business data as a memory source. Memory Export uses Pydantic schemas for output, not input ingestion of external structured data.

   • [claimed-docs] “Store facts once, then retrieve them by query”
   • [claimed-docs] “Mem0 pulls the individual facts out of the conversation and stores each one separately”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [claimed-docs] “Mem0 sits between your application and your model. You send conversation turns to `add`, then call `sear”
   • [claimed-docs] “The Memory Export feature allows you to create structured exports of memories using customizable Pydantic schemas.”

   proof ↗⚑ flag

   Zep✓fullclaimed8/10

   Docs explicitly state Zep ingests JSON, text, business data, and documents into the Context Graph, not just chat messages (zep-docs-2, zep-docs-27), with API examples for graph operations and custom entity/edge types for structuring business data. Community context confirms the underlying Graphiti engine tracks facts/entities beyond raw transcripts. Missing for 10: no hands-on independent verification of ingesting large documents or complex JSON schemas at scale, and no detail on supported document formats (PDF, etc.).

   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”
   • [claimed-docs] “Custom Entity/Edge Types | Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Co…”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”

   proof ↗⚑ flag

2. developerStore images, PDFs, or other files as memory inputs and recall information from them later

   weight 1 · round drawn
   Mem0—none0/10

   All evidence describes Mem0 storing and retrieving text-based conversational facts (add/search operations, graph memory, expiration, etc.); nothing in the docs or community evidence mentions ingesting images, PDFs, or other file types as memory inputs.

   • [claimed-docs] “Store facts once, then retrieve them by query”
   • [claimed-docs] “Mem0 pulls the individual facts out of the conversation and stores each one separately”
   • [claimed-docs] “client.add(messages, user_id="user123")”
   • [claimed-docs] “You send conversation turns to `add`, then call `search` before the next model request to fetch relevant context.”
   • [claimed-docs] “Mem0 sits between your application and your model. You send conversation turns to `add`, then call `sear”

   proof ↗⚑ flag

   Zep—none0/10

   Zep's documentation explicitly enumerates ingestible data types as JSON, text, and message only (zep-docs-2), with no mention of images, PDFs, or file uploads anywhere in the evidence pack. No feature, API, or integration is described for storing or recalling from binary/file-based memory inputs.

   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”

   proof ↗⚑ flag

Governance

1. platform-engineerGovern who and what can read or write memory with roles, policies, or access-control lists, and audit that access

   weight 2 · round to Zep
   Mem0~partialclaimed4/10

   Mem0 documents per-user API keys and a request audit log in the self-hosted bundle, plus entity-scoped memory (user/agent/app/session) that could support basic access separation, but there is no evidence of role-based access control, granular permission policies, or ACLs governing who can read/write specific memories. missing for 10: RBAC/permission policies, ACL enforcement on read/write, admin console for managing roles, independent verification of audit log completeness.

   • [claimed-docs] “The self-hosted bundle ships the REST API and a web dashboard together... per-user API keys and a request audit log.”
   • [claimed-docs] “A Docker stack with a dashboard, per-user API keys, and a request audit log.”
   • [claimed-docs] “Stand up the Mem0 REST server and dashboard in a few minutes, with an admin account, API keys, and a live audit log included.”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”
   • [claimed-docs] “As a self-hosted server. A Docker stack with a dashboard, per-user API keys, and a request audit log.”

   proof ↗⚑ flag

   Zep~partialclaimed6/10

   Zep's governance docs describe RBAC for dashboard users and ABAC policies scoped to API keys and UserGroups, letting admins limit what agents and Memory MCP users can read/write (zep-docs-12, zep-docs-25, zep-docs-31, zep-docs-38). However, there is no documented audit logging/trail capability to verify who accessed what memory. Missing for 10: audit log/trail evidence, granular per-resource ACLs beyond API-key/UserGroup scope, and independent verification of policy enforcement.

   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”

   proof ↗⚑ flag

Isolation

1. developerScope memories per user, agent, or application so one tenant's memories never leak into another's retrieval

   weight 3 · round drawn
   Mem0✓fullclaimed7/10

   Docs explicitly describe entity-scoped memory with user_id, agent_id, app_id, and session scoping so memories 'land exactly where they belong' and are separated across users/agents/apps, matching the tenancy story directly (mem0-docs-9, mem0-docs-30, mem0-docs-35). Missing for 10: independent/hands-on verification that isolation is enforced at retrieval time (no cross-tenant leakage tested), and no detail on access-control enforcement (e.g., can a request with wrong user_id still retrieve another user's memories) beyond first-party docs.

   • [claimed-docs] “Mem0's Platform API lets you separate memories for different users, agents, and apps.”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”
   • [claimed-docs] “client.add(messages, user_id="user123")”

   proof ↗⚑ flag

   Zep✓fullclaimed7/10

   Zep documents user-scoped Context Graphs (each user gets their own knowledge graph, created explicitly per app user) and thread-level isolation, plus ABAC/RBAC policies that limit which context each agent, API key, UserGroup, or Memory MCP user can reach — directly supporting tenant isolation across users/agents. Deletion is also scoped per user (RTBF), reinforcing that one user's data is a separable unit that can be walled off or purged without affecting others. missing for 10: explicit documentation of 'application'-level tenancy/namespace isolation beyond User/UserGroup scoping, and independent/hands-on verification that cross-tenant retrieval leakage cannot occur.

   • [claimed-docs] “Whenever users are created in your application, you need to trigger the creation of a Zep user.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”

   proof ↗⚑ flag

Sharing

1. developerShare selected memory across multiple agents or users (team or group memory) while keeping private memory private

   weight 1 · round drawn
   Mem0~partialclaimed5/10

   Mem0's entity-scoped memory lets you scope by user_id, agent_id, app_id, and session, which can be used to segregate private memory per user while sharing memory under a common agent_id or app_id — a workable pattern for group/team memory. However, the docs never explicitly describe a 'team' or 'group' memory concept, permission model, or access-control rules distinguishing private vs shared visibility across users/agents. Missing for 10: explicit team/group memory feature, role-based access control or sharing permissions, and any documentation of enforcing privacy boundaries between scoped entities.

   • [claimed-docs] “Mem0's Platform API lets you separate memories for different users, agents, and apps.”
   • [claimed-docs] “Scope conversations by user, agent, app, and session so memories land exactly where they belong.”

   proof ↗⚑ flag

   Zep~partialclaimed5/10

   Zep's governance model provides ABAC policies attached to API keys and UserGroups to limit which context/actions each agent or MCP user can reach, implying some ability to scope shared vs. private access, and user-level Context Graphs are the default privacy boundary (zep-docs-12, zep-docs-25, zep-docs-31, zep-docs-38). However, there is no explicit documentation of a mechanism for selectively sharing specific memory items across multiple users/agents as a 'team or group memory' feature—only access-control policies, not a shared-graph or memory-merging capability. Missing for 10: explicit team/group memory graph construct, documented API for cross-user memory sharing, and any example/tutorial showing selective sharing while isolating private data.

   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [claimed-docs] “Whenever users are created in your application, you need to trigger the creation of a Zep user.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”

   proof ↗⚑ flag