Zep vs Cognee

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

   Cognee✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   Cognee✓fullprobed8/10

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

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Cognee✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   Cognee✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Cognee~partialprobed6/10

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

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Cognee—none0/10

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

   ⚑ flag

Agentic features

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

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

   Cognee~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

   • [claimed-docs] “Install Cognee as a Linear agent that answers @mentions and delegated issues from memory, and index the workspace's issues.”
   • [claimed-docs] “Connect Cognee to MCP-compatible AI tools like Claude, Cursor, and Cline.”
   • [claimed-docs] “Cognee MCP brings persistent AI memory to your workflow through the Model Context Protocol.”

   proof ↗⚑ flag

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

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

   Cognee✓fullprobed7/10

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

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

   proof ↗⚑ flag

Api quality

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

   ⚑ flag

Forgetting

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

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

   Cognee✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

Portability

1. platform-engineerExport memories in a machine-readable format so the memory store is portable and not a lock-in trap

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

Self host

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

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

   Cognee~partialclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Cognee✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Knowledge graph

1. ml-engineerStore memories as a knowledge graph of entities and relationships so multi-hop and entity-centric questions are answerable

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

   Cognee✓fullcommunity8/10

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

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

   proof ↗⚑ flag

2. ml-engineerTrack when facts became valid or invalid (temporal reasoning) so the memory distinguishes current from outdated information

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

   Cognee—none0/10

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

   ⚑ flag

Schema customization

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

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

   Cognee~partialcommunity6/10

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

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

   proof ↗⚑ flag

Agent memory

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

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

   Cognee✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Zep
   Zep✓fullcommunity8/10

   Zep automatically ingests raw chat messages into a temporal knowledge graph (zep-docs-20, zep-gh-1/2/3), extracting facts/entities/relations without manual tagging, and separately generates and incrementally updates natural-language thread summaries in the background (zep-docs-8). Community commentary confirms this is a deliberate design evolution from naive LLM fact-extraction toward a more robust temporal graph approach for salience and consolidation (zep-comm-1). Missing for 10: independent benchmark or hands-on evidence of extraction accuracy/salience quality, and detail on exactly how 'importance' is scored versus simply ingesting everything.

   • [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] “A thread summary is a natural-language summary of the messages in a single thread, generated and incrementally updated by Zep.”
   • [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] “Zep builds a Context Graph from chat messages, business data, documents, and JSON.”

   proof ↗⚑ flag

   Cognee~partialclaimed6/10

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

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

   proof ↗⚑ flag

Benchmarks

1. ml-engineerSee published memory-quality benchmark results (e.g. LongMemEval, LoCoMo) backing the product's recall-accuracy claims

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

   Cognee—none0/10

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

   ⚑ flag

Core memory

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

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

   Cognee✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

Retrieval controls

1. developerSteer retrieval with metadata filters, keyword/hybrid search modes, or reranking instead of accepting a single fixed similarity search

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   Cognee✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Pricing

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

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

   Cognee~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

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

   Cognee✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Cognee—none0/10

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

   ⚑ flag

Latency

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

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

   Cognee—none0/10

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

   ⚑ flag

Scale

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

Agent memory

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

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

   Cognee~partialprobed7/10

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

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

   proof ↗⚑ flag

Frameworks

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

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

2. developerWire memory into real-time voice pipelines (e.g. LiveKit, Pipecat, ElevenLabs) with documented integrations fast enough for live conversation

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

   Cognee—none0/10

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

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

   proof ↗⚑ flag

Sdks

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

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

   Cognee~partialprobed3/10

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

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

   proof ↗⚑ flag

Context assembly

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

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

2. developerGet summaries of past sessions or threads so an agent can pick up where the last conversation left off

   weight 3 · round to Zep
   Zep✓fullclaimed9/10

   Zep documents thread summaries that are auto-generated and incrementally updated per thread, plus a Context Block retrievable via thread.add_messages()/get_user_context() combining summaries, edges, nodes, and episodes so an agent can resume with full prior context. This directly supports resuming past sessions/threads with sub-200ms retrieval performance documented. Missing for 10: independent hands-on verification of summary quality/accuracy over long conversations beyond vendor docs.

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

   Cognee~partialclaimed7/10

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

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

   proof ↗⚑ flag

Ingestion

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

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

   Cognee✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   Cognee~partialclaimed6/10

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

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

   proof ↗⚑ flag

Governance

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

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

   Cognee~partialclaimed5/10

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

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

   proof ↗⚑ flag

Isolation

1. developerScope memories per user, agent, or application so one tenant's memories never leak into another's retrieval

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

   Cognee~partialclaimed7/10

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

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

   proof ↗⚑ flag

Sharing

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

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

   Cognee~partialclaimed7/10

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

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

   proof ↗⚑ flag