Zep vs Supermemory

Agent access

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

   weight 2 · round to Zep
   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

   Supermemory✓fullprobed8/10

   A probe confirms a working llms.txt endpoint (HTTP 200) at docs.supermemory.ai, and first-party docs describe agent-oriented resources: a remote MCP server for agents to search Supermemory documentation while implementing integrations, an npx supermemory setup CLI that detects the project and launches the integration flow, and an installable skill so agents use real endpoints instead of hallucinating APIs. Missing for 10: independent/hands-on report of an agent successfully using llms.txt or the docs-MCP end-to-end, and no discoverable OpenAPI spec (probe found 404s on all candidate paths).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.supermemory.ai/llms.txt # supermemory | Memory API for the AI era - [Introduction](https://superme…”
   • [claimed-docs] “Remote MCP that lets the agent search Supermemory documentation while it implements an integration.”
   • [claimed-docs] “npx supermemory setup # detect project, launch/print integration flow”
   • [claimed-docs] “Install the official skill so the agent uses the real endpoints, auth, and `containerTag` rules instead of hallucinating APIs”
   • [claimed-docs] “Set up coding agents to integrate Supermemory — CLI, skill, and docs MCP.”
   • [probe] “official MCP server documented at https://supermemory.ai/docs/supermemory-mcp/mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Supermemory
   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

   Supermemory✓fullclaimed7/10

   Supermemory is API-first: official TypeScript/Python SDKs and a documented REST API let content be added and searched entirely programmatically (docs-24, docs-26, docs-27), and the self-hosted binary explicitly boots with no Docker/config, suitable for automated/CI environments (docs-7, docs-31, docs-44). A CLI (npx supermemory setup) also supports scripted agent setup (docs-6). missing for 10: explicit CI/automation examples or docs, independent confirmation of unattended API-key usage, and clarity on whether initial key minting can be fully non-interactive

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “No Docker. No database to provision. No config files. It boots in seconds with everything built in”
   • [claimed-docs] “State-of-the-art memory, running on your machine. One binary, zero config.”
   • [claimed-docs] “npx supermemory setup # detect project, launch/print integration flow”
   • [claimed-docs] “app.supermemory.ai is the consumer product on the same engine — not where you mint API keys.”

   proof ↗⚑ flag

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

   weight 3 · round to Zep
   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

   Supermemory✓fullprobed8/10

   Supermemory is not itself an agent but a memory service, so shipping an official MCP server is a fair axis; docs confirm a Supermemory MCP server that gives 'every MCP-compatible assistant a shared memory layer' with natural-language tool selection, plus a separate docs-search MCP for integration, and a probe confirms the MCP docs page exists. missing for 10: no independent/hands-on confirmation of the MCP server working end-to-end with a real agent, and no explicit setup/connection instructions cited in the pack.

   • [claimed-docs] “Supermemory MCP gives every MCP-compatible assistant a shared memory layer, so technical and non-technical teams can collaborate with AI usi…”
   • [claimed-docs] “Ask naturally. The assistant selects the right Supermemory tool without requiring code or tool names.”
   • [claimed-docs] “Remote MCP that lets the agent search Supermemory documentation while it implements an integration.”
   • [claimed-docs] “Remote MCP that lets the agent **search Supermemory documentation** while it implements an integration.”
   • [claimed-docs] “Set up coding agents to integrate Supermemory — CLI, skill, and docs MCP.”
   • [probe] “official MCP server documented at https://supermemory.ai/docs/supermemory-mcp/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Zep
   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

   Supermemory~partialclaimed5/10

   Docs mention an official CLI command (`npx supermemory setup`) that detects a project and launches the integration flow, and reference 'CLI, skill, and docs MCP' as part of agent setup, showing a CLI exists for AI-native/agentic workflows. However, evidence is thin — no dedicated CLI reference page, no list of full command set, and no independent/hands-on confirmation of its use. Missing for 10: a full CLI command reference, examples beyond the single setup command, independent user confirmation of the CLI in practice.

   • [claimed-docs] “npx supermemory setup # detect project, launch/print integration flow”
   • [claimed-docs] “Set up coding agents to integrate Supermemory — CLI, skill, and docs MCP.”
   • [claimed-docs] “Install the official skill so the agent uses the real endpoints, auth, and `containerTag` rules instead of hallucinating APIs”

   proof ↗⚑ flag

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

   weight 3 · round to Zep
   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

   Supermemory✓fullprobed8/10

   Supermemory documents a full public API (add/search/memory-operations, containerTag scoping, filtering) plus official TypeScript and Python client libraries wrapping it, and an API reference overview — clearly enabling AI-native users to drive the product programmatically. Missing for 10: a discoverable OpenAPI/swagger spec (probe found only 404s) and independent hands-on confirmation of API robustness beyond docs.

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [claimed-docs] “Create memories directly without going through the document ingestion workflow. Memories are embedded and immediately searchable.”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “Use `searchMode: "hybrid"` for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Metadata Filtering ... Query memories by custom properties like category, status, or date”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.supermemory.ai/openapi.json, https://docs.supermemory.ai/swagger.json, https://docs.sup…”

   proof ↗⚑ flag

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

   weight 2 · round to Zep
   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

   Supermemory—none0/10

   Evidence shows container-tag based data isolation (namespacing memories per user/tenant) and mention that API keys are minted somewhere other than the consumer app, but nothing describes issuing scoped or least-privilege API credentials/tokens (e.g., read-only vs write, per-agent permission scopes) for agents. OAuth credential replacement (docs-47) is about branding the OAuth app name, not permission scoping.

   • [claimed-docs] “A container tag is a hard boundary — its own namespace. Memories in one tag are never returned by a search scoped to another tag.”
   • [claimed-docs] “app.supermemory.ai is the consumer product on the same engine — not where you mint API keys.”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [claimed-docs] “You can replace this with your own app name by providing your own OAuth credentials via the settings endpoint.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Supermemory
   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

   Supermemory✓fullprobed8/10

   Docs explicitly reference official TypeScript and Python SDKs ('npm install supermemory', 'pip install supermemory') that wrap the full API, with extensive documented usage examples (add, search, container tags) across the docs, indicating a mature developer-facing SDK surface. Missing for 10: independent hands-on developer corroboration of the SDKs themselves (community evidence only discusses unrelated ingestion/auth complaints) and no visible changelog/versioning evidence for SDK maturity.

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “await client.add({ content: "Alex mentioned he just started at Stripe", containerTag: "user_123" });”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.supermemory.ai/llms.txt # supermemory | Memory API for the AI era - [Introduction](https://superme…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   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

   Supermemory—none0/10

   The only webhook references describe internal connector sync (e.g., Google Drive/Gmail/Notion changes triggering Supermemory's own ingestion pipeline via 'real-time webhooks'), not an outbound webhook subscription API for end users to receive event notifications. No docs describe registering a webhook endpoint or subscribing to events like memory-created, sync-complete, etc.

   • [github] “Connectors Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”
   • [github] “Connectors | Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”
   • [claimed-docs] “Connect external platforms to automatically sync documents into supermemory. Supported connectors include Google Drive, Gmail, Notion, OneDr…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   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

   Supermemory~partialclaimed5/10

   Supermemory automatically extracts facts, builds a living knowledge graph, and maintains auto-updating user profiles from ingested data — a form of AI-generated insight derived from raw content (supermemory-docs-14, supermemory-docs-15, supermemory-docs-33, supermemory-docs-40). However, there's no evidence of proactive 'suggestions' (e.g., recommended actions, next-step prompts) surfaced to the user — the product is positioned as memory infrastructure/API for retrieval rather than an insights/suggestions dashboard. Missing for 10: evidence of proactive suggestion generation, a user-facing insights UI, or explicit 'recommendation' features beyond fact/profile extraction.

   • [claimed-docs] “Supermemory builds a living knowledge graph of facts on top of other facts — not a static folder of embeddings”
   • [claimed-docs] “User profiles are **automatically maintained collections of facts about your users** that Supermemory builds from all their interactions.”
   • [claimed-docs] “No search needed — comprehensive user info always ready Profiles update as users interact with your system”
   • [claimed-docs] “User profiles are automatically maintained collections of facts about your users that Supermemory builds from all their interactions.”
   • [claimed-docs] “Retrieve three ways — document search (RAG), memory graph traversal, and user profile”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Supermemory
   Zep—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Supermemory~partialclaimed4/10

   Supermemory offers background automation only in the narrow sense of connector auto-sync via real-time webhooks (Google Drive, Gmail, Notion, OneDrive, GitHub) and automatically-maintained user profiles that update as users interact — both run autonomously without manual triggering. But there's no evidence of a general-purpose automation/workflow builder, scheduled agent tasks, or triggers-and-actions system that an AI-native user could configure to run arbitrary autonomous background jobs. Missing for 10: a documented automation/workflow engine, scheduling capabilities beyond data-sync connectors, and any evidence of user-configurable autonomous background tasks.

   • [github] “Connectors Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”
   • [github] “Connectors | Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”
   • [claimed-docs] “User profiles are automatically maintained collections of facts about your users that Supermemory builds from all their interactions.”
   • [claimed-docs] “No search needed — comprehensive user info always ready Profiles update as users interact with your system”
   • [claimed-docs] “Connect external platforms to automatically sync documents into supermemory. Supported connectors include Google Drive, Gmail, Notion, OneDr…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Zep—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Supermemory—none0/10

   Supermemory is positioned as a memory infrastructure/API layer that other AI assistants connect to (via MCP, SDKs, connectors) rather than as a product with its own built-in AI assistant for task delegation; 'Ask naturally' (supermemory-docs-35) describes external assistants querying Supermemory's tools, not a native in-app agent. No evidence describes a built-in assistant inside Supermemory itself that a user can delegate tasks to.

   ⚑ flag

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

   weight 2 · round to Supermemory
   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

   Supermemory✓fullprobed7/10

   Supermemory's MCP docs explicitly describe natural-language operation: 'Ask naturally. The assistant selects the right Supermemory tool without requiring code or tool names,' and the MCP layer lets any MCP-compatible assistant collaborate using shared context. This directly matches the AI-native natural-language command story. Missing for 10: independent/hands-on confirmation of the natural-language MCP experience and broader examples of the range of commands supported beyond search/recall.

   • [claimed-docs] “Ask naturally. The assistant selects the right Supermemory tool without requiring code or tool names.”
   • [claimed-docs] “Supermemory MCP gives every MCP-compatible assistant a shared memory layer, so technical and non-technical teams can collaborate with AI usi…”
   • [claimed-docs] “A space keeps a team's documents, memories, and profile context focused, so AI retrieves the right knowledge without mixing unrelated work.”
   • [probe] “official MCP server documented at https://supermemory.ai/docs/supermemory-mcp/mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   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

   Supermemory—none0/10

   Evidence shows only a static API-reference overview page and SDK code snippets (client.add, client.search), with no interactive 'try-it' console or runnable sandbox; a probe explicitly checked for an OpenAPI/Swagger spec (which typically powers interactive references) and found all candidate URLs returning 404.

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.supermemory.ai/openapi.json, https://docs.supermemory.ai/swagger.json, https://docs.sup…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Supermemory—none0/10

   A direct probe for machine-readable API specs at standard OpenAPI/Swagger paths returned 404 on all candidates, and no evidence pack item links to a downloadable OpenAPI/JSON spec despite an 'API reference' doc existing.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.supermemory.ai/openapi.json, https://docs.supermemory.ai/swagger.json, https://docs.sup…”
   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Supermemory—none0/10

   The evidence describes container-tag based data isolation between end-users/tenants, self-hosting, and a MemoryBench benchmarking tool, but none of this documents an actual sandbox/staging environment (e.g., a test API key, non-production project, or explicit test mode) that a developer could use to try things without touching production data.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Supermemory—none0/10

   No evidence of API versioning scheme (e.g., v1/v2 paths) or any documented deprecation policy; OpenAPI spec probes returned 404 and no changelog/deprecation docs appear in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.supermemory.ai/openapi.json, https://docs.supermemory.ai/swagger.json, https://docs.sup…”

   proof ↗⚑ flag

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

   weight 2 · round to Supermemory
   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

   Supermemory~partialclaimed5/10

   Evidence shows container-tag scoped deletion of all memories in a tenant at once, connector auto-sync ingesting many documents in bulk, and metadata filtering across memories, which together imply some bulk-style operations, but there is no documented dedicated bulk API (e.g., batch add/update/delete of many arbitrary items in one call) or independent confirmation of true bulk throughput. missing for 10: explicit bulk/batch endpoint documentation, evidence of bulk operations beyond tag-scoped delete and connector sync, independent/hands-on validation of bulk performance.

   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. When the user requests deletion, delete that container's content via the API / console w…”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. 2. When the user requests deletion, delete that container's content via the API / consol…”
   • [claimed-docs] “Connect external platforms to automatically sync documents into supermemory. Supported connectors include Google Drive, Gmail, Notion, OneDr…”
   • [github] “Connectors Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”
   • [claimed-docs] “Metadata Filtering ... Query memories by custom properties like category, status, or date”
   • [claimed-docs] “Use customId to update existing documents or conversations. When you send content with the same customId, Supermemory intelligently processe…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Supermemory—none0/10

   Supermemory is a memory/storage layer for AI apps — it supports connectors, auto-sync, and memory extraction, but there is no evidence of a rules/automation engine where users define 'if event X then action Y' triggers. Ingestion and connector syncing are automatic pipelines, not user-defined conditional automation.

   ⚑ 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
   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

   Supermemory~partialclaimed6/10

   Docs explicitly describe deleting a user's entire memory scope via container tags ('When the user requests deletion, delete that container's content via the API / console workflow'), which covers per-entity/full erasure for privacy compliance. However, evidence never documents a single-memory delete endpoint/method, nor any confirmation flow, audit trail, or independent verification that deletion actually purges data (e.g., from backups/embeddings). missing for 10: single-memory-level delete API/example, confirmation of hard-delete semantics (vs soft-delete), independent/hands-on evidence of successful deletion, and audit/compliance documentation beyond container-tag erasure.

   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. When the user requests deletion, delete that container's content via the API / console w…”
   • [claimed-docs] “Scope each end-user (or tenant) to a **container tag**. When the user requests deletion, delete that container's content via the API / conso…”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag.”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. 2. When the user requests deletion, delete that container's content via the API / consol…”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”

   proof ↗⚑ flag

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

   weight 2 · round to Zep
   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

   Supermemory—none0/10

   No documentation describes TTL, expiration dates, or recency-weighted decay; the only related mention (isStatic flag) is about marking facts permanent vs. default, not about expiring stale ones. Moreover the product's own comparison doc admits 'No temporal truth ("loved Adidas" then "switched to Puma", both stay equally relevant)', indicating stale facts are not down-weighted or expired.

   • [claimed-docs] “isStatic: true for permanent identity traits (name, hometown). Defaults to false”
   • [claimed-docs] “No temporal truth ("loved Adidas" then "switched to Puma", both stay equally "relevant")”

   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 Zep
   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

   Supermemory—none0/10

   The evidence pack documents ingestion, search, self-hosting, and API clients, but never mentions a bulk export endpoint, data-dump command, or documented export format for memories — nothing addresses portability of existing data out of the platform. Self-hosting (supermemory-docs-7/8/16/44) is a deployment option, not an export mechanism for data already stored in the hosted service.

   ⚑ flag

Self host

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

   weight 1 · round to Supermemory
   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

   Supermemory~partialclaimed6/10

   Docs explicitly describe a self-hosting option running as a single self-contained binary with local graph engine, local embeddings, and local LLM, claiming data never leaves the building and no Docker/config needed. However, there's no independent/hands-on corroboration of fully offline operation, no detail on which local models are supported or how embedding/LLM swapping works, and self-hosting is positioned as a paid-tier feature (SOC2/HIPAA self-hosted option) rather than a fully documented open local dev path. missing for 10: independent verification of the self-hosted binary running fully offline, concrete local-model configuration docs, and evidence this isn't gated behind enterprise pricing.

   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “Local graph engine, local embeddings, local LLM. Your data never leaves the building.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform ... as a single self-contained binary.”
   • [claimed-docs] “No Docker. No database to provision. No config files. It boots in seconds with everything built in”
   • [claimed-docs] “State-of-the-art memory, running on your machine. One binary, zero config.”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Supermemory~partialclaimed4/10

   Docs confirm a genuine self-host mode — 'runs on your own hardware... single self-contained binary' with local embeddings/LLM — but explicitly state 'No Docker' and describe a closed single-binary distribution rather than open-source code the engineer builds/deploys via Docker. The GitHub repo evidence in the pack only documents connectors/extractors, not that the self-host binary itself is open-source or containerized. missing for 10: Docker/container deployment path, confirmation the self-hosted binary is built from open-source code (license/repo), and independent hands-on verification of self-host setup.

   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform ... as a single self-contained binary.”
   • [claimed-docs] “No Docker. No database to provision. No config files. It boots in seconds with everything built in”
   • [claimed-docs] “State-of-the-art memory, running on your machine. One binary, zero config.”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   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
   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

   Supermemory✓fullclaimed7/10

   Docs explicitly describe a 'living knowledge graph of facts on top of other facts' with graph traversal as one of three retrieval modes, and show entity-centric queries (e.g. 'where does Alex work?' with relatedMemories) demonstrating multi-hop entity resolution across facts like 'Alex mentioned he just started at Stripe'. missing for 10: independent/hands-on validation of multi-hop accuracy, and deeper documentation of explicit entity/relationship schema or graph query language beyond the relatedMemories flag.

   • [claimed-docs] “Supermemory builds a living knowledge graph of facts on top of other facts — not a static folder of embeddings”
   • [claimed-docs] “Retrieve three ways — document search (RAG), memory graph traversal, and user profile”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “await client.add({ content: "Alex mentioned he just started at Stripe", containerTag: "user_123" });”
   • [claimed-docs] “No temporal truth ("loved Adidas" then "switched to Puma", both stay equally "relevant")”

   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
   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

   Supermemory—none0/10

   Supermemory's own comparison docs explicitly admit the product lacks temporal truth tracking, giving the example that 'loved Adidas' then 'switched to Puma' both remain equally relevant rather than one being marked outdated — the opposite of the story's requirement. No other evidence describes validity windows, fact invalidation, or temporal versioning of memories.

   • [claimed-docs] “No temporal truth ("loved Adidas" then "switched to Puma", both stay equally "relevant")”

   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
   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

   Supermemory—none0/10

   Supermemory documents automatic knowledge-graph construction, buckets for profile categorization, and metadata filtering, but no evidence anywhere describes defining custom entity types, edge/relationship types, or an ontology to fit a domain schema — extraction is described as fully automatic ('Supermemory builds a living knowledge graph... automatically').

   • [claimed-docs] “Supermemory builds a living knowledge graph of facts on top of other facts — not a static folder of embeddings”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “Buckets are custom topical categories for a profile ... group them by subject (e.g. preferences, goals, work).”
   • [claimed-docs] “Metadata Filtering ... Query memories by custom properties like category, status, or date”
   • [claimed-docs] “Supermemory automatically extracts and indexes content from various formats.”

   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 Supermemory
   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

   Supermemory✓fullprobed8/10

   Supermemory exposes API/SDK operations (add, search hybrid, update via customId, delete via container tag) and an official MCP server that lets an agent invoke these tools mid-conversation without pre-configured tool names ('Ask naturally... selects the right Supermemory tool'). This directly matches the story of an agent managing its own memory via tool/API calls. missing for 10: no independent hands-on evidence of an agent autonomously invoking delete via MCP, and no explicit example combining add/search/update/delete in one live agent session.

   • [claimed-docs] “Create memories directly without going through the document ingestion workflow. Memories are embedded and immediately searchable.”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “Use searchMode: "hybrid" for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Use customId to update existing documents or conversations. When you send content with the same customId, Supermemory intelligently processe…”
   • [claimed-docs] “Supermemory MCP gives every MCP-compatible assistant a shared memory layer, so technical and non-technical teams can collaborate with AI usi…”
   • [claimed-docs] “Ask naturally. The assistant selects the right Supermemory tool without requiring code or tool names.”
   • [claimed-docs] “Scope each end-user (or tenant) to a **container tag**. When the user requests deletion, delete that container's content via the API / conso…”
   • [probe] “official MCP server documented at https://supermemory.ai/docs/supermemory-mcp/mcp”

   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
   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

   Supermemory~partialclaimed7/10

   Docs clearly describe automatic extraction of salient facts from raw content (docs-1, docs-41, docs-42) and background consolidation into an evolving knowledge graph and auto-maintained user profiles (docs-14, docs-15, docs-33, docs-40) with no manual tagging required. However, the vendor's own comparison page admits a real consolidation gap — no temporal truth resolution, so outdated and current facts both remain 'relevant' (docs-48) — and there is no independent/hands-on evidence corroborating extraction quality. missing for 10: independent corroboration of extraction accuracy, resolution of the documented temporal-truth/consolidation gap.

   • [claimed-docs] “Send any raw content to Supermemory — conversations, documents, files, URLs. We extract the memories automatically.”
   • [claimed-docs] “Supermemory builds a living knowledge graph of facts on top of other facts — not a static folder of embeddings”
   • [claimed-docs] “User profiles are **automatically maintained collections of facts about your users** that Supermemory builds from all their interactions.”
   • [claimed-docs] “No search needed — comprehensive user info always ready Profiles update as users interact with your system”
   • [claimed-docs] “User profiles are automatically maintained collections of facts about your users that Supermemory builds from all their interactions.”
   • [claimed-docs] “Supermemory automatically extracts and indexes content from various formats.”
   • [claimed-docs] “Just upload — Supermemory handles the rest ... No chunking strategies to configure. No embedding models to choose. It just works.”
   • [claimed-docs] “No temporal truth ("loved Adidas" then "switched to Puma", both stay equally "relevant")”

   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
   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

   Supermemory—none0/10

   Supermemory documents a 'MemoryBench' tool that lets users run their own benchmarks against Mem0/Zep/Supermemory, but the evidence contains no published results on standard benchmarks like LongMemEval or LoCoMo, nor any recall-accuracy numbers backing its claims.

   • [claimed-docs] “MemoryBench ships a Claude Code skill that automates the entire process of benchmarking a custom memory implementation — yours — against Sup…”
   • [claimed-docs] “you can run it yourself, against your own memory implementation, on the datasets that match your use case”

   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
   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

   Supermemory✓fullcommunity8/10

   Docs show a complete workflow: add raw content or direct memories (client.add), semantic/hybrid search (client.search with searchMode:hybrid), container tags to scope and isolate memory per user/session, and automatic extraction/indexing of conversations and documents — directly matching the story of persisting and recalling context across sessions. Missing for 10: independent hands-on validation of recall quality/accuracy, and one HN complaint noting ingestion size limits on large linked content suggests some real-world friction in the add-memory pipeline.

   • [claimed-docs] “Send any raw content to Supermemory — conversations, documents, files, URLs. We extract the memories automatically.”
   • [claimed-docs] “Use `searchMode: "hybrid"` for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Create memories directly without going through the document ingestion workflow. Memories are embedded and immediately searchable.”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [community] “It's a shame it is unable to store large content from links. I tried it with a tutorial link so that I could eventually master the Nix langu…”

   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
   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

   Supermemory~partialclaimed5/10

   Supermemory documents a customId mechanism that lets you resend content and have it 'intelligently process only what's new' (supermemory-docs-30), and memory-graph docs show new facts (e.g., new employer) being added on top of old ones (supermemory-docs-27, supermemory-docs-37), suggesting some update/graph-merge behavior. But the product's own comparison page explicitly admits it lacks 'temporal truth' — contradictory facts like 'loved Adidas' then 'switched to Puma' both remain equally relevant rather than the newer one superseding the older (supermemory-docs-48) — a direct, first-party admission that conflicting memories are not reliably resolved. missing for 10: no documented mechanism for detecting/resolving direct factual contradictions (vs. just adding new facts or updating same-ID documents), no independent/community verification of merge or supersession behavior in practice.

   • [claimed-docs] “Use customId to update existing documents or conversations. When you send content with the same customId, Supermemory intelligently processe…”
   • [claimed-docs] “No temporal truth ("loved Adidas" then "switched to Puma", both stay equally "relevant")”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “await client.add({ content: "Alex mentioned he just started at Stripe", containerTag: "user_123" });”

   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 to Supermemory
   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

   Supermemory✓fullclaimed8/10

   Docs explicitly document hybrid search mode (searchMode: "hybrid" combining memories and document chunks), metadata filtering by custom properties like category/status/date, and container-tag scoping as retrieval controls beyond plain similarity search. Multiple retrieval modes (document RAG, memory graph traversal, user profile) are also documented as selectable. missing for 10: no explicit mention of a dedicated reranking feature/parameter, and no independent/hands-on corroboration of these filtering/hybrid modes working as described.

   • [claimed-docs] “Use `searchMode: "hybrid"` for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Use searchMode: "hybrid" for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Metadata Filtering ... Query memories by custom properties like category, status, or date”
   • [claimed-docs] “Retrieve three ways — document search (RAG), memory graph traversal, and user profile”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”

   proof ↗⚑ flag

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

   weight 2 · round to Zep
   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

   Supermemory~partialprobed6/10

   Docs show a comprehensive REST API (add/search/memory operations, container tags, user profiles, connectors) with official TS/Python clients, and note that app.supermemory.ai is just the consumer UI on the same engine (implying API-first parity). However, some workflows (e.g. deletion) are described as done 'via the API / console workf[low]', suggesting console-only steps exist, and a live probe found no discoverable OpenAPI spec, undercutting full API self-service. missing for 10: explicit statement/evidence that every UI action (connector setup, buckets, profile management, deletion) is fully API-equivalent, and a public OpenAPI/schema reference confirming complete API surface.

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [claimed-docs] “app.supermemory.ai is the consumer product on the same engine — not where you mint API keys.”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. When the user requests deletion, delete that container's content via the API / console w…”
   • [claimed-docs] “Connect external platforms to automatically sync documents into supermemory. Supported connectors include Google Drive, Gmail, Notion, OneDr…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.supermemory.ai/openapi.json, https://docs.supermemory.ai/swagger.json, https://docs.sup…”

   proof ↗⚑ flag

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

   weight 3 · round to Zep
   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

   Supermemory—none0/10

   The docs describe ingestion, search, self-hosting, and API access, but no citation documents a bulk data-export feature or open-format export tool that would let a user extract all stored memories and leave the platform. Self-hosting (docs-7/16/31/44) shows you can run your own instance, but that is not the same as exporting existing hosted data in an open format.

   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform ... as a single self-contained binary.”
   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.supermemory.ai/openapi.json, https://docs.supermemory.ai/swagger.json, https://docs.sup…”

   proof ↗⚑ flag

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

   weight 2 · round to Zep
   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

   Supermemory—none0/10

   There is a public GitHub repository (supermemoryai/supermemory) referenced, and self-hosting docs describe a distributable binary, but no evidence pack item states an open-source license, and the self-hosting binary is described as a closed compiled artifact rather than published source. Missing for 10: any explicit license file/name, evidence the GitHub repo contains the actual product source (vs. docs/SDK), and confirmation the self-hosted binary corresponds to inspectable open-licensed code.

   • [github] “Connectors Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “State-of-the-art memory, running on your machine. One binary, zero config.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Supermemory
   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

   Supermemory✓fullclaimed8/10

   Docs explicitly document a self-hosting mode running the same memory engine as a single self-contained binary with local graph engine, embeddings, and LLM, requiring no Docker or config, and no data leaving the building. Missing for 10: independent hands-on verification of the self-host binary working, and details on feature parity/limitations vs hosted version.

   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “Local graph engine, local embeddings, local LLM. Your data never leaves the building.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform ... as a single self-contained binary.”
   • [claimed-docs] “No Docker. No database to provision. No config files. It boots in seconds with everything built in”
   • [claimed-docs] “State-of-the-art memory, running on your machine. One binary, zero config.”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   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 to Supermemory
   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

   Supermemory~partialclaimed4/10

   A dedicated pricing.md page is referenced with some billing mechanics (unique-content-only billing, prompt-cache discount, plan tiers like 'Max plan' gating connectors, SOC2/HIPAA/self-host options), but no evidence pack citation actually shows a free-tier allotment or explicit per-unit dollar rates. Missing for 10: explicit free-tier limits, published per-unit/usage pricing figures, and any independent corroboration of the pricing page's numbers.

   • [claimed-docs] “only unique content we ingest is billed; repeats cost nothing (100% prompt-cache discount, baked in).”
   • [claimed-docs] “Google Drive, Notion & OneDrive connectors”
   • [claimed-docs] “Max Plan Required: The Gmail connector is available on Max plan and above.”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   proof ↗⚑ flag

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

   weight 2 · round to Zep
   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

   Supermemory~partialclaimed4/10

   Supermemory offers a self-hosted binary option ("data never leaves the building") and lists SOC2/HIPAA BAA/self-hosted as compliance options, which lets an org control the physical location of data by running it on their own infrastructure, but there is no documented feature to choose a specific region/data-residency setting within the hosted SaaS offering itself. missing for 10: explicit region/residency selection controls in the hosted product, documentation of where hosted data is stored geographically, and any multi-region deployment options.

   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform ... as a single self-contained binary.”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   proof ↗⚑ flag

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

   weight 3 · round to Supermemory
   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

   Supermemory~partialclaimed5/10

   Supermemory offers a self-hosted deployment where 'your data never leaves the building' with local embeddings/LLM (supermemory-docs-8, supermemory-docs-16), which implicitly prevents data from reaching any third-party model training pipeline, and it advertises SOC2/HIPAA compliance (supermemory-docs-52). However, there is no explicit policy statement for the hosted/cloud platform about not training on customer data or an opt-out toggle. missing for 10: explicit no-training/data-use policy for the hosted SaaS offering, independent verification of self-host data isolation claims.

   • [claimed-docs] “Local graph engine, local embeddings, local LLM. Your data never leaves the building.”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform ... as a single self-contained binary.”
   • [claimed-docs] “State-of-the-art memory, running on your machine. One binary, zero config.”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Zep
   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

   Supermemory~partialclaimed6/10

   Docs explicitly document a deletion workflow scoped by container tags (delete a user's/tenant's content via API/console) plus self-hosting for full data control and SOC2/HIPAA compliance options, giving users a documented path to control retention and deletion. However, there's no evidence of granular per-memory deletion controls, retention policy settings (auto-expiry/TTL), or an end-user-facing UI for self-service deletion — the workflow described is developer/console-mediated only. Missing for 10: user-facing self-service deletion UI, configurable retention/expiry policies, and independent confirmation that deletion actually purges data from backups/indexes.

   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. When the user requests deletion, delete that container's content via the API / console w…”
   • [claimed-docs] “Scope each end-user (or tenant) to a **container tag**. When the user requests deletion, delete that container's content via the API / conso…”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag.”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. 2. When the user requests deletion, delete that container's content via the API / consol…”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”
   • [claimed-docs] “Supermemory runs on your own hardware. It's the same memory engine behind the hosted platform... as a single self-contained binary.”
   • [claimed-docs] “Local graph engine, local embeddings, local LLM. Your data never leaves the building.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Supermemory—none0/10

   No evidence pack item addresses telemetry opt-out or usage-tracking controls for Supermemory; docs cover security/compliance (SOC 2, HIPAA) and self-hosting but never mention a telemetry toggle or analytics opt-out mechanism.

   ⚑ 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
   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

   Supermemory—none0/10

   No evidence in the pack cites any documented latency targets or measured p50/p95 numbers for retrieval; docs discuss features like hybrid search, self-hosting, and MemoryBench for benchmarking against competitors, but no concrete performance figures are given. Missing for 10: published latency SLAs/targets, measured p50/p95 benchmark numbers, or any performance dashboard/report.

   ⚑ flag

Scale

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

   weight 2 · round drawn
   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

   Supermemory—none0/10

   Docs describe ingestion mechanics (raw content ingestion, customId dedup, connectors with webhooks, automatic extraction) but there is no mention of a batch/async ingestion API, job IDs, or an endpoint/mechanism to check the status of background memory-processing operations — the evidence pack contains no support for this platform-engineer-facing capability. missing for 10: batch ingestion API, async job/task status endpoint, documentation of processing queue or webhook completion callbacks.

   • [claimed-docs] “Send any raw content to Supermemory — conversations, documents, files, URLs. We extract the memories automatically.”
   • [claimed-docs] “Use customId to update existing documents or conversations. When you send content with the same customId, Supermemory intelligently processe…”
   • [claimed-docs] “Connect external platforms to automatically sync documents into supermemory. Supported connectors include Google Drive, Gmail, Notion, OneDr…”
   • [github] “Connectors Google Drive · Gmail · Notion · OneDrive · GitHub — auto-sync with real-time webhooks.”

   proof ↗⚑ 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
   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

   Supermemory✓fullprobed8/10

   Supermemory ships an official MCP server explicitly described as giving 'every MCP-compatible assistant a shared memory layer,' which covers Claude, ChatGPT, Cursor and other MCP clients, plus container-tag scoping to keep the shared memory user-specific and natural-language tool selection without code. Missing for 10: explicit named walkthroughs/screenshots for each specific assistant (Claude, ChatGPT, Cursor) connecting simultaneously, and independent hands-on confirmation that cross-tool memory sharing works smoothly in practice.

   • [claimed-docs] “Supermemory MCP gives every MCP-compatible assistant a shared memory layer, so technical and non-technical teams can collaborate with AI usi…”
   • [claimed-docs] “Ask naturally. The assistant selects the right Supermemory tool without requiring code or tool names.”
   • [claimed-docs] “A space keeps a team's documents, memories, and profile context focused, so AI retrieves the right knowledge without mixing unrelated work.”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [probe] “official MCP server documented at https://supermemory.ai/docs/supermemory-mcp/mcp”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag.”

   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 to Zep
   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

   Supermemory—none0/10

   The evidence pack documents official TypeScript/Python SDKs, an MCP server, a CLI setup flow, and third-party connectors (Google Drive, Gmail, Notion, OneDrive, GitHub) but contains no mention of first-party integrations for LangChain, LangGraph, CrewAI, or the Vercel AI SDK specifically. Since a memory-layer product plausibly could ship such framework adapters, absence of evidence here is 'none' rather than 'na'.

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [claimed-docs] “Set up coding agents to integrate Supermemory — CLI, skill, and docs MCP.”
   • [claimed-docs] “Supermemory MCP gives every MCP-compatible assistant a shared memory layer, so technical and non-technical teams can collaborate with AI usi…”

   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
   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

   Supermemory—none0/10

   The evidence pack shows generic SDKs, connectors (Drive, Gmail, Notion, etc.), MCP integration, and self-hosting, but nowhere mentions LiveKit, Pipecat, ElevenLabs, or any real-time voice pipeline integration, latency benchmarks, or streaming APIs suited for live conversation. No documented voice-pipeline integration exists in the pack.

   ⚑ flag

Sdks

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

   weight 2 · round to Supermemory
   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

   Supermemory~partialclaimed6/10

   Docs explicitly confirm official TypeScript (npm install supermemory) and Python (pip install supermemory) SDKs wrapping the same API, with code examples shown mainly in TS/JS (client.add, client.search). There's no direct evidence of Python-specific code samples or confirmation the Python SDK has full feature parity (e.g., container tags, hybrid search, profiles) documented equivalently. Missing for 10: Python code examples demonstrating equivalent memory operations, explicit parity statement across SDKs, independent developer corroboration of Python SDK usage.

   • [claimed-docs] “Official clients wrap this API: TypeScript: npm install supermemory Python: pip install supermemory”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “Use searchMode: "hybrid" for best results. It searches both memories and document chunks, returning the most relevant content.”

   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
   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

   Supermemory~partialclaimed4/10

   Supermemory offers a single-call hybrid search that returns relevant memories/document chunks and related memories, and user profiles that are 'always ready' without a search call, which covers assembling relevant context in one call — but no docs mention a token-budget parameter or explicit prompt-sized context-block output. missing for 10: explicit token-budget/max-token control on retrieval, evidence of a single call returning a pre-formatted prompt-ready block combining profile+graph+documents together.

   • [claimed-docs] “Use `searchMode: "hybrid"` for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Use searchMode: "hybrid" for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “No search needed — comprehensive user info always ready”
   • [claimed-docs] “No search needed — comprehensive user info always ready Profiles update as users interact with your system”
   • [claimed-docs] “Retrieve three ways — document search (RAG), memory graph traversal, and user profile”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”

   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
   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

   Supermemory~partialclaimed7/10

   Supermemory ingests raw conversations and auto-extracts memories, then exposes them via hybrid search, memory graph traversal, and always-ready user profiles that update as users interact — this gives an agent a way to recall prior conversation context and continue it (docs-1, docs-2, docs-3, docs-15, docs-23, docs-33). However there is no explicit 'session/thread summary' artifact or transcript-resume feature documented, and no hands-on/independent evidence of an agent actually resuming a specific thread using this data. Missing for 10: a dedicated session-summary or thread-resume API/feature, and independent verification that agents successfully pick up prior conversations using this context.

   • [claimed-docs] “Send any raw content to Supermemory — conversations, documents, files, URLs. We extract the memories automatically.”
   • [claimed-docs] “Use `searchMode: "hybrid"` for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “No search needed — comprehensive user info always ready”
   • [claimed-docs] “User profiles are **automatically maintained collections of facts about your users** that Supermemory builds from all their interactions.”
   • [claimed-docs] “Retrieve three ways — document search (RAG), memory graph traversal, and user profile”
   • [claimed-docs] “No search needed — comprehensive user info always ready Profiles update as users interact with your system”
   • [claimed-docs] “Use customId to update existing documents or conversations. When you send content with the same customId, Supermemory intelligently processe…”

   proof ↗⚑ flag

Ingestion

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

   weight 2 · round to Zep
   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

   Supermemory!disputedcontradicted6/10

   First-party docs strongly document ingesting raw documents, files, URLs, JSON-like content, code, PDFs, images, and connectors (Google Drive, Notion, OneDrive, Gmail, GitHub) beyond chat transcripts, with customId-based document updates and content-type-specific extraction. However, a hands-on community report describes a concrete failure — a large-content link being rejected with a 'content too large' error — directly contradicting the 'just upload, it just works' ingestion claim for real-world documents. Missing for 10: resolution/acknowledgment of the size-limit failure, and independent corroboration of large-scale JSON/business-data ingestion succeeding in practice.

   • [claimed-docs] “Send any raw content to Supermemory — conversations, documents, files, URLs. We extract the memories automatically.”
   • [claimed-docs] “Supermemory automatically extracts and indexes content from various formats.”
   • [claimed-docs] “Connect external platforms to automatically sync documents into supermemory. Supported connectors include Google Drive, Gmail, Notion, OneDr…”
   • [github] “Multi-modal Extractors | PDFs, images (OCR), videos (transcription), code (AST-aware chunking). Upload and it works.”
   • [claimed-docs] “Use customId to update existing documents or conversations. When you send content with the same customId, Supermemory intelligently processe…”
   • [community] “It's a shame it is unable to store large content from links. I tried it with a tutorial link so that I could eventually master the Nix langu…”

   proof ↗⚑ flag

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

   weight 1 · round to Supermemory
   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

   Supermemory✓fullclaimed8/10

   GitHub docs explicitly list multi-modal extractors for PDFs and images (OCR) with 'upload and it works,' and docs describe raw file ingestion plus hybrid search/recall across document chunks and memories. Missing for 10: independent hands-on verification specifically for image/PDF recall (the only community evidence found concerns large link content failing, not files/images).

   • [github] “Multi-modal Extractors | PDFs, images (OCR), videos (transcription), code (AST-aware chunking). Upload and it works.”
   • [claimed-docs] “Send any raw content to Supermemory — conversations, documents, files, URLs. We extract the memories automatically.”
   • [claimed-docs] “Supermemory automatically extracts and indexes content from various formats.”
   • [claimed-docs] “Use `searchMode: "hybrid"` for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Use searchMode: "hybrid" for best results. It searches both memories and document chunks, returning the most relevant content.”
   • [claimed-docs] “Just upload — Supermemory handles the rest ... No chunking strategies to configure. No embedding models to choose. It just works.”

   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
   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

   Supermemory~partialclaimed4/10

   Supermemory provides container-tag based tenant isolation (hard namespace boundaries) and SOC2/HIPAA BAA compliance claims, which partially address data segregation and enterprise trust, but there is no documented role-based access control, granular read/write policies, or audit-log capability for tracking who accessed or modified memories. Missing for 10: explicit RBAC/ACL system, audit trail/logging of access events, and evidence of enforcement beyond tag-scoped isolation.

   • [claimed-docs] “A container tag is a hard boundary — its own namespace. Memories in one tag are never returned by a search scoped to another tag.”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. When the user requests deletion, delete that container's content via the API / console w…”
   • [claimed-docs] “SOC 2 · HIPAA BAA · self-hosted option”

   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 to Supermemory
   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

   Supermemory✓fullclaimed8/10

   Docs clearly document container tags as hard isolation boundaries per user/agent/app, with explicit statements that tag-scoped searches never return cross-tenant memories and code examples showing containerTag usage for scoping and deletion. missing for 10: independent/hands-on verification of isolation guarantees beyond vendor docs, and no detail on cross-tenant leakage testing or edge cases (e.g., shared profiles/buckets interacting with tags).

   • [claimed-docs] “A container tag is a hard boundary — its own namespace. Memories in one tag are never returned by a search scoped to another tag.”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [claimed-docs] “await client.add({ content: "The user loves Paris.", containerTag: "user_123" });”
   • [claimed-docs] “const results = await client.search({ q: "where does Alex work?", containerTag: "user_123", include: { relatedMemories: true }, });”
   • [claimed-docs] “await client.add({ content: "Alex mentioned he just started at Stripe", containerTag: "user_123" });”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. When the user requests deletion, delete that container's content via the API / console w…”
   • [claimed-docs] “Scope each end-user (or tenant) to a **container tag**. When the user requests deletion, delete that container's content via the API / conso…”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag.”
   • [claimed-docs] “Scope each end-user (or tenant) to a container tag. 2. When the user requests deletion, delete that container's content via the API / consol…”

   proof ↗⚑ flag

Sharing

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

   weight 1 · round to Supermemory
   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

   Supermemory~partialclaimed7/10

   Docs describe container tags as hard-boundary namespaces for per-user/tenant isolation (private memory) and separately describe 'spaces' and the Supermemory MCP as a shared memory layer letting teams collaborate on the same authorized context, which together map to the private-vs-shared story. However there's no explicit example of selectively promoting specific memories from a private container into a shared team space, nor documented fine-grained ACL/role controls for partial sharing. missing for 10: worked example of mixed private+shared memory for the same agent/user, explicit role-based access control docs, independent/hands-on verification of isolation guarantees.

   • [claimed-docs] “A container tag is a hard boundary — its own namespace. Memories in one tag are never returned by a search scoped to another tag.”
   • [claimed-docs] “every memory tagged with `user_alex` lives in its own isolated space, completely separate from memories tagged `user_jordan`”
   • [claimed-docs] “A space keeps a team's documents, memories, and profile context focused, so AI retrieves the right knowledge without mixing unrelated work.”
   • [claimed-docs] “Supermemory MCP gives every MCP-compatible assistant a shared memory layer, so technical and non-technical teams can collaborate with AI usi…”
   • [claimed-docs] “Scope each end-user (or tenant) to a **container tag**. When the user requests deletion, delete that container's content via the API / conso…”

   proof ↗⚑ flag