Zep vs Airweave

Agent access

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

   weight 2 · round to Zep
   Zep✓fullprobed9/10

   Zep hosts an llms.txt file at help.getzep.com/llms.txt (confirmed HTTP 200 via direct probe) with a clear summary of the product, and also runs a docs MCP server that completed a live keyless JSON-RPC handshake, giving agents multiple direct machine-readable entry points into the docs. Missing for 10: no independent/community confirmation that agents actually use these entry points successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://help.getzep.com/llms.txt # Welcome to Zep! > Zep delivers agent memory at enterprise scale — a governed…”
   • [probe] “PROBE runtime (recorded 2026-09-05): Zep's documentation MCP server at https://help.getzep.com/_mcp/server completed a full keyless JSON-RPC…”
   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”

   proof ↗⚑ flag

   Airweave✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Airweave
   Zep~partialprobed6/10

   Zep is fundamentally API/SDK-driven (thread.add_messages, graph.edge.delete calls) and ships a full-access CLI (zepctl) for managing projects, users, threads, and data from the terminal — both of which are inherently scriptable/headless and usable in CI pipelines. However, there is no explicit documentation or example of CI/CD integration, automated testing, or headless deployment guidance. Missing for 10: explicit CI/CD pipeline examples, headless automation docs, non-interactive auth/service-account setup guidance for CI.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “official CLI documented at https://help.getzep.com/zepctl-cli”

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

   Zep documents and runtime-verifies an official Memory MCP server that lets end users connect Claude, ChatGPT, Cursor, Codex and other MCP clients to their agent memory, with a live OAuth-gated endpoint confirmed at api.getzep.com/mcp. missing for 10: independent third-party (non-vendor) hands-on review of the MCP client connection experience beyond Zep's own docs/probe.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [probe] “official MCP server documented at https://help.getzep.com/memory-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”

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

   Zep documents zepctl, an official CLI providing full administrative access to Zep projects (managing users, threads, Context Graphs, and data operations from the terminal), independently confirmed via probe at the documented URL. missing for 10: no independent/community hands-on usage reports of zepctl, and no detail on installation/distribution channels.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [probe] “official CLI documented at https://help.getzep.com/zepctl-cli”

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

   Zep documents a full REST/SDK API (thread.add_messages, graph.edge.delete, get_user_context, etc.) with quick-start guides, plus a CLI (zepctl) providing full programmatic/administrative access, and runtime probes confirm live endpoints (MCP server, docs API) behaving as documented. This is clearly a documented, agent-drivable public API surface with concrete code examples and independent runtime verification. Missing for 10: no independent third-party API reference/benchmark beyond vendor docs and probes.

   • [claimed-docs] “Add agent memory to your app in three lines of code.”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “official CLI documented at https://help.getzep.com/zepctl-cli”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

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

   Zep explicitly documents ABAC policies attached to API keys and UserGroups to enable least-privilege access for agents and Memory MCP users (zep-docs-25, zep-docs-38, zep-docs-31, zep-docs-12), and this is corroborated at runtime by the Memory MCP endpoint being IdP-gated with OAuth-protected-resource metadata rather than open access (zep-probe-rt-2). Missing for 10: no worked example showing granular scope definitions (e.g. per-thread or per-action policy syntax) or independent third-party audit of the ABAC enforcement.

   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

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

   Docs show official SDK method calls (client.graph.edge.delete, thread.add_messages, three-line quick start) and a real pip-installable OSS engine (graphiti-core) confirmed via probe, indicating an official Python SDK/client exists and works. However, there's no explicit documentation of the full SDK ecosystem (e.g., multiple language SDKs, GitHub repo for the client library itself) or independent developer corroboration of building against these SDKs. Missing for 10: explicit multi-language SDK listing, dedicated SDK GitHub repo evidence, third-party developer confirmation of SDK integration.

   • [claimed-docs] “Add agent memory to your app in three lines of code.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”

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

   No evidence in the pack mentions webhooks or event subscription mechanisms; Zep's docs cover MCP servers, CLI, SDKs, and API access but nothing about outbound event notifications or webhook subscriptions.

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

   Zep does generate AI-derived artifacts from ingested data — thread summaries (natural-language summaries incrementally updated by Zep) and entity/relation extraction into the Context Graph — which qualify as AI-generated insights from user data. However, there is no evidence of proactive 'suggestions' or recommendation-style outputs, nor any user-facing dashboard/UI surfacing these insights to an end user; the artifacts are primarily consumed programmatically by the calling agent/app rather than presented as insights inside a product experience. Missing for 10: evidence of suggestion/recommendation generation, and evidence of a UI or interface that surfaces these AI-generated insights directly to a human/ai-native user.

   • [claimed-docs] “A thread summary is a natural-language summary of the messages in a single thread, generated and incrementally updated by Zep.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”
   • [claimed-docs] “Custom Entity/Edge Types | Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Co…”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”

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

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ 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
   Zep~partialprobed5/10

   Zep exposes an MCP server so agents/AI clients can invoke memory operations via natural-language-driven tool calls, and the Memory MCP endpoint is confirmed live/IdP-gated in a runtime probe, which supports natural-language operation through an AI assistant. However, the primary administrative surface is zepctl, a traditional structured CLI, not a natural-language command interface, and there is no documented natural-language command parser or chat-driven admin console. missing for 10: evidence of natural-language command parsing/execution outside MCP-client pass-through, first-party NL command examples, independent hands-on confirmation of NL-driven operation.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

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

   Zep's docs pages show static code snippets (e.g., zep-docs-21, zep-docs-29) but there is no evidence of an interactive, runnable API reference (e.g., embedded sandbox, 'try it' console, Postman/Swagger integration) anywhere in the evidence pack.

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

   Zep is an API-first service with SDKs, a CLI (zepctl), and MCP servers, so a downloadable OpenAPI spec would be a natural artifact — but no evidence pack item mentions an OpenAPI/Swagger spec, API reference export, or machine-readable schema file being available for download.

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

   No evidence of a dedicated sandbox/staging environment, test API keys, or non-production project mode for Zep's memory platform; the only related items are deployment options (Cloud vs VPC) and the standalone open-source Graphiti library, neither of which document a sandbox for testing against production-like data safely.

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

   The evidence pack covers Zep's features (memory, graph, MCP, CLI) but contains no mention of API versioning scheme or a documented deprecation policy for breaking changes. This is a fair axis for an API-first product, but no evidence supports it.

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

   Zep supports some bulk-style operations — deleting a User removes all associated threads/artifacts in one API call, and the zepctl CLI gives scriptable full access to manage users, threads, and graphs from the terminal — but there is no documented batch/bulk create-ingest API for processing many items in a single call. missing for 10: explicit bulk ingest/create endpoints, batch size limits or throughput guidance, and independent evidence of large-scale bulk operations being exercised in practice.

   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

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

   Zep is a memory/context-graph layer with search, retrieval, MCP access, and governance policies, but no evidence describes a rules engine or event-trigger mechanism that automatically fires actions on defined conditions/events. Governance features (ABAC/RBAC) restrict access rather than trigger automated actions.

   ⚑ 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 Zep
   Zep✓fullclaimed9/10

   Zep documents multiple granularities of deletion: single edge deletion via client.graph.edge.delete (with cascading edge deletion when a node is deleted), and full user erasure via a single API call that deletes all threads and graph data, explicitly framed as satisfying Right To Be Forgotten/privacy regulation requirements. This covers single-memory, per-entity (node/edge), and full-erasure use cases directly relevant to a platform-engineer's data-lifecycle needs. Missing for 10: no independent/hands-on confirmation of deletion behavior beyond first-party docs, and no explicit documented API for bulk per-entity-type deletion across a graph (only node/edge-level and full-user-level are shown).

   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”

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

   Zep's underlying Graphiti engine is a temporal knowledge graph that tracks how facts change over time, which implies automatic invalidation of superseded facts as new information arrives — a decay-like mechanism rather than explicit TTL. However, no evidence describes explicit TTL settings, expiration dates, or recency-weighted retrieval; only manual node/edge deletion APIs are documented for removing stale data. Missing for 10: explicit TTL/expiration-date configuration, documented recency-weighting in search/ranking, and confirmation that fact invalidation actually suppresses surfacing of stale facts in retrieval.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”

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

   Zep exposes a graph API (JSON data model, node/edge delete by UUID) and a zepctl CLI described as having 'full access... to manage users, threads, Context Graphs, and data operations from the terminal,' which implies some programmatic read/write access to graph data, and the underlying Graphiti engine is open-source and pip-installable, reducing lock-in. However, no evidence explicitly documents a bulk 'export' command, a defined export file format, or a documented data-portability workflow for moving a full Context Graph out of Zep. Missing for 10: an explicit export/dump feature or format, documentation confirming zepctl or API supports full-graph export, and independent verification of successful export/import round-trips.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”

   proof ↗⚑ flag

   Airweave—none0/10

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

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

   proof ↗⚑ flag

Self host

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

   weight 1 · round to Zep
   Zep~partialprobed5/10

   Zep's open-source engine Graphiti can be pip-installed and imported with no API key and used to build/query a Context Graph 'locally' in-process, giving a genuine local path, but the main Zep memory service (the one with threads, users, MCP server, zepctl) is documented as deployed via Cloud or 'Your VPC', not as an embeddable local-only runtime, and there is no evidence of configuring it against local LLMs/embedding models. Missing for 10: explicit support for local/self-hosted LLM or embedding models, confirmation that the full Zep memory layer (not just Graphiti) can run fully offline/in-process, and any docs on air-gapped or no-cloud-dependency operation.

   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”

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

   Zep explicitly offers a 'Your VPC' deployment option alongside cloud (zep-docs-17), and its underlying open-source engine Graphiti is pip-installable and runs locally with no API key (zep-probe-rt-3), showing some self-hostable OSS components exist. However, there is no Docker Compose file, self-hosting guide, or explicit instructions for standing up the full commercial 'memory layer' (threads/users/MCP server) on infrastructure a platform engineer controls — the evidence conflates the OSS Graphiti library with the hosted Zep service. Missing for 10: explicit Docker/self-host deployment docs for the full Zep memory service, confirmation that the main product (not just Graphiti) is open-source, and any hands-on report of a successful self-hosted deployment.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”

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

   Zep explicitly builds a Context Graph (temporal knowledge graph via Graphiti) from chat/business data, with entities and relationships, custom entity/edge types, edge/node deletion, and hybrid semantic+BM25 search across nodes/edges/episodes enabling multi-hop and entity-centric retrieval; the underlying Graphiti engine is verified installable and open-source with independent GitHub corroboration. Missing for 10: no explicit hands-on multi-hop query benchmark or third-party validation of entity-centric answer accuracy beyond vendor docs.

   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Context Graph.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”

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

   Zep's Context Graph is built on Graphiti, explicitly described as a temporal knowledge graph that 'tracks how facts change over time' and maintains provenance, directly matching the ml-engineer's need to distinguish current vs outdated facts; this is corroborated by GitHub docs, the Zep team's own explanation of moving from static fact extraction to a temporal graph to fix hallucination/staleness issues, and a runtime probe confirming the open-source Graphiti engine is real and installable. Missing for 10: explicit documentation of valid_at/invalid_at timestamp fields or an API example showing querying facts as of a point in time, and independent hands-on verification of temporal query accuracy.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents.”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”

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

   Zep explicitly supports Custom Entity/Edge Types via Pydantic-like classes to customize creation/retrieval of entities and relations in the Context Graph (zep-docs-3, zep-docs-33), and the underlying Graphiti engine documents support for both prescribed and learned ontology (zep-gh-1). This directly matches the ML-engineer story of customizing entity/edge types to fit a domain. Missing for 10: no independent hands-on example showing a full custom ontology in production use, and no detail on limits/complexity of ontology customization beyond entity/edge type classes.

   • [claimed-docs] “Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Context Graph.”
   • [claimed-docs] “Custom Entity/Edge Types | Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Co…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”

   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 Zep
   Zep~partialprobed7/10

   Zep exposes API/SDK calls the agent (or an MCP-connected agent) can invoke itself to add memories (thread.add_messages), search the graph (semantic+BM25, scope=auto), and delete edges/nodes (graph.edge.delete), and the Memory MCP Server is confirmed live and functioning for end-user agent memory access (zep-docs-6, zep-probe-2, zep-probe-rt-2). However, no explicit 'update' operation on existing memories is documented (only add/delete), and the MCP server is gated behind OAuth per the runtime probe, meaning autonomous mid-conversation self-service isn't fully frictionless. Missing for 10: an explicit update-memory API/tool, and clearer evidence the agent (not just external MCP clients) autonomously triggers add/search/delete without human-configured auth setup.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [probe] “official MCP server documented at https://help.getzep.com/memory-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

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

   The evidence pack contains no mention of published benchmark results such as LongMemEval or LoCoMo, nor any recall-accuracy benchmark comparison; it only covers performance latency claims (sub-200ms retrieval) and general architecture/feature docs. missing for 10: any citation to LongMemEval/LoCoMo results, any third-party or first-party benchmark study, or recall-accuracy metrics.

   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code... in under 200ms.”

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

   Zep's docs directly cover the story: adding messages persists them into a user-level knowledge graph (thread.add_messages), retrieval via semantic + BM25 hybrid graph search with sub-200ms context blocks, and cross-session persistence via Threads/Users tied to a Context Graph. This is corroborated by runtime probes confirming the memory endpoints are live and by community discussion of the underlying Graphiti engine's design rationale. Missing for 10: independent hands-on benchmarking of recall quality/accuracy across long sessions beyond vendor-stated latency claims.

   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search. Semantic search finds conceptual matches, and full-text search fin…”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

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

   Zep's Graphiti-based temporal knowledge graph explicitly tracks how facts change over time and maintains provenance, and Zep's own team describes moving away from naive fact-extraction to a temporal graph specifically to handle contradiction/reconciliation issues, with edge/node deletion APIs supporting explicit correction. missing for 10: no explicit documented API or hands-on example showing automatic detection/supersession of a contradicting fact (e.g., 'address changed from X to Y' auto-invalidating the old edge) or independent benchmark validating merge/supersede accuracy.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [community] “Zep team explained prior approach: LLM extracted 'facts' from chat history via RAG pipeline, but reconciling facts from complex conversation…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”

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

   Zep's docs confirm hybrid retrieval (semantic similarity + BM25 full-text) and a configurable 'scope' that composes across edges/nodes/episodes/summaries, showing retrieval is not a single fixed similarity search. However, there is no documented support for explicit metadata-based filtering or a dedicated reranking step/model in the search API. Missing for 10: metadata filter parameters in search calls, explicit reranking option/model, independent confirmation of these controls in practice.

   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search.”
   • [claimed-docs] “Zep graph search combines semantic similarity with BM25 full-text search. Semantic search finds conceptual matches, and full-text search fin…”
   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”

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

   Zep is fundamentally API/SDK-driven (thread.add_messages, graph.edge.delete, etc.) and zepctl/CLI is documented as providing 'full access to Zep, enabling you to manage users, threads, Context Graphs, and data operations from the terminal,' implying strong API/CLI parity with the dashboard UI. However, there is no explicit confirmation that every dashboard-only feature (e.g., RBAC/ABAC policy configuration, analytics views) is fully API-exposed. Missing for 10: explicit parity statement or docs enumerating dashboard-only features and confirming API equivalents, independent verification of full CLI/API coverage.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”

   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 drawn
   Zep~partialprobed4/10

   Zep exposes API/CLI access to graph data (zepctl, client.graph.edge.delete, thread/user APIs) and its underlying Graphiti engine is open-source and locally installable, giving some data portability, but there is no documented bulk 'export all my data' feature or standard export format. missing for 10: explicit data-export/portability feature or format documentation, evidence of a full account-data export tool, independent confirmation of successful full export.

   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”

   proof ↗⚑ flag

   Airweave~partialprobed4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Zep~partialprobed5/10

   Zep's underlying temporal knowledge-graph engine, Graphiti, is confirmed open-source on GitHub (30.6k stars) and independently verified as pip-installable with no API key required, satisfying an open-license read for the core Context Graph technology. However, the full Zep product itself (the hosted memory service, zepctl CLI, Memory MCP server) is offered as a commercial Cloud/VPC deployment with no evidence of its own source being under an open license. Missing for 10: confirmation that Zep's actual service/CLI code (not just the Graphiti dependency) is open-licensed, and any repo/license file for Zep itself.

   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents.”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [claimed-docs] “Deploy anywhere CloudYour VPC”

   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 to Airweave
   Zep~partialprobed5/10

   Zep offers a 'Your VPC' deployment option alongside Cloud (zep-docs-17), suggesting self-hosting is possible, and the underlying Graphiti temporal knowledge-graph engine that powers Zep's Context Graphs is genuinely open-source and pip-installable with no API key (zep-probe-rt-3, zep-gh-1/2/3). However, the full Zep product (users/threads API, zepctl, governance, Memory MCP server) is only ever described as a commercial Cloud/VPC deployment, not as an openly licensed self-hostable package — VPC deployment likely requires an enterprise contract rather than free self-hosting. Missing for 10: explicit open-source license or self-host instructions for the full Zep service (not just the Graphiti sub-component), pricing/terms for VPC self-hosting, and any community confirmation of successfully self-hosting core Zep.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [probe] “PROBE runtime (recorded 2026-09-05): pypi graphiti-core 0.30.1 (Graphiti, Zep's open-source temporal knowledge-graph engine, 30.6k GitHub st…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”
   • [github] “Graphiti is a framework for building and querying temporal context graphs for AI agents. Unlike static knowledge graphs, Graphiti's context …”
   • [claimed-docs] “`zepctl` is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, …”

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

   The only pricing-related evidence (zep-docs-17) shows a 'Deploy anywhere / Cloud / Your VPC' snippet from the pricing page but contains no mention of a free tier, per-unit rates, or any cost figures that would let a platform engineer project costs. Missing for 10: published free-tier details, per-unit/usage pricing rates, and any cost calculator or tier breakdown.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”

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

   Zep's pricing page states 'Deploy anywhere: Cloud, Your VPC' (zep-docs-17), implying customers can self-host in their own VPC and thus control where data resides, and the open-source Graphiti engine can be run entirely locally (zep-docs-15). However, there is no documentation of a region-selection feature within Zep Cloud itself or explicit data-residency guarantees for hosted customers. Missing for 10: explicit region/residency options in the managed cloud offering, documented list of supported regions, and any compliance certification tied to region choice.

   • [claimed-docs] “Deploy anywhere CloudYour VPC”
   • [claimed-docs] “Graphiti is the open-source temporal knowledge graph framework. Use it to build and query a single Context Graph per subject locally”

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

   The evidence pack covers RTBF/deletion, access control, and MCP/CLI tooling, but contains no statement about Zep's or its LLM providers' use of customer data for model training, nor any opt-out/no-training guarantee. Since Zep processes conversational data through LLMs, this is a fair privacy-posture question, but no evidence addresses it.

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

   Zep documents user-level deletion (single API call deletes all threads/artifacts) explicitly framed for Right To Be Forgotten/privacy compliance, plus granular deletion of individual edges/nodes and cascading edge deletion. This is corroborated by concrete API examples (client.graph.edge.delete) and admin CLI (zepctl) for data operations. Missing for 10: no documented data-retention policy/TTL configuration or independent third-party audit of deletion completeness.

   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “Deleting a node will also delete all edges connected to that node.”
   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “zepctl is a command-line interface for administering Zep projects. It provides full access to Zep, enabling you to manage users, threads, Co…”

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

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Zep itself; the closest topics are RTBF/user-deletion and access control, which do not cover product telemetry opt-out.

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

   Zep's docs make an explicit performance claim ('sub-200ms context retrieval regardless of graph size or number of graphs') and reference it in the quick-start guide, giving platform engineers a concrete latency target to plan against. However, there is no documented p50/p95 breakdown, benchmark methodology, or dataset/scale disclosure, and no independent hands-on measurement corroborates the figure. Missing for 10: percentile (p50/p95) breakdowns, benchmark methodology/conditions, and independent/third-party latency verification.

   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code... in under 200ms.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”

   proof ↗⚑ 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
   Zep—none0/10

   The evidence pack describes single-message ingestion (thread.add_messages) and various data types, but nowhere documents a batch/async ingestion API or a way to poll status of background memory-processing jobs. Missing for 10: batch ingestion endpoint, async job submission, job status/polling API.

   ⚑ flag

   Airweave~partialclaimed5/10

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

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

   proof ↗⚑ flag

Agent memory

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

   weight 2 · round to Zep
   Zep✓fullprobed9/10

   Zep documents an official Memory MCP Server explicitly enabling Claude, ChatGPT, Claude Code, Codex, Cursor, and others to connect to a shared end-user memory graph, with a runtime probe confirming the endpoint is live and IdP-gated as documented. This directly satisfies the story of connecting multiple off-the-shelf assistants to shared memory; missing for 10: independent hands-on multi-assistant test showing simultaneous cross-tool memory sharing in practice.

   • [claimed-docs] “The Memory MCP Server lets an end user connect an MCP client (Claude, ChatGPT, Claude Code, Codex, Cursor, and others) to their own agent me…”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [probe] “official MCP server documented at https://help.getzep.com/memory-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the Memory MCP endpoint https://api.getzep.com/mcp returned HTTP 40…”

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

   Zep docs explicitly reference 'agent frameworks' integrations (zep-docs-14, zep-docs-24) that persist and retrieve conversation data, and community/HN threads confirm real-world adoption, but the evidence pack never names or links specific first-party integration docs for LangChain, LangGraph, CrewAI, or Vercel AI SDK—only generic 'supported frameworks' language. missing for 10: named/linked docs pages for LangChain, LangGraph, CrewAI, or Vercel AI SDK integrations, and independent confirmation these integrations work as advertised.

   • [claimed-docs] “Zep provides agent memory for agents that you build with supported frameworks.”
   • [claimed-docs] “Zep provides agent memory for agents that you build with supported frameworks. The integrations persist conversation turns and retrieve data…”
   • [claimed-docs] “Add agent memory to your app in three lines of code.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”

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

   The evidence pack shows generic 'agent framework' memory integrations, an MCP server, and a CLI, but contains no mention of LiveKit, Pipecat, ElevenLabs, or any real-time voice pipeline integration or documentation. This is an applicable axis for a memory SDK, but no supporting evidence exists.

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

   Code examples in docs (e.g. client.graph.edge.delete, thread.add_messages()) show a Python-style SDK, but the evidence pack never mentions a TypeScript/JavaScript SDK or confirms parity between two language SDKs. Missing for 10: explicit TypeScript SDK docs/install instructions, side-by-side API parity confirmation, and any independent corroboration of both SDKs.

   • [claimed-docs] “Here's how to delete an edge from a graph: client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Here's how to delete an edge from a graph: ... client.graph.edge.delete(uuid_="your_edge_uuid")”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call. This optimization eliminates the need for a se…”

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

   Zep's docs describe a single-call 'Context Block' — via `scope="auto"` graph search or returned directly from `thread.add_messages()` — that composes relevant edges, nodes, episodes, and summaries into one prompt-ready block, with sub-200ms retrieval regardless of graph size, and prior HN commentary confirms the long-term-state/token-count design intent. missing for 10: explicit documentation of a configurable token budget/limit parameter and independent hands-on benchmarking of the assembled context block's quality.

   • [claimed-docs] “set scope="auto" and let Zep dynamically compose the most relevant context across edges, nodes, episodes, observations, and thread summaries…”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call.”
   • [claimed-docs] “You can request the Context Block directly in the response to the `thread.add_messages()` call. This optimization eliminates the need for a …”
   • [claimed-docs] “You can request the Context Block directly in the response to the thread.add_messages() call. This optimization eliminates the need for a se…”
   • [claimed-docs] “Zep delivers sub-200ms context retrieval regardless of graph size or number of graphs.”
   • [claimed-docs] “Add agent memory to your app in three lines of code. This Zep quick start covers users, threads, ingesting data, and retrieving a Context Bl…”
   • [community] “Zep team clarified differentiation: 'Many long-term memory services focus on vector search over documents... Zep is different, we focus on t…”

   proof ↗⚑ flag

   Airweave—none0/10

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

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

   proof ↗⚑ flag

Ingestion

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

   weight 2 · round drawn
   Zep✓fullclaimed8/10

   Docs explicitly state Zep ingests JSON, text, business data, and documents into the Context Graph, not just chat messages (zep-docs-2, zep-docs-27), with API examples for graph operations and custom entity/edge types for structuring business data. Community context confirms the underlying Graphiti engine tracks facts/entities beyond raw transcripts. Missing for 10: no hands-on independent verification of ingesting large documents or complex JSON schemas at scale, and no detail on supported document formats (PDF, etc.).

   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”
   • [claimed-docs] “Custom Entity/Edge Types | Feature allowing use of Pydantic-like classes to customize creation/retrieval of entities and relations in the Co…”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [github] “Graphiti's context graphs track how facts change over time, maintain provenance to source data, and support both prescribed and learned onto…”

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

   Zep's documentation explicitly enumerates ingestible data types as JSON, text, and message only (zep-docs-2), with no mention of images, PDFs, or file uploads anywhere in the evidence pack. No feature, API, or integration is described for storing or recalling from binary/file-based memory inputs.

   • [claimed-docs] “JSON, text, and message | Data types that you can ingest into a Context Graph.”
   • [claimed-docs] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”

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

   Zep's governance docs describe RBAC for dashboard users and ABAC policies scoped to API keys and UserGroups, letting admins limit what agents and Memory MCP users can read/write (zep-docs-12, zep-docs-25, zep-docs-31, zep-docs-38). However, there is no documented audit logging/trail capability to verify who accessed what memory. Missing for 10: audit log/trail evidence, granular per-resource ACLs beyond API-key/UserGroup scope, and independent verification of policy enforcement.

   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”

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

   Zep documents user-scoped Context Graphs (each user gets their own knowledge graph, created explicitly per app user) and thread-level isolation, plus ABAC/RBAC policies that limit which context each agent, API key, UserGroup, or Memory MCP user can reach — directly supporting tenant isolation across users/agents. Deletion is also scoped per user (RTBF), reinforcing that one user's data is a separable unit that can be walled off or purged without affecting others. missing for 10: explicit documentation of 'application'-level tenancy/namespace isolation beyond User/UserGroup scoping, and independent/hands-on verification that cross-tenant retrieval leakage cannot occur.

   • [claimed-docs] “Whenever users are created in your application, you need to trigger the creation of a Zep user.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”
   • [claimed-docs] “Deleting a User will delete all Threads and thread artifacts associated with that User with a single API call, making it easy to handle Righ…”
   • [claimed-docs] “This single-operation approach makes it simple to handle Right To Be Forgotten (RTBF) requests and comply with privacy regulations.”
   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”

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

   Zep's governance model provides ABAC policies attached to API keys and UserGroups to limit which context/actions each agent or MCP user can reach, implying some ability to scope shared vs. private access, and user-level Context Graphs are the default privacy boundary (zep-docs-12, zep-docs-25, zep-docs-31, zep-docs-38). However, there is no explicit documentation of a mechanism for selectively sharing specific memory items across multiple users/agents as a 'team or group memory' feature—only access-control policies, not a shared-graph or memory-merging capability. Missing for 10: explicit team/group memory graph construct, documented API for cross-user memory sharing, and any example/tutorial showing selective sharing while isolating private data.

   • [claimed-docs] “Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Use policies when you need least-privilege access to context for agents and Memory MCP users.”
   • [claimed-docs] “Role-based access control governs dashboard users. Attribute-based access control governs API keys and UserGroups.”
   • [claimed-docs] “Limit which actions and context each agent and Memory MCP user can reach with ABAC policies attached to API keys and UserGroups.”
   • [claimed-docs] “Whenever users are created in your application, you need to trigger the creation of a Zep user.”
   • [claimed-docs] “Chat messages are added to threads using `thread.add_messages`, which both adds those messages to the thread history and ingests those messa…”

   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