Mem0 vs Cognee

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

   Cognee✓fullprobed8/10

   A live llms.txt file is confirmed via direct probe (HTTP 200) at docs.cognee.ai/llms.txt, and the docs site provides extensive agent-oriented markdown documentation (core-concepts, CLI, MCP, API reference pages all served as .md), which an agent could be pointed at directly. missing for 10: no evidence of a dedicated agents.txt/llms-full.txt variant or explicit guidance/examples showing an agent being pointed at llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.cognee.ai/llms.txt # Cognee Documentation > Cognee turns documents, code, and application data int…”
   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Python file”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”

   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

   Cognee~partialprobed6/10

   Cognee offers a Python API, a CLI (cognee-cli), and a Docker container that can all be scripted/automated headlessly without a UI, and 'cognee-cli demo' explicitly works with no network access, suggesting CI-friendliness. However there is no explicit CI/CD example, no documented non-interactive flags for auth/config in pipelines, and no independent report of someone running it in CI. missing for 10: explicit CI/CD pipeline example or GitHub Actions integration, documented non-interactive/headless auth flow, independent hands-on confirmation of CI usage.

   • [claimed-docs] “lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Python file”
   • [claimed-docs] “The cognee-cli command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Py…”
   • [claimed-docs] “The `cognee-cli` command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a …”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “`cognee-cli demo` gives you a working example with **no API key and no embedding provider**, on a machine with no network access”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [probe] “official CLI documented at https://docs.cognee.ai/cognee-cli/overview”

   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

   Cognee✓fullprobed8/10

   Cognee ships an official MCP server (cognee-mcp) documented as bringing persistent AI memory via MCP, connecting to Claude, Cursor, Cline, Continue, and Codex, confirmed by both docs and an independent probe. Missing for 10: independent/hands-on user reports validating the MCP server's real-world reliability beyond vendor docs.

   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”
   • [claimed-docs] “You access them through MCP-compatible AI assistants like Cursor, Claude Desktop, Continue, Cline, and Codex.”
   • [probe] “official MCP server documented at https://docs.cognee.ai/cognee-mcp/mcp-overview”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Cognee✓fullprobed8/10

   Cognee ships an official `cognee-cli` documented in first-party docs, supporting core memory operations (remember, enrich, ask questions) from the terminal without opening Python, plus cloud push, report generation, and an offline demo mode. This is a genuine, well-documented CLI tailored to its agentic/memory workflows. Missing for 10: independent/hands-on community verification of the CLI's reliability beyond vendor docs.

   • [claimed-docs] “lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Python file”
   • [claimed-docs] “The cognee-cli command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Py…”
   • [claimed-docs] “The `cognee-cli` command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a …”
   • [claimed-docs] “`cognee-cli push` uploads a local dataset's knowledge graph to Cognee Cloud”
   • [claimed-docs] “`cognee-cli report` writes a Graph Insight Report describing what a dataset's graph contains”
   • [claimed-docs] “`cognee-cli demo` gives you a working example with **no API key and no embedding provider**, on a machine with no network access”
   • [probe] “official CLI documented at https://docs.cognee.ai/cognee-cli/overview”

   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

   Cognee✓fullprobed7/10

   Cognee documents a public API surface across multiple layers: the Python SDK (.remember, .recall, .improve, .forget, python-api.md), a REST-style API reachable via the documented Docker container exposing port 8000 with an 'api-reference' section, and a CLI wrapping the same operations — all clearly documented for programmatic/agentic use. However the openapi probe found no machine-readable OpenAPI/swagger spec at expected paths, suggesting the 'documented public API' is prose/markdown rather than a formal spec, and there is no independent hands-on corroboration of API usage. Missing for 10: a discoverable OpenAPI/swagger schema, independent developer corroboration of API stability/usage.

   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”
   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cognee.ai/openapi.json, https://docs.cognee.ai/swagger.json, https://docs.cognee.ai/api…”

   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

   Cognee—none0/10

   Evidence shows dataset-scoped permissions for multi-user isolation, but there is no mention of scoped/least-privilege API credentials or API keys that an ai-native user could issue to an agent with restricted permissions. missing for 10: API key/credential issuance mechanism, scoping/least-privilege token model, documentation of credential lifecycle management.

   • [claimed-docs] “This system provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users o…”
   • [claimed-docs] “provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users or organizati…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Mem0
   Mem0✓fullprobed8/10

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

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

   proof ↗⚑ flag

   Cognee~partialprobed6/10

   Cognee documents a Python SDK with clear operations (.remember, .recall, .improve, .forget) and a CLI, giving AI-native users official building blocks, but the API reference lacks a discoverable OpenAPI/swagger spec (all probed endpoints 404) and there's no independent/hands-on corroboration of SDK usage beyond first-party docs. missing for 10: verifiable OpenAPI/REST SDK spec, independent developer corroboration of SDK reliability, multi-language SDK support beyond Python/CLI.

   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “The `.improve` operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “The cognee-cli command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Py…”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cognee.ai/openapi.json, https://docs.cognee.ai/swagger.json, https://docs.cognee.ai/api…”
   • [probe] “official CLI documented at https://docs.cognee.ai/cognee-cli/overview”

   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

   Cognee—none0/10

   No evidence anywhere in the pack mentions webhooks, event subscriptions, or push notifications; Cognee's integrations (Slack, GitHub, Linear) are described as data sources to ingest, not as an event/webhook subscription mechanism for users. This is a fair axis for an agentic memory/integration platform, so absence of evidence yields none.

   ⚑ flag

Agentic features

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

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

   Cognee~partialclaimed6/10

   Cognee's docs show AI-driven enrichment and insight generation: `.improve()` enriches the knowledge graph with new AI-extracted entities/relations, `cognee-cli report` generates a 'Graph Insight Report' describing what a dataset contains, and `recall()` auto-classifies queries to surface relevant information. These support 'AI-generated insights' but the story's 'suggestions' aspect (e.g., proactive recommendations) isn't directly evidenced, and there's no independent/hands-on validation of insight quality. missing for 10: explicit suggestion/recommendation feature, third-party validation of insight usefulness.

   • [claimed-docs] “`cognee-cli report` writes a Graph Insight Report describing what a dataset's graph contains”
   • [claimed-docs] “The `.improve` operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “The .improve operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “Use `improve()` after Remember when you want to enrich an existing graph further. Use it at the end of a chat or agent session to bridge sho…”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “The `.recall` operation is the main retrieval entry point in Cognee v1.0. It searches memory using the best available source for the request…”

   proof ↗⚑ flag

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

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

   Cognee✓fullprobed7/10

   Cognee's `.recall` operation auto-classifies natural-language queries to pick a retrieval strategy, the CLI lets users 'remember data, enrich memory, and ask questions' from the terminal without writing code, and the MCP server exposes these operations to AI assistants (Claude, Cursor, Cline) so an AI-native user can drive Cognee via natural language through those chat interfaces. This directly supports NL-driven operation of memory/recall workflows. Missing for 10: independent/hands-on confirmation that free-form natural-language commands (beyond structured queries) are parsed correctly, and explicit CLI examples showing raw NL command syntax rather than just query-answering.

   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Python file”
   • [claimed-docs] “The cognee-cli command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Py…”
   • [claimed-docs] “The `cognee-cli` command lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a …”
   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”
   • [claimed-docs] “You access them through MCP-compatible AI assistants like Cursor, Claude Desktop, Continue, Cline, and Codex.”
   • [probe] “official MCP server documented at https://docs.cognee.ai/cognee-mcp/mcp-overview”
   • [probe] “official CLI documented at https://docs.cognee.ai/cognee-cli/overview”

   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

   Cognee—none0/10

   The docs mention an 'api-reference' section but only show static Docker run commands, not an interactive, runnable API console; explicit probes for OpenAPI/Swagger specs all returned 404, indicating no interactive API reference exists. Missing for 10: any interactive/runnable API explorer (e.g., Swagger UI, Postman collection, live code sandbox) and independent confirmation of one working.

   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cognee.ai/openapi.json, https://docs.cognee.ai/swagger.json, https://docs.cognee.ai/api…”

   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

   Cognee—none0/10

   Cognee has an 'api-reference' section referencing a REST API and Docker deployment, but a direct probe for OpenAPI/Swagger specs at all standard locations (openapi.json, swagger.json, etc.) returned 404s, and no documentation page links to a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cognee.ai/openapi.json, https://docs.cognee.ai/swagger.json, https://docs.cognee.ai/api…”
   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

   Cognee supports local-only operation via Docker and cognee.start_ui() for dev/testing (docs-7, docs-26, docs-10/23), plus a cognee-cli demo mode that runs with no API key and no network access (docs-44), and dataset-scoped permissions/isolation (docs-9/25) that could keep test datasets separate from production ones. However, there's no explicit 'sandbox environment' concept, staging/prod environment separation, or documented guarantee that testing never touches production data stores. missing for 10: explicit sandbox/staging environment feature, documented prod-data isolation guarantee, independent confirmation of safe test workflows.

   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “`cognee-cli demo` gives you a working example with **no API key and no embedding provider**, on a machine with no network access”
   • [claimed-docs] “This system provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users o…”
   • [claimed-docs] “you can also run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”

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

   Cognee—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; the OpenAPI probe returned 404s for all candidate spec locations, and no docs mention version support windows or deprecation timelines. Missing for 10: any versioning scheme documentation, explicit deprecation policy, changelog/migration guides for breaking changes.

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

   Docs show several bulk-oriented affordances: ingesting multiple text/files/URLs in a single `.remember` call, dataset-level or full-user `.forget` cleanup instead of item-by-item deletion, and GitHub-org-wide code indexing across every repo. However, there's no explicit bulk/batch API for arbitrary large-scale multi-item operations with pagination, concurrency, or throughput guarantees, and no independent evidence of bulk performance at scale. Missing for 10: dedicated batch API documentation, evidence of large-scale bulk throughput/limits, independent hands-on validation of bulk operations.

   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”
   • [claimed-docs] “Remove a data item, an entire dataset, or all memory for the current user.”
   • [claimed-docs] “Connect a GitHub organization and index every covered repository into the code graph.”

   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

   Cognee—none0/10

   Cognee's evidence pack shows manual operations (remember, recall, improve, forget) invoked via API, CLI, or MCP calls, but no evidence of a rules/trigger engine that fires actions automatically on events (e.g., webhooks, event listeners, conditional automations). This is a plausible axis for a memory/knowledge-graph platform, but no supporting capability is documented.

   ⚑ flag

Forgetting

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

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

   Cognee✓fullclaimed8/10

   The `.forget` operation is documented as Cognee's unified deletion command supporting single data item deletion, per-dataset deletion, and full cleanup of everything the current user can delete, directly matching the platform-engineer's need for granular-to-full erasure. Combined with dataset-scoped permissions/isolation, this supports privacy-driven deletion per user. Missing for 10: independent/hands-on verification that forget() actually purges data from graph+vector+storage layers reliably, and explicit per-entity (vs per-dataset) deletion granularity confirmation.

   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”
   • [claimed-docs] “Remove a data item, an entire dataset, or all memory for the current user.”
   • [claimed-docs] “This system provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users o…”

   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

   Cognee—none0/10

   The docs describe sessions as short-term memory caches and .forget as manual deletion, but nowhere do they mention TTL, expiration dates, automatic decay, or recency-weighted scoring that would make stale facts stop surfacing automatically.

   • [claimed-docs] “cognee.remember(data, session_id="my_session") — writes content directly into the session cache for fast retrieval.”
   • [claimed-docs] “A session is Cognee's short-term memory for a specific user. It is identified by `(user_id, session_id)` and stores an ordered list of recen…”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”

   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

   Cognee—none0/10

   The docs describe rich operations (remember, recall, improve, forget) and a CLI with `push` (upload to Cognee Cloud) and `report` (human-readable Graph Insight Report), but there is no documented export command or API that dumps memory/graph data into a portable machine-readable format (e.g., JSON, GraphML) for migration off Cognee. Being open-source/self-hostable reduces lock-in in principle, but does not itself satisfy an explicit data-export requirement, and a community comment even flags a 'trapped in their service' feeling. Missing for 10: a documented export/dump command or API returning graph/vector data in a standard interchange format, and any independent confirmation that exported data can be re-imported elsewhere.

   • [claimed-docs] “`cognee-cli push` uploads a local dataset's knowledge graph to Cognee Cloud”
   • [claimed-docs] “`cognee-cli report` writes a Graph Insight Report describing what a dataset's graph contains”
   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [community] “Cognee's knowledge-graph design (ontology, LLM extraction, dedup) 'looks like such a heavy setup that adds a lot of friction and silos... fe…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cognee.ai/openapi.json, https://docs.cognee.ai/swagger.json, https://docs.cognee.ai/api…”

   proof ↗⚑ flag

Self host

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

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

   Cognee~partialclaimed7/10

   Docs confirm Cognee is open source and can run fully locally: Docker quick-start, `cognee.start_ui()` running the UI/pipelines on-machine with no account, and `cognee-cli demo` working with no API key, no embedding provider, and no network access. This strongly supports local, cloud-free operation, but the evidence doesn't explicitly document configuring local LLMs/embedding models for full production use (beyond the offline demo), nor independent hands-on confirmation of a no-cloud deployment at scale. missing for 10: explicit doc/example wiring Cognee to local LLM/embedding backends for real workloads, and independent verification of fully offline operation beyond the demo command.

   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “you can also run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”
   • [claimed-docs] “Cognee Cloud gives you the full Cognee platform ... you can also run the UI and all pipelines entirely on your own machine for free, with no…”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”
   • [claimed-docs] “`cognee-cli demo` gives you a working example with **no API key and no embedding provider**, on a machine with no network access”

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

   Cognee✓fullclaimed8/10

   Docs explicitly confirm Cognee is open source and can be self-hosted via a single Docker run command, run locally with UI/pipelines with no account required, and pricing page states 'Run the full memory engine locally or on your own stack — free, forever.' This directly satisfies the platform-engineer self-host story. Missing for 10: independent hands-on verification of the Docker deployment working in production, and details on scaling/persistence configuration for self-hosted infra.

   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “you can also run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”

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

   Cognee✓fullcommunity8/10

   Cognee's core docs describe exactly this capability: `.remember` ingests data and 'extracts entities and builds the knowledge graph' automatically, `.recall` searches memory picking the best retrieval strategy, and ontologies link entity types/mentions to canonical concepts for well-defined entity-centric relationships. This directly supports multi-hop and entity-centric querying over a graph memory store. Missing for 10: independent/hands-on benchmark evidence of actual multi-hop QA accuracy, and the one community mention raises friction/scale concerns (not a functional dispute) rather than confirming multi-hop correctness.

   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “The `.recall` operation is the main retrieval entry point in Cognee v1.0. It searches memory using the best available source for the request…”
   • [claimed-docs] “when you do not specify a search type, recall() classifies the query and picks the best retrieval strategy automatically.”
   • [claimed-docs] “An ontology is an optional RDF/OWL file you can provide to Cognee. It acts as a reference vocabulary, making sure that entity types...are li…”
   • [claimed-docs] “It acts as a reference vocabulary, making sure that entity types ("classes") and entity mentions ("individuals") extracted from your data ar…”
   • [community] “Cognee's knowledge-graph design (ontology, LLM extraction, dedup) 'looks like such a heavy setup that adds a lot of friction and silos... fe…”

   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

   Cognee—none0/10

   No evidence in the pack mentions temporal validity tracking, fact invalidation timestamps, or any mechanism to distinguish current vs. outdated facts; operations like .remember/.forget/.improve describe ingestion, deletion, and enrichment but not temporal versioning of facts.

   ⚑ flag

Schema customization

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

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

   Cognee~partialcommunity6/10

   Cognee documents an optional ontology mechanism (RDF/OWL file) that lets you map entity types and mentions to canonical, domain-specific concepts, which is a real form of schema customization. However, there is no evidence of a direct API for defining custom entity/edge type schemas outside of the ontology file, and community feedback flags the ontology/extraction setup as heavy and adding friction for smaller-scale customization. Missing for 10: documented API for defining custom node/edge types independent of RDF/OWL, examples of domain-specific schema customization, and hands-on validation that ontology customization works smoothly in practice.

   • [claimed-docs] “An ontology is an optional RDF/OWL file you can provide to Cognee. It acts as a reference vocabulary, making sure that entity types...are li…”
   • [claimed-docs] “It acts as a reference vocabulary, making sure that entity types ("classes") and entity mentions ("individuals") extracted from your data ar…”
   • [claimed-docs] “An ontology is an optional RDF/OWL file you can provide to Cognee. It acts as a reference vocabulary, making sure that entity types ... extr…”
   • [claimed-docs] “An ontology is an optional RDF/OWL file you can provide to Cognee. It acts as a reference vocabulary, making sure that entity types ("classe…”
   • [claimed-docs] “An **ontology** is an optional RDF/OWL file you can provide to Cognee. It acts as a **reference vocabulary**, making sure that entity types …”
   • [community] “Cognee's knowledge-graph design (ontology, LLM extraction, dedup) 'looks like such a heavy setup that adds a lot of friction and silos... fe…”

   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

   Cognee✓fullprobed8/10

   Cognee exposes explicit remember/recall/improve/forget operations as unified memory CRUD primitives, and ships an official MCP server so agents (Claude, Cursor, Cline, Codex, etc.) can invoke these as tools mid-conversation, plus a CLI/API for programmatic use. Missing for 10: independent/hands-on evidence of an agent actually performing add/search/update/delete calls in a live conversation, and no OpenAPI spec was found to confirm full API surface.

   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “The `.improve` operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”
   • [claimed-docs] “You access them through MCP-compatible AI assistants like Cursor, Claude Desktop, Continue, Cline, and Codex.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”
   • [probe] “official MCP server documented at https://docs.cognee.ai/cognee-mcp/mcp-overview”

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

   Cognee's ingestion pipeline automatically extracts entities and builds a knowledge graph rather than storing raw text verbatim (docs-16), and `.improve()` is explicitly designed to consolidate short-term session memory into permanent memory in the background of a session (docs-31, docs-19). However, both `.remember` and `.improve` are explicit, user/agent-invoked API calls rather than an autonomous decision process that judges salience on its own — there's no evidence of the system independently deciding what to discard vs. keep beyond structured extraction. missing for 10: evidence of autonomous/automatic triggering of consolidation without explicit calls, evidence of selective filtering of non-salient content vs. full extraction of everything ingested.

   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “Use `improve()` after Remember when you want to enrich an existing graph further. Use it at the end of a chat or agent session to bridge sho…”
   • [claimed-docs] “The .improve operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “A session is Cognee's short-term memory for a specific user. It is identified by `(user_id, session_id)` and stores an ordered list of recen…”

   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

   Cognee—none0/10

   No evidence pack item mentions benchmark results, LongMemEval, LoCoMo, or any published recall-accuracy metrics; all docs describe API features and operations without quantitative evaluation data.

   ⚑ 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

   Cognee✓fullcommunity8/10

   Cognee's docs directly evidence the story: `.remember` ingests conversation/session data (including session-scoped writes via session_id), `.recall` performs semantic/classified search over stored memory, and `.improve` explicitly bridges short-term session memory into permanent memory for cross-session persistence. MCP integration also lets AI assistants use this persistent memory across sessions. Missing for 10: independent/hands-on evidence of retrieval quality or recall accuracy in practice (only vendor docs, plus one skeptical community note about setup friction at small scale) and no first-party benchmark of semantic search precision.

   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “cognee.remember(data, session_id="my_session") — writes content directly into the session cache for fast retrieval.”
   • [claimed-docs] “when you do not specify a search type, recall() classifies the query and picks the best retrieval strategy automatically.”
   • [claimed-docs] “Use `improve()` after Remember when you want to enrich an existing graph further. Use it at the end of a chat or agent session to bridge sho…”
   • [claimed-docs] “A session is Cognee's short-term memory for a specific user. It is identified by `(user_id, session_id)` and stores an ordered list of recen…”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”
   • [community] “Cognee's knowledge-graph design (ontology, LLM extraction, dedup) 'looks like such a heavy setup that adds a lot of friction and silos... fe…”

   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

   Cognee~partialclaimed5/10

   Cognee documents `.forget` for deletion and `.improve` for enriching an existing graph after ingestion, plus ontology-based canonicalization to keep entity concepts consistent, which together imply some update/merge capability, but no doc explicitly describes automatic detection or resolution of contradictory facts, versioning, or supersession logic. missing for 10: explicit contradiction-detection/merge-resolution mechanism, before/after example of conflicting facts being reconciled, independent validation of update behavior.

   • [claimed-docs] “The `.improve` operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “The .improve operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “Use `improve()` after Remember when you want to enrich an existing graph further. Use it at the end of a chat or agent session to bridge sho…”
   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”
   • [claimed-docs] “Remove a data item, an entire dataset, or all memory for the current user.”
   • [claimed-docs] “An ontology is an optional RDF/OWL file you can provide to Cognee. It acts as a reference vocabulary, making sure that entity types...are li…”

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

   Cognee~partialclaimed5/10

   Docs state that recall() supports specifying a search type (with auto-classification as the default), implying developers can override the single fixed similarity mode, but the evidence never names specific modes like keyword/hybrid search, metadata filters, or reranking controls. Missing for 10: explicit documentation of metadata-filter parameters, named keyword/hybrid search types, and reranking configuration options.

   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “when you do not specify a search type, recall() classifies the query and picks the best retrieval strategy automatically.”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically.”
   • [claimed-docs] “The `.recall` operation is the main retrieval entry point in Cognee v1.0. It searches memory using the best available source for the request…”

   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

   Cognee~partialprobed6/10

   Cognee is fundamentally API/library-first: remember, recall, improve, and forget are documented as the core operations, and the CLI/MCP surfaces reuse the same underlying calls, suggesting close parity with what the optional browser UI exposes (upload, search, dataset management). However, there is no OpenAPI/swagger spec (probe-2 shows all candidate paths 404), and no explicit documentation confirming graph-visualization/exploration features in the UI have direct API equivalents. Missing for 10: a published OpenAPI/REST spec, explicit doc statement mapping every UI feature (e.g., graph visualization) to an API call, and independent confirmation of full UI/API parity.

   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “The .improve operation enriches an existing Cognee graph after data has already been ingested.”
   • [claimed-docs] “Upload data, explore knowledge graphs, run searches, and manage datasets through the browser.”
   • [claimed-docs] “Cognee Cloud gives you the full Cognee platform ... you can also run the UI and all pipelines entirely on your own machine for free, with no…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cognee.ai/openapi.json, https://docs.cognee.ai/swagger.json, https://docs.cognee.ai/api…”
   • [probe] “official CLI documented at https://docs.cognee.ai/cognee-cli/overview”

   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

   Cognee~partialclaimed5/10

   Cognee is explicitly open source and can be run fully locally with your own storage backend (docs-14, docs-23, docs-26), meaning your data never has to leave your infrastructure — a strong form of avoiding lock-in. However, there is no documented explicit 'export' command or open-format data dump feature; the closest is a Graph Insight Report (docs-12) which is a descriptive summary, not a full data export, and forget/delete operations (docs-18, docs-30) only remove data rather than export it. Missing for 10: a documented export/dump command producing open-format (e.g., JSON, RDF, CSV) files of the full graph/vector data, and any independent confirmation that self-hosted data is fully portable without proprietary lock-in.

   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “`cognee-cli report` writes a Graph Insight Report describing what a dataset's graph contains”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed5/10

   Cognee's pricing page explicitly states 'Cognee is open source. Run the full memory engine locally or on your own stack — free, forever,' confirming open-source availability, but no specific license (e.g. MIT/Apache) is named nor is a GitHub repository link or independent corroboration provided in the evidence pack. missing for 10: explicit license type/name, link to source repository, independent confirmation of license terms.

   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”

   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

   Cognee✓fullcommunity8/10

   Cognee is explicitly open source and can be self-hosted via Docker (single docker run command) or run entirely locally including UI/pipelines with no account required, and pricing page confirms 'Run the full memory engine locally or on your own stack — free, forever.' Community sentiment notes the knowledge-graph setup can feel heavy at small scale, but does not contradict self-hosting capability itself. Missing for 10: independent hands-on verification of a full self-hosted production deployment beyond docs/quick-start.

   • [claimed-docs] “Run Cognee container\ndocker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”
   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “you can also run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”
   • [community] “Cognee's knowledge-graph design (ontology, LLM extraction, dedup) 'looks like such a heavy setup that adds a lot of friction and silos... fe…”

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

   Cognee~partialclaimed4/10

   The pricing page confirms a free/open-source tier (self-host free forever) and lists some paid-tier features (integrations, code indexing), but no evidence shows per-unit or usage-based rates that would let a platform engineer project costs. missing for 10: documented per-unit/usage pricing rates, tiered price points, or a cost calculator.

   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “Data source integrations: Slack, Notion, Linear, Google Drive”
   • [claimed-docs] “Code indexing for your repos”

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

   Cognee is open-source and can be fully self-hosted (Docker, local UI, no account required), giving users complete control over where their data physically resides — a strong proxy for data residency. However, there is no documented region-selection feature within Cognee Cloud itself (e.g., choosing EU vs US data centers), so residency is achieved only via self-hosting, not via a first-class regional-storage option. Missing for 10: explicit multi-region cloud storage/selection controls, documented data-residency/compliance certifications (e.g., GDPR region pinning) for the hosted offering.

   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”
   • [claimed-docs] “Run Cognee locally using Docker for development, testing, and custom deployments.”
   • [claimed-docs] “Cognee Cloud gives you the full Cognee platform ... you can also run the UI and all pipelines entirely on your own machine for free, with no…”
   • [claimed-docs] “Quick start with Docker (single command): docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main”

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed5/10

   Cognee is open source and can run entirely locally with no account required (`cognee.start_ui()`, self-hosted Docker), meaning data never has to leave the user's infrastructure, which inherently prevents third-party training use. However, there is no explicit privacy policy statement addressing training-data use, especially for the Cognee Cloud option where data is pushed via `cognee-cli push` to a hosted service. Missing for 10: an explicit no-training-on-user-data policy statement, terms-of-service language for the cloud tier, and independent confirmation of this claim.

   • [claimed-docs] “Cognee is open source. Run the full memory engine locally or on your own stack — free, forever.”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”
   • [claimed-docs] “`cognee-cli push` uploads a local dataset's knowledge graph to Cognee Cloud”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

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

   Cognee✓fullclaimed8/10

   Cognee documents a unified `.forget` deletion command supporting single-item deletion, full dataset deletion, and full cleanup of everything a user can delete, giving explicit user-controlled retention/deletion granularity. This is backed by dedicated docs pages with concrete API semantics. Missing for 10: independent/hands-on verification of deletion behavior and no explicit data-retention policy/TTL documentation beyond the deletion API.

   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data.”
   • [claimed-docs] “Single data item deletion: remove one data item from a dataset. Dataset deletion: remove an entire dataset and its graph/vector data. Full c…”
   • [claimed-docs] “Remove a data item, an entire dataset, or all memory for the current user.”

   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

   Cognee—none0/10

   No evidence pack item addresses telemetry, usage tracking, or an opt-out mechanism; the docs cover ingestion, retrieval, deletion, CLI, MCP, and deployment but never mention analytics/telemetry settings.

   ⚑ 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

   Cognee—none0/10

   No evidence pack item documents any retrieval-latency targets, benchmarks, or measured p50/p95 numbers; docs describe features (recall, sessions, caching) qualitatively as 'fast' without quantified performance data.

   ⚑ 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

   Cognee—none0/10

   The evidence pack details Cognee's core ingestion (.remember), enrichment (.improve), and CLI/Docker deployment options, but nowhere describes asynchronous or batch ingestion pipelines, job queuing, or a way to check the status of background memory operations. Pipelines are mentioned only in passing (e.g., 'run the UI and all pipelines') without any status/monitoring API or async processing model documented.

   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using cognee.start_ui()”
   • [claimed-docs] “Cognee Cloud gives you the full Cognee platform ... you can also run the UI and all pipelines entirely on your own machine for free, with no…”
   • [claimed-docs] “run the UI and all pipelines entirely on your own machine for free, with no account required, using `cognee.start_ui()`”

   proof ↗⚑ flag

Agent memory

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

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

   Cognee~partialprobed7/10

   Cognee ships an official MCP server documented to connect Claude, Cursor, Cline, Continue, and Codex to the same persistent memory store, directly matching the 'shared memory across assistants' story. However, ChatGPT is never listed among supported MCP clients, and there is no independent/hands-on evidence confirming multi-tool memory sharing actually works in practice. Missing for 10: explicit ChatGPT/MCP support confirmation, independent verification of cross-tool memory sharing in real use.

   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”
   • [claimed-docs] “You access them through MCP-compatible AI assistants like Cursor, Claude Desktop, Continue, Cline, and Codex.”
   • [probe] “official MCP server documented at https://docs.cognee.ai/cognee-mcp/mcp-overview”

   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

   Cognee—none0/10

   The evidence shows Cognee integrates with MCP-compatible tools (Claude, Cursor, Cline, Continue, Codex) and offers a Python API, CLI, and Docker deployment, but there is no mention anywhere of first-party integrations with LangChain, LangGraph, CrewAI, or the Vercel AI SDK specifically.

   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”
   • [claimed-docs] “You access them through MCP-compatible AI assistants like Cursor, Claude Desktop, Continue, Cline, and Codex.”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”

   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

   Cognee—none0/10

   No evidence of any documented integration with voice pipeline frameworks like LiveKit, Pipecat, or ElevenLabs, nor any mention of real-time/low-latency voice conversation support. Cognee's integrations listed are MCP clients (Claude, Cursor, Cline), data sources (Slack, Notion, Linear, GitHub), and its own CLI/cloud UI — none address voice pipelines.

   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Connect Slack, GitHub, Linear to Cognee and help agents recall what your company knows.”
   • [claimed-docs] “Data source integrations: Slack, Notion, Linear, Google Drive”
   • [claimed-docs] “Connect a GitHub organization and index every covered repository into the code graph.”
   • [claimed-docs] “Install Cognee as a Linear agent that answers @mentions and delegated issues from memory, and index the workspace's issues.”

   proof ↗⚑ flag

Sdks

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

   weight 2 · round to Mem0
   Mem0~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Cognee~partialprobed3/10

   The evidence shows a rich, well-documented Python API (.remember, .recall, .improve, .forget, sessions, CLI, Docker) but there is no mention anywhere of a TypeScript/JavaScript SDK or equivalent memory API in another language — only Python and CLI/MCP integrations are documented. missing for 10: TypeScript SDK, cross-language API parity documentation, evidence of any non-Python client library.

   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “The `.forget` operation is the unified deletion command in Cognee v1.0.”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”
   • [claimed-docs] “lets you run Cognee from the terminal so you can remember data, enrich memory, and ask questions without opening a Python file”
   • [probe] “official CLI documented at https://docs.cognee.ai/cognee-cli/overview”

   proof ↗⚑ flag

Context assembly

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

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

   Cognee~partialclaimed5/10

   Cognee's `.recall()` operation retrieves relevant memories in a single call and automatically picks the best retrieval strategy, and session/caching docs describe assembling short-term memory for fast retrieval, satisfying the 'one call' and 'relevant memories' parts of the story. However, there is no documentation of token-budget management or explicit prompt-ready formatting of the returned context block. missing for 10: token-budget control/truncation, explicit prompt-formatted output examples.

   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically”
   • [claimed-docs] “when you do not specify a search type, recall() classifies the query and picks the best retrieval strategy automatically.”
   • [claimed-docs] “when you do not specify a search type, `recall()` classifies the query and picks the best retrieval strategy automatically.”
   • [claimed-docs] “The `.recall` operation is the main retrieval entry point in Cognee v1.0. It searches memory using the best available source for the request…”
   • [claimed-docs] “cognee.remember(data, session_id="my_session") — writes content directly into the session cache for fast retrieval.”
   • [claimed-docs] “A session is Cognee's short-term memory for a specific user. It is identified by `(user_id, session_id)` and stores an ordered list of recen…”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”

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

   Cognee~partialclaimed7/10

   Cognee's docs describe a concrete session-memory model (`(user_id, session_id)` short-term memory storing an ordered list of recent interactions) plus a `.improve` operation explicitly meant to 'bridge short-term session memory into permanent memory' and `.recall` to retrieve from it, which supports an agent resuming a past thread. However the docs describe raw retrieval/graph-enrichment rather than an explicit 'summary' artifact, and there's no independent/hands-on confirmation of this workflow. missing for 10: explicit session-summary generation feature, independent verification that recall/improve actually reconstructs prior conversation context in practice.

   • [claimed-docs] “cognee.remember(data, session_id="my_session") — writes content directly into the session cache for fast retrieval.”
   • [claimed-docs] “A session is Cognee's short-term memory for a specific user. It is identified by `(user_id, session_id)` and stores an ordered list of recen…”
   • [claimed-docs] “Use `improve()` after Remember when you want to enrich an existing graph further. Use it at the end of a chat or agent session to bridge sho…”
   • [claimed-docs] “The `.recall` operation is the main retrieval entry point in Cognee v1.0. It searches memory using the best available source for the request…”
   • [claimed-docs] “`cognee-cli report` writes a Graph Insight Report describing what a dataset's graph contains”

   proof ↗⚑ flag

Ingestion

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

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

   Cognee✓fullclaimed8/10

   Docs clearly show Cognee ingests text, files, URLs, JSON, and business data (Slack, Notion, Linear, Google Drive, GitHub) into a persistent knowledge graph via .remember and related pipelines, going well beyond chat transcripts, with ontology support for structured business data typing. Missing for 10: independent hands-on verification of ingestion across formats beyond docs, and no concrete example of JSON-specific ingestion walkthrough.

   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “Connect Slack, GitHub, Linear to Cognee and help agents recall what your company knows.”
   • [claimed-docs] “Data source integrations: Slack, Notion, Linear, Google Drive”
   • [claimed-docs] “Connect a GitHub organization and index every covered repository into the code graph.”
   • [claimed-docs] “Install Cognee as a Linear agent that answers @mentions and delegated issues from memory, and index the workspace's issues.”
   • [claimed-docs] “An ontology is an optional RDF/OWL file you can provide to Cognee. It acts as a reference vocabulary, making sure that entity types...are li…”

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

   Docs confirm ingestion of 'text, files, or URLs' via a single call (docs-16) and that `.remember`/`.recall` handle storage and retrieval of that content later (docs-1, docs-37), which covers the general 'files as memory inputs' claim, but no evidence explicitly confirms image or PDF parsing/support specifically, nor any hands-on example of recalling from a PDF/image. missing for 10: explicit documentation or example of PDF/image ingestion, independent verification that non-text file types are correctly parsed and recalled.

   • [claimed-docs] “Give Cognee text, files, or URLs. It ingests, chunks, extracts entities, and builds the knowledge graph for you in one call.”
   • [claimed-docs] “The `.remember` operation is the main ingestion entry point in Cognee v1.0. It stores information in memory with a single API call.”
   • [claimed-docs] “The `.recall` operation is the main retrieval entry point in Cognee v1.0. It searches memory using the best available source for the request…”
   • [claimed-docs] “Store data as permanent graph memory or fast session memory in one call.”

   proof ↗⚑ flag

Governance

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

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

   Cognee~partialclaimed5/10

   Cognee's multi-user mode provides dataset-scoped permissions and per-dataset storage for access isolation between users/orgs, which is a form of access control, but the docs give no detail on granular roles, policy definitions, or read/write ACL granularity, and there is no mention of audit logging or access history. missing for 10: role/policy definition mechanics, granular read/write ACLs, audit-log/trail evidence, independent corroboration of the permissions system in practice.

   • [claimed-docs] “This system provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users o…”
   • [claimed-docs] “provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users or organizati…”

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

   Cognee~partialclaimed7/10

   Cognee's docs describe a dedicated multi-user permissions system with dataset-scoped storage and access control, explicitly enabling isolation so multiple users/organizations share one instance without data leakage, and sessions are scoped per (user_id, session_id). This covers user-level tenancy well but doesn't explicitly document agent- or application-level scoping constructs, and there's no independent/hands-on test confirming isolation actually holds under load. Missing for 10: explicit agent/application-scoped isolation docs, independent verification of no cross-tenant leakage, and any audit/pen-test evidence.

   • [claimed-docs] “This system provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users o…”
   • [claimed-docs] “provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users or organizati…”
   • [claimed-docs] “A session is Cognee's short-term memory for a specific user. It is identified by `(user_id, session_id)` and stores an ordered list of recen…”
   • [claimed-docs] “cognee.remember(data, session_id="my_session") — writes content directly into the session cache for fast retrieval.”

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

   Cognee~partialclaimed7/10

   Cognee's multi-user mode explicitly provides dataset-scoped permissions and per-dataset storage so multiple users/orgs can share one instance while keeping data isolated, which maps directly to team vs private memory separation (cognee-docs-9/25). However, the docs describe isolation/access-control mechanics rather than a concrete worked example of selectively sharing one dataset across multiple agents while another stays private, and there's no independent/hands-on confirmation of this permission model in practice. Missing for 10: a documented example of cross-agent shared dataset access alongside private datasets, and independent verification of the permission system's real-world behavior.

   • [claimed-docs] “This system provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users o…”
   • [claimed-docs] “provides data isolation and access control through dataset-scoped permissions and per-dataset storage, enabling multiple users or organizati…”

   proof ↗⚑ flag