Cognee vs Airweave

Agent access

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

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

   Airweave✓fullprobed8/10

   Airweave hosts a working llms.txt at docs.airweave.ai/llms.txt (HTTP 200, confirmed by probe) plus markdown-appendable docs pages explicitly designed for agent consumption, and also publishes official 'skills' for Cursor, Claude Code, Gemini CLI, OpenCode, etc. so agents can self-configure. missing for 10: no independent/community confirmation that an agent successfully used llms.txt end-to-end, and no evidence of additional agent-discovery standards (e.g. skills.json manifest validation).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.airweave.ai/llms.txt # Airweave ## Instructions for AI Agents - For clean Markdown of any page, a…”
   • [claimed-docs] “Airweave publishes official skills so that agents in Cursor, Claude Code, Gemini CLI, OpenCode, and other environments can set up integratio…”
   • [claimed-docs] “Airweave publishes official skills so that agents in Cursor, Claude Code, Gemini CLI, OpenCode, and other environments can set up integratio…”
   • [claimed-docs] “enabling your coding agents to instantly search across all your synced apps and databases with zero additional setup required”

   proof ↗⚑ flag

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

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

   Airweave~partialprobed7/10

   Airweave exposes a full REST API (OpenAPI spec), a CLI, and self-hostable deployment via a shell script, plus webhooks for event-driven automation and Pipedream workflow actions—all of which support running it headlessly or wiring it into automation/CI. However, there is no explicit CI/CD example, GitHub Actions template, or documented headless test-mode workflow in the evidence. missing for 10: explicit CI pipeline example/docs, headless testing/automation guide.

   • [claimed-docs] “The primary use case — search any collection from your terminal”
   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”
   • [claimed-docs] “The Airweave integration provides a set of actions that enable you to search your synced data to retrieve relevant context, manage your coll…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Cognee—none0/10

   Evidence only shows Cognee shipping its own MCP server so external AI tools (Claude, Cursor, Cline) can call Cognee's memory tools — the reverse direction of the story. There is no evidence that Cognee itself acts as an MCP client that can plug in and use external MCP servers' tools.

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

   Airweave—none0/10

   Airweave documents itself as an MCP *server* that lets external AI assistants query its data (airweave-docs-5, airweave-probe-3), and its integrations (auth-providers, connectors) are proprietary, not MCP-based consumption of external servers. There is no evidence Airweave itself acts as an MCP client that plugs in and uses tools from other MCP servers.

   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [claimed-docs] “Authentication providers let you reuse existing authenticated connections from third-party platforms such as Composio or Pipedream.”
   • [probe] “official MCP server documented at https://docs.airweave.ai/mcp-server”

   proof ↗⚑ flag

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

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

   Airweave✓fullprobed8/10

   Airweave is not itself an agent but a data-integration/search platform, so shipping an official MCP server is a fair axis; docs and a probe confirm a first-party MCP server implementing the Model Context Protocol so AI assistants/agents can search synced data, plus community confirmation it works well with Cursor. Missing for 10: independent hands-on verification of the MCP server's reliability/performance beyond one community anecdote.

   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [probe] “official MCP server documented at https://docs.airweave.ai/mcp-server”
   • [community] “Onyx co-founder: Congratulations on the launch. It looks like Airweave works well with Cursor, something we don't have nailed down yet!”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Airweave✓fullprobed8/10

   Airweave documents an official CLI whose primary use case is searching any collection directly from the terminal, confirmed both in docs and via a dedicated CLI docs page probe. Missing for 10: independent/hands-on community verification of the CLI itself and more detail on its full command surface beyond search.

   • [claimed-docs] “The primary use case — search any collection from your terminal”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”

   proof ↗⚑ flag

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

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

   Airweave✓fullprobed8/10

   Airweave exposes a documented OpenAPI spec (openapi.json), an llms.txt for AI-native consumption, a CLI, MCP server, and REST endpoints for collections/search/webhooks, all confirmed via probes and docs. missing for 10: independent hands-on validation of API completeness/stability and public API versioning/changelog details.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.airweave.ai/llms.txt # Airweave ## Instructions for AI Agents - For clean Markdown of any page, a…”
   • [probe] “official MCP server documented at https://docs.airweave.ai/mcp-server”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”
   • [claimed-docs] “The primary use case — search any collection from your terminal”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”

   proof ↗⚑ flag

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

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

   Airweave—none0/10

   Evidence covers source connections, auth providers, direct token injection, and MCP/CLI access, but there is no mention of issuing scoped or least-privilege API keys/credentials specifically for agents. missing for 10: any documentation of scoped API key creation, permission/role-based credential issuance, or least-privilege agent access controls.

   ⚑ flag

8. ai-native userBuild against official SDKs

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

   Airweave~partialprobed6/10

   Airweave exposes a documented OpenAPI spec (implying auto-generatable SDKs), an official LlamaIndex tool-spec package (llama-index-tools-airweave) giving agents direct API access, plus CLI and MCP server for agentic use, and integrations like Pipedream actions. However there is no explicit first-party Python/TypeScript SDK documentation beyond the LlamaIndex wrapper, so full 'build against official SDKs' coverage is unclear. missing for 10: dedicated language SDK docs (Python/JS/Go), independent developer confirmation of SDK usage beyond LlamaIndex.

   • [claimed-docs] “The llama-index-tools-airweave package provides an AirweaveToolSpec that gives your LlamaIndex agents access to Airweave's search capabiliti…”
   • [claimed-docs] “The Airweave integration provides a set of actions that enable you to search your synced data to retrieve relevant context, manage your coll…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.airweave.ai/mcp-server”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

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

   Airweave✓fullclaimed8/10

   Airweave documents a dedicated webhooks system: real-time notifications pushed on events like sync completion, source connection creation, and collection updates, explicitly positioned as an alternative to polling. This directly matches the story of subscribing to events via webhooks. Missing for 10: independent/hands-on confirmation of webhook reliability and detail on signature verification/retry semantics.

   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”

   proof ↗⚑ flag

Agentic features

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

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

   Airweave—none0/10

   Airweave's documented capabilities center on search/retrieval — vector search, AI-agent tool-calling search, MCP server access — for AI agents to query synced data, not on Airweave itself surfacing proactive AI-generated insights or suggestions to the end user. No evidence shows an insights/suggestions feature or dashboard; missing for 10: any proactive insight-generation capability, any UI or output described as 'suggestions' rather than query-driven retrieval.

   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “Airweave lets AI agents search across company knowledge bases, cloud drives, databases, and SaaS tools in a single query.”

   proof ↗⚑ flag

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

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

   Airweave~partialclaimed5/10

   Source connections automatically sync data in the background and webhooks push real-time updates instead of requiring polling, showing some autonomous background operation, but there's no evidence of a general-purpose automation/workflow engine (scheduled tasks, conditional triggers, multi-step actions) within Airweave itself—automation-style triggering is delegated to third-party tools like Pipedream. Missing for 10: native scheduling/trigger configuration UI, evidence of autonomous multi-step task execution, and independent confirmation that background syncs run reliably at scale.

   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”
   • [claimed-docs] “The Airweave integration provides a set of actions that enable you to search your synced data to retrieve relevant context, manage your coll…”

   proof ↗⚑ flag

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

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

   Airweave✓fullprobed8/10

   Airweave supports natural-language operation via its MCP server, CLI, and AI-agent tool-calling search, letting agents in Cursor, Claude Code, etc. issue natural-language queries against synced data, and community feedback confirms it works well with Cursor. Missing for 10: independent hands-on verification of natural-language control beyond search/retrieval (e.g., managing connections or collections via NL) and broader third-party corroboration.

   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [claimed-docs] “The primary use case — search any collection from your terminal”
   • [claimed-docs] “Airweave publishes official skills so that agents in Cursor, Claude Code, Gemini CLI, OpenCode, and other environments can set up integratio…”
   • [community] “Onyx co-founder: Congratulations on the launch. It looks like Airweave works well with Cursor, something we don't have nailed down yet!”
   • [probe] “official MCP server documented at https://docs.airweave.ai/mcp-server”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”

   proof ↗⚑ flag

Api quality

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

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

   Airweave~partialprobed4/10

   Airweave publishes a machine-readable OpenAPI spec (probe-2) and doc pages exist for code samples (airweave-comm-5 mentions code samples on the docs site), suggesting some form of API reference, but there is no direct evidence of an interactive 'try it' console or actually runnable examples within the docs — the community note only complains about static code sample formatting, not interactivity. missing for 10: explicit documentation or screenshot of an interactive API console (e.g., Swagger/Redoc 'Try it' UI), evidence that examples can be executed in-browser, independent confirmation of runnable examples working.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [community] “Code samples on the site have broken whitespace on mobile (Android/Brave) so look a bit intense. Also, the pricing is complex to reason abou…”

   proof ↗⚑ flag

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

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

   Airweave✓fullprobed9/10

   Probe evidence confirms a machine-readable OpenAPI spec is directly downloadable at https://docs.airweave.ai/openapi.json returning HTTP 200 with an 'openapi' key, and the docs also expose an llms.txt for machine-readable navigation. Missing for 10: no independent third-party confirmation of the spec's completeness/versioning beyond the probe check.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.airweave.ai/llms.txt # Airweave ## Instructions for AI Agents - For clean Markdown of any page, a…”

   proof ↗⚑ flag

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

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

   Airweave—none0/10

   No evidence of a dedicated sandbox/test environment distinct from production data. Self-hosting (docs-11, docs-14) allows running a local instance, but this is not documented as a sandbox mode for safely testing against non-production data, and no staging/test-environment feature is mentioned anywhere in the evidence.

   ⚑ flag

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

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

   Airweave—none0/10

   There's evidence of an OpenAPI spec existing, but nothing about API versioning scheme, version history, or a documented deprecation policy. Missing for 10: versioning scheme documentation, deprecation policy, changelog/migration guides.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

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

   Airweave~partialclaimed4/10

   Airweave's core sync and search architecture inherently processes many items at once (source connections auto-sync entire datasets, collections span multiple sources, single queries search across large data sets), but there is no explicit documentation of a bulk API for batch creating/updating/deleting many items or connections in one call. Missing for 10: explicit bulk/batch API endpoints, evidence of bulk item management (not just sync), and any hands-on confirmation of bulk operation performance at scale.

   • [claimed-docs] “A collection is a group of different data sources that you can search using a single endpoint.”
   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Airweave lets AI agents search across company knowledge bases, cloud drives, databases, and SaaS tools in a single query.”

   proof ↗⚑ flag

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

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

   Airweave~partialclaimed3/10

   Airweave offers webhooks that push real-time event notifications (sync completed, connection created, collection updated) rather than a true rule engine where users define conditional triggers that automatically execute actions inside the product; actual automation logic must be built externally (e.g., via Pipedream workflows) that consume these events. missing for 10: a native rule/trigger-condition builder, support for user-defined conditional logic, and evidence of actions being executed automatically by Airweave itself rather than just notifying external systems.

   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”
   • [claimed-docs] “The Airweave integration provides a set of actions that enable you to search your synced data to retrieve relevant context, manage your coll…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Airweave
   Cognee—none0/10

   Cognee is a memory/knowledge-graph engine with operations (remember, recall, improve, forget), a CLI, and MCP integration, but there is no evidence of any scheduler, cron-like feature, or recurring job/workflow automation capability in the docs pack.

   ⚑ flag

   Airweave~partialclaimed3/10

   Airweave's source connections 'automatically sync data' and it pushes webhook updates instead of polling, implying some recurring background sync exists, but there's no documented scheduling interface, cron-like controls, or ability to schedule arbitrary recurring jobs/workflows beyond source sync. Missing for 10: explicit scheduling/cron configuration options, user-defined recurring workflow triggers, and any evidence of customizable sync intervals.

   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”

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

   Airweave—none0/10

   No evidence of deletion capabilities for memories/entities/users — the pack covers syncing, search, MCP, CLI, webhooks, and connectors, but nothing about deleting or erasing synced data on demand. This is a fair capability for a data-sync/RAG platform to expose (e.g., for GDPR compliance) given it stores user data, so the axis applies, but no evidence supports it.

   ⚑ flag

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

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

   Airweave—none0/10

   Airweave's docs cover data sync, search modes, MCP/CLI integrations, and connectors, but there is no mention of TTL, expiration dates, recency weighting, or any mechanism to decay or expire stale data/memories. Missing for 10: TTL/expiration configuration, recency-based scoring or decay, any lifecycle policy documentation.

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

   Airweave—none0/10

   Evidence covers ingestion (source connections), search (vector/agentic), MCP server, CLI, webhooks, and self-hosting, but nothing describes an export mechanism or machine-readable dump of stored memories/collections for portability. Self-hosting (docker-compose) implies some data ownership but does not demonstrate an explicit export feature. missing for 10: documented export/dump endpoint or CLI command, evidence of a standard export format (e.g., JSON/CSV), any migration or data-portability guide.

   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”
   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”

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

   Airweave~partialclaimed4/10

   Airweave documents self-hosting via docker-compose (`./start.sh`) on macOS/Linux/WSL, showing a local deployment path, but there is no evidence it can run embedded in-process (as a library) or configured against local embedding/LLM models to avoid all cloud dependency — the docs describe it as a service with source connectors, vector DB, and search API rather than an embeddable local-only memory layer. missing for 10: evidence of in-process/embedded mode, evidence of local-model (non-cloud) embedding/LLM configuration, confirmation no external API calls are required once self-hosted.

   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”

   proof ↗⚑ flag

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

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

   Airweave✓fullclaimed8/10

   Docs explicitly provide a git clone + ./start.sh workflow for local self-hosted deployment on macOS/Linux/WSL, indicating Docker-based open-source self-hosting is supported. Missing for 10: explicit confirmation of production-grade/cloud self-host guidance (beyond local dev) and independent hands-on verification of the self-hosted deployment succeeding.

   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”

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

   Airweave—none0/10

   Airweave's docs describe vector search and an agent that can 'navigate entity hierarchies (parent/child/sibling)', but this is document/entity hierarchy navigation within a RAG pipeline, not a knowledge graph of entities and relationships designed for multi-hop, entity-centric reasoning. There is no mention of a graph database, relationship modeling, or multi-hop query capability.

   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “Direct vector search. Use when speed is critical (~0.5sec).”

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

   Airweave—none0/10

   No evidence Airweave tracks fact validity intervals or temporal versioning of entities; docs describe sync, search strategies, and entity hierarchy navigation but nothing about time-bound validity or invalidation of facts. Missing for 10: any mention of temporal metadata, valid/invalid time tracking, or versioned fact history.

   ⚑ flag

Schema customization

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

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

   Airweave—none0/10

   Airweave's evidence describes collections, source connections, vector/agentic search, MCP, CLI, and webhooks, but nothing addresses customizing entity types, edge types, or an ontology/schema for a graph-entity memory model — Airweave appears to use a fixed sync/search architecture rather than an editable knowledge-graph schema. Missing for 10: any mention of entity/edge type definitions, schema customization API, or ontology configuration.

   • [claimed-docs] “A collection is a group of different data sources that you can search using a single endpoint.”
   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”

   proof ↗⚑ flag

Agent memory

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

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

   Airweave—none0/10

   Airweave's documented capability is agentic *search* over synced external data sources (docs-4, docs-5, docs-17) and syncing/connecting data, not an agent-writable memory store. There is no evidence of an agent invoking add/update/delete operations on memories mid-conversation — data flows in via source connections/syncs, not via agent tool calls for memory CRUD.

   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”

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

   Airweave—none0/10

   No published benchmark results (e.g. LongMemEval, LoCoMo) or quantitative recall-accuracy metrics appear anywhere in the evidence; only a single anecdotal HN comment claims superior 'retrieval accuracy' with no data. missing for 10: published benchmark suite results, comparison methodology, any quantitative recall/accuracy numbers.

   • [community] “Had meetings with a ton of MCP-server providers, no one came close to Airweave’s retrieval accuracy. I even tried Zapier and similar large c…”

   proof ↗⚑ flag

Core memory

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

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

   Airweave—none0/10

   Airweave's documented model is syncing external data sources (Slack, GitHub, Drive, databases) into collections and then searching them via vector/agentic search, not an explicit API for adding conversational memories and retrieving them for session persistence. None of the evidence describes a 'store this conversation turn' or memory-write primitive, or session-context persistence semantics — missing for 10: an add-memory/write API for conversational turns, evidence of session-scoped recall, and any first-party or community confirmation of using Airweave as a conversation memory layer.

   • [claimed-docs] “A collection is a group of different data sources that you can search using a single endpoint.”
   • [claimed-docs] “Direct vector search. Use when speed is critical (~0.5sec).”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “Airweave lets AI agents search across company knowledge bases, cloud drives, databases, and SaaS tools in a single query.”

   proof ↗⚑ flag

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

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

   Airweave—none0/10

   Airweave is a data-sync/search platform that indexes and syncs source data via connectors and search endpoints; the evidence describes syncing, webhooks, and search strategies but contains no mention of a memory layer that detects contradictions, supersedes, or merges conflicting stored facts. This is an applicable axis for a retrieval/knowledge system, but no evidence shows such conflict-resolution or memory-update logic exists.

   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”

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

   Airweave~partialclaimed4/10

   Airweave documents two retrieval modes—fast direct vector search and an agentic iterative search that reads full documents and navigates entity hierarchies—giving developers some steering beyond a single fixed similarity search, but there is no explicit documentation of metadata filters, keyword/hybrid search, or a reranking step. missing for 10: metadata filter parameters, keyword/hybrid search mode, explicit reranking mechanism, independent verification of these controls.

   • [claimed-docs] “Direct vector search. Use when speed is critical (~0.5sec).”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “Direct vector search. Use when speed is critical (\~0.5sec).”

   proof ↗⚑ flag

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

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

   Airweave~partialprobed6/10

   Airweave's docs describe collections, source connections, search, and sync management as API/CLI-first concepts, and an OpenAPI spec plus CLI and MCP server are documented, implying most functionality is API-accessible. However, no evidence explicitly confirms full parity between UI and API (e.g., whether every dashboard action like billing, org settings, or Airweave Connect widget configuration is also API-exposed). Missing for 10: an explicit parity statement or audit showing all UI features are API-reachable, and independent confirmation from users exercising the API directly.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”
   • [claimed-docs] “A collection is a group of different data sources that you can search using a single endpoint.”
   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “The primary use case — search any collection from your terminal”

   proof ↗⚑ flag

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

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

   Airweave~partialprobed4/10

   Airweave is open-source and self-hostable (git clone, ./start.sh) and exposes a documented OpenAPI/CLI surface, giving some data portability and avoiding lock-in, but there is no explicit documented bulk-export feature or open-format export tooling for a user's synced data. missing for 10: explicit data export/backup feature, documented open export formats, evidence of a 'leave and take your data' workflow.

   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.airweave.ai/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.airweave.ai/cli”

   proof ↗⚑ flag

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

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

   Airweave~partialclaimed5/10

   The docs show a public GitHub repo (airweave-ai/airweave) that can be cloned and self-hosted (airweave-docs-11, airweave-docs-14), implying the source is publicly readable, but no evidence specifies an actual open-source license (e.g., MIT/Apache) or license file. Missing for 10: explicit license declaration, confirmation of license terms, and independent corroboration that the repo is fully open (not just source-available for self-hosting).

   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   Airweave✓fullclaimed8/10

   Docs explicitly provide a self-host path via git clone and ./start.sh, and note it can run on macOS, Linux, or WSL, confirming the core product can be self-hosted rather than only used as SaaS. Missing for 10: independent hands-on report of a successful self-hosted deployment and more detail on production-grade self-host configuration/scaling.

   • [claimed-docs] “git clone https://github.com/airweave-ai/airweave.git cd airweave ./start.sh”
   • [claimed-docs] “If you prefer to run Airweave yourself, you can deploy it locally on macOS, Linux or WSL.”

   proof ↗⚑ flag

Pricing

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

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

   Airweave—none0/10

   No evidence pack item documents a published pricing page, free tier, or per-unit rates; the only pricing-related mentions are community complaints that pricing is 'complex to reason about' and 'prohibitive,' with a direct ask for usage-based per-unit pricing that goes unanswered, indicating no clear published rate structure exists for cost projection.

   • [community] “Code samples on the site have broken whitespace on mobile (Android/Brave) so look a bit intense. Also, the pricing is complex to reason abou…”
   • [community] “Your pricing currently seems prohibitive for that kind of use case. Shouldn't it be usage-based so one can build a product where users can c…”

   proof ↗⚑ flag

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

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

   Airweave—none0/10

   There is no mention anywhere in the evidence pack of data residency, region selection, or self-hosting for compliance/geographic control (the self-host option is framed as a deployment preference, not a residency feature). Missing for 10: any documentation of region choice, data residency guarantees, or compliance-driven storage location controls.

   ⚑ flag

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

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

   Airweave—none0/10

   No evidence in the pack addresses AI-model training data usage policies, opt-out mechanisms, or data-retention/training guarantees for Airweave; the docs focus on data syncing, search, and integrations but never mention training-data controls.

   ⚑ flag

3. ai-native userControl data retention and deletion

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

   Airweave—none0/10

   Evidence pack covers syncing, search, MCP, and connectors but contains no mention of data retention policies, deletion controls, or user-initiated data purging/export for collections or synced data. This is an applicable axis for a data-sync/RAG platform handling third-party app data, so absence of evidence yields 'none'.

   ⚑ flag

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

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

   Airweave—none0/10

   No evidence in the pack mentions telemetry, usage tracking, analytics collection, or an opt-out mechanism for Airweave; the docs cover collections, search, MCP, CLI, and integrations but never address telemetry practices.

   ⚑ flag

Latency

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

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

   Airweave~partialclaimed3/10

   Airweave documents a single rough latency figure ("~0.5sec" for direct vector search) but provides no p50/p95 breakdown, no methodology, benchmark environment, or measured distributions, and no independent corroboration of this number. Missing for 10: documented p50/p95 percentile targets, benchmark methodology/environment details, and independent verification of the latency claim.

   • [claimed-docs] “Direct vector search. Use when speed is critical (~0.5sec).”
   • [claimed-docs] “Direct vector search. Use when speed is critical (\~0.5sec).”

   proof ↗⚑ flag

Scale

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

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

   Airweave~partialclaimed5/10

   Airweave's source connections 'automatically sync data' in the background, and webhooks notify when 'syncs completing' occur, with docs noting this is an alternative to 'constantly polling the API' — implying an async sync/status mechanism exists. However, there is no explicit documentation of batch/large-scale ingestion controls, job-status endpoints, or throughput guarantees for platform-engineer-scale operations. Missing for 10: explicit batch/async ingestion API docs, sync job status endpoint documentation, scale/throughput benchmarks or SLAs.

   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [claimed-docs] “Instead of constantly polling the API, you register a webhook endpoint and Airweave pushes updates to you the moment they occur.”

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

   Airweave✓fullprobed8/10

   Airweave ships an official MCP server that lets assistants like Claude and Cursor search synced data, plus published skills for Cursor, Claude Code, Gemini CLI, and OpenCode that enable setup/search without re-explaining, all pointing to a single shared 'collection' as the underlying memory. Community evidence corroborates real-world use with Cursor. Missing for 10: explicit first-party ChatGPT connector docs and independent evidence of multiple assistants simultaneously sharing state in practice.

   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [claimed-docs] “Airweave publishes official skills so that agents in Cursor, Claude Code, Gemini CLI, OpenCode, and other environments can set up integratio…”
   • [claimed-docs] “Airweave publishes official skills so that agents in Cursor, Claude Code, Gemini CLI, OpenCode, and other environments can set up integratio…”
   • [claimed-docs] “A collection is a group of different data sources that you can search using a single endpoint.”
   • [probe] “official MCP server documented at https://docs.airweave.ai/mcp-server”
   • [community] “Onyx co-founder: Congratulations on the launch. It looks like Airweave works well with Cursor, something we don't have nailed down yet!”

   proof ↗⚑ flag

Frameworks

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

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

   Airweave~partialclaimed3/10

   Airweave documents a framework-integration pattern (e.g., LlamaIndex's AirweaveToolSpec, Pipedream actions, and MCP server/CLI/skills for coding agents), showing the product does ship first-party SDK-style hooks into agent tooling — but none of the specific frameworks named in the story (LangChain, LangGraph, CrewAI, Vercel AI SDK) appear anywhere in the evidence pack. missing for 10: documented LangChain integration, LangGraph integration, CrewAI integration, Vercel AI SDK integration.

   • [claimed-docs] “The llama-index-tools-airweave package provides an AirweaveToolSpec that gives your LlamaIndex agents access to Airweave's search capabiliti…”
   • [claimed-docs] “The Airweave integration provides a set of actions that enable you to search your synced data to retrieve relevant context, manage your coll…”
   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [claimed-docs] “Airweave publishes official skills so that agents in Cursor, Claude Code, Gemini CLI, OpenCode, and other environments can set up integratio…”

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

   Airweave—none0/10

   No evidence mentions LiveKit, Pipecat, ElevenLabs, or any voice pipeline integration; Airweave's documented integrations are limited to MCP, CLI, coding agents, LlamaIndex, and Pipedream. Latency claims (~0.5s vector search) exist but are not tied to any voice/real-time conversational framework. missing for 10: any mention of LiveKit/Pipecat/ElevenLabs, voice pipeline docs, real-time conversation latency benchmarks specific to voice use cases.

   • [claimed-docs] “Direct vector search. Use when speed is critical (~0.5sec).”
   • [claimed-docs] “The Airweave MCP server implements the Model Context Protocol to let AI assistants search your synced data.”
   • [claimed-docs] “The llama-index-tools-airweave package provides an AirweaveToolSpec that gives your LlamaIndex agents access to Airweave's search capabiliti…”
   • [claimed-docs] “The Airweave integration provides a set of actions that enable you to search your synced data to retrieve relevant context, manage your coll…”

   proof ↗⚑ flag

Sdks

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

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

   Airweave—none0/10

   No evidence pack item mentions official Python or TypeScript SDKs at all; documentation references an OpenAPI spec, MCP server, CLI, and framework integrations (LlamaIndex, Pipedream) but not dedicated Python/TypeScript client libraries with memory APIs. Missing for 10: any mention of an official Python SDK, an official TypeScript SDK, or parity of memory/search APIs between them.

   ⚑ flag

Context assembly

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

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

   Airweave—none0/10

   Airweave's docs describe search endpoints (direct vector search and agentic search) returning results from connected sources, but there is no mention of a token-budgeted or prompt-ready context assembly feature. Missing for 10: any documentation of token-limit controls, context-window formatting, or a single-call 'assemble context' endpoint.

   • [claimed-docs] “Direct vector search. Use when speed is critical (~0.5sec).”
   • [claimed-docs] “An AI agent iteratively searches your data using tool calling. It searches with multiple strategies, reads full documents, navigates entity …”
   • [claimed-docs] “Airweave lets AI agents search across company knowledge bases, cloud drives, databases, and SaaS tools in a single query.”

   proof ↗⚑ flag

Ingestion

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

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

   Airweave✓fullcommunity8/10

   Airweave connects and syncs diverse sources — cloud drives, databases, SaaS tools, knowledge bases — into searchable collections, explicitly going beyond chat transcripts to documents, JSON/business data, and structured app data (docs-2, docs-12, docs-16). Community feedback corroborates strong retrieval across integrations. Missing for 10: independent hands-on verification of ingesting raw JSON/business data specifically (beyond documented app connectors), and detailed schema/normalization docs for non-document structured data.

   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Airweave lets AI agents search across company knowledge bases, cloud drives, databases, and SaaS tools in a single query.”
   • [claimed-docs] “If your favorite tool or API is not yet supported, you can build a connector and either use it locally or contribute it back to the communit…”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”
   • [community] “Had meetings with a ton of MCP-server providers, no one came close to Airweave’s retrieval accuracy. I even tried Zapier and similar large c…”
   • [community] “Yes, a lot MCP servers are just api wrappers. Airweave looks like it copies the data and has a RAG that is processing your queries.”

   proof ↗⚑ flag

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

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

   Airweave—none0/10

   Airweave's docs describe syncing structured data from apps/databases and cloud drives (Slack, GitHub, Google Drive, Notion) into searchable collections, but no evidence shows direct ingestion of images, PDFs, or arbitrary files as memory inputs, nor multimodal parsing/recall of such files. missing for 10: explicit file/image/PDF upload API, multimodal parsing or OCR capability, and any documentation or example of recalling content from a stored image/PDF.

   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Airweave Connect is a hosted, embeddable UI widget that lets end users connect their apps (Slack, GitHub, Google Drive, Notion, and more) di…”
   • [claimed-docs] “Airweave lets AI agents search across company knowledge bases, cloud drives, databases, and SaaS tools in a single query.”

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

   Airweave—none0/10

   No evidence of RBAC, policies, ACLs, or audit logging for governing memory/data access in Airweave; docs cover collections, sources, search, sync, and integrations but nothing on access control or auditing.

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

   Airweave—none0/10

   Airweave's docs describe collections, source connections, and organizations as organizational units, but nothing in the evidence pack describes per-user/agent/application scoping guarantees or tenant-isolation enforcement in retrieval. No mention of access control, row-level security, or per-tenant query filtering that would prevent cross-tenant leakage.

   • [claimed-docs] “A collection is a group of different data sources that you can search using a single endpoint.”
   • [claimed-docs] “A source connection links a specific app or database to your collection. It handles authentication and automatically syncs data.”
   • [claimed-docs] “Webhooks are real-time notifications that Airweave sends when things happen in your organization: syncs completing, source connections being…”

   proof ↗⚑ flag

Sharing

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

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

   Airweave—none0/10

   Airweave's docs describe collections, source connections, and search endpoints, but nothing addresses per-user/per-agent memory scoping, shared vs. private data boundaries, or team/tenant isolation. The evidence pack has no mention of access control, multi-tenant permissions, or selective sharing of synced data between agents/users.

   ⚑ flag