kgai shared decision memory for dev teams

notes for dev teams · kgai.dev/blog

"kgai vs Graphiti: two ways to build a graph that keeps its history"

You want a knowledge graph for agents that doesn't lose history when facts change. Graphiti is the closest tool to kgai on that axis, which makes this comparison mostly about the write path, not the storage philosophy. Both projects believe old truths should survive.

What Graphiti does well. It builds a bi-temporal knowledge graph from unstructured and structured data. Facts are triplets with validity windows, and when information changes, old facts are invalidated rather than deleted. Episodes are kept as the ground-truth stream, so every derived fact traces back to its source. Retrieval combines semantic embeddings, BM25 keyword search and graph traversal. It runs on Neo4j, FalkorDB or Amazon Neptune with your choice of LLM provider, it's Apache-2.0, and it's the engine at the core of Zep.

Where kgai differs. How facts get in. Graphiti extracts entities and relationships from episodes with an LLM, which is what lets it handle arbitrary text, and it also means the resulting graph depends on that extraction run. kgai stores decisions the agent writes explicitly as it works. There's no extraction step, so replay is deterministic. The same append-only log projects to the same graph on every machine, and you can verify that with a canonical export.

Invalidation semantics. Graphiti invalidates a fact automatically when new information contradicts it. In kgai, supersession is an explicit link with a reason, recorded by whoever made the new decision. Dead ends keep the reason they died, and recall returns only decisions still in force.

What you operate. Graphiti needs a graph database running plus LLM calls per episode. kgai's engine is embedded. No daemon, no server, no model calls in the read path, and team sync is opt-in through an S3 bucket you own, with per-writer shards so parallel writers never produce a textual conflict.

Choose Graphiti if you need a general temporal graph over arbitrary text and data, want semantic recall over it, and are fine operating a graph database and paying for extraction. Building memory features into your own product is exactly what it's a framework for. Choose kgai if the corpus is specifically your dev team's engineering decisions and agents do most of the writing. It stays in that lane. Conversations, document piles and per-user personalization are all out of scope.

If what you actually want is Graphiti as a managed service, that's Zep, compared separately in kgai vs Zep. For the decision-log side, the install is two commands and the first recorded decision is the whole demo.

Try it on your repo. Two commands, MIT, nothing leaves your machine until you configure a bucket.

$claude plugin marketplace add kgaidev/kgai
$claude plugin install kgai@kgai-marketplace
★ Star on GitHub

See how kgai compares to other tools on the comparison page, or browse the other notes.