Supermemory vs Cognee

Agent access

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

   weight 2 · round drawn
   Supermemory✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to Cognee
   Supermemory~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Supermemory~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Cognee~partialclaimed4/10

   Cognee documents some autonomous integrations — a Linear agent that answers @mentions and processes delegated issues from memory, and automatic indexing of an entire GitHub org's repos into the code graph — which imply background, event-driven automation without manual invocation. However, there's no documentation of a general-purpose scheduling/trigger system, background job orchestration, or first-party 'automations' feature; most operations (.remember, .recall, .improve) are described as explicit API/CLI calls rather than autonomous background processes. Missing for 10: explicit scheduler/cron or trigger framework, broader examples of autonomous multi-step agent workflows, and independent confirmation the Linear/GitHub integrations run unattended in production.

   • [claimed-docs] “Install Cognee as a Linear agent that answers @mentions and delegated issues from memory, and index the workspace's issues.”
   • [claimed-docs] “Connect a GitHub organization and index every covered repository into the code graph.”
   • [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”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Supermemory—none0/10

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

   ⚑ flag

   Cognee—none0/10

   Cognee positions itself as a memory/knowledge-graph backend that other AI assistants (Claude, Cursor, Cline) connect to via MCP, not as a product with its own built-in assistant that users delegate tasks to. The closest hint is a Linear 'agent' integration that answers @mentions from memory, but this is a narrow third-party integration, not a built-in assistant inside Cognee itself, and no evidence shows a native chat/delegation interface within the core product.

   • [claimed-docs] “Install Cognee as a Linear agent that answers @mentions and delegated issues from memory, and index the workspace's issues.”
   • [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.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Supermemory✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 drawn
   Supermemory~partialclaimed7/10

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

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

   proof ↗⚑ flag

   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
   Supermemory!disputedcontradicted6/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 drawn
   Supermemory~partialclaimed7/10

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

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

   proof ↗⚑ flag

   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