Mem0 vs Supermemory

Agent access

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

   weight 2 · round to Mem0
   Mem0✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 to Mem0
   Mem0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 to Supermemory
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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 userOperate the product with natural-language commands

   weight 2 · round to Supermemory
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 to Mem0
   Mem0~partialprobed4/10

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

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

   proof ↗⚑ flag

   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 to Mem0
   Mem0✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

   ⚑ flag

   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
   Mem0—none0/10

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

   ⚑ flag

   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
   Mem0~partialclaimed3/10

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

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

   proof ↗⚑ flag

   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 to Mem0
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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
   Mem0~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 to Mem0
   Mem0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialcommunity7/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

   ⚑ flag

   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 drawn
   Mem0✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialprobed6/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

   ⚑ flag

   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 drawn
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

   ⚑ flag

   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 drawn
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

   ⚑ flag

   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 drawn
   Mem0—none0/10

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

   ⚑ flag

   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
   Mem0—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 Mem0
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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 Supermemory
   Mem0~partialprobed6/10

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

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

   proof ↗⚑ flag

   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 Supermemory
   Mem0—none0/10

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

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

   proof ↗⚑ flag

   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
   Mem0—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Mem0~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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
   Mem0✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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
   Mem0~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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