"kgai vs Cognee: documents distilled, or decisions recorded"
The job sounds the same from a distance. Turn what your organization knows into something an agent can query. The split is where that knowledge lives. Cognee starts from documents you already have. kgai starts from decisions your team is making right now.
What Cognee does well. It ingests data in more or less any format, then builds a knowledge graph plus vector embeddings out of it with an LLM pipeline. Queries auto-route to the search strategy that fits. It ships Python, TypeScript and Rust SDKs, an MCP server and a Claude Code plugin, and its default stores run embedded, so the first run doesn't ask you to stand up infrastructure. Apache-2.0, with a hosted cloud if you want one.
Where kgai differs. Direction of capture. Cognee distills existing content into a graph, and the LLM doing that distillation decides what the graph contains. kgai records each decision explicitly at the moment it's made, into an append-only immutable log. The projection from log to graph is deterministic, so the same log gives the same graph on every machine, with no model calls and no embeddings in the read path.
What happens when knowledge changes. On Cognee's own tracker, its maintainer has an open issue proposing supersedes links and contradiction resolution as a first-class memory task, describing it as missing today (issue 3394). In kgai that mechanism is the core primitive. A new decision supersedes the old through an explicit link carrying the reason. Recall returns only decisions still in force, but the whole superseded chain, dead ends and all, stays queryable.
The team story. Cognee's memory is whatever the pipeline was fed. kgai's log syncs opt-in through an S3 bucket you own, with per-writer shards, so a whole team of humans and agents can record in parallel without ever producing a textual conflict.
Choose Cognee if the knowledge you need is already written down. Wikis, PDFs, specs, tickets. Distilling a corpus into a queryable graph is its actual job and kgai has no answer for it. Choose kgai if the knowledge is being created decision by decision as your team and its agents work. It's decision-level memory for AI dev teams. It won't ingest your document pile, won't do conversation memory, and won't personalize per user.
Plenty of teams have both problems, in which case these aren't rivals. If the decision side is the one bleeding, the closest architectural comparison is kgai vs Graphiti, and trying kgai itself is a two-command install.
Try it on your repo. Two commands, MIT, nothing leaves your machine until you configure a bucket.
See how kgai compares to other tools on the comparison page, or browse the other notes.