Supermemory vs Airweave

Agent access

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

   weight 2 · round drawn
   Supermemory✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 userConnect an agent via an official MCP server

   weight 3 · round drawn
   Supermemory✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round to Airweave
   Supermemory~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Supermemory✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Supermemory—none0/10

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

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

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Supermemory
   Supermemory✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Airweave
   Supermemory—none0/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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