kgai shared decision memory for dev teams

notes for dev teams · kgai.dev/blog

"kgai vs Mem0: user memory and decision memory solve different problems"

Start with what you want remembered, because that decides this comparison before any feature does. Mem0 remembers people. kgai remembers decisions. If you're picking one for the wrong job, the better tool will still disappoint you.

What Mem0 does well. It's a memory layer for AI assistants and agents, built for personalization. An LLM pass extracts memories from conversation, and retrieval fuses semantic similarity, BM25 keyword and entity signals scored in parallel. It publishes results on conversational-recall benchmarks like LoCoMo and LongMemEval, ships Python and Node SDKs plus integrations for LangGraph, CrewAI and the Vercel AI SDK, and runs as a library, a self-hosted server, or a hosted platform. Apache-2.0.

Where kgai differs. What a memory is, to begin with. A Mem0 memory is a fact about a user, extracted from what they said. A kgai memory is an engineering decision. What changed, why, and what was rejected, written into an append-only immutable log. A replaced decision is superseded through an explicit link with a reason, and the dead end stays in the graph with the reason it died.

The write path. Mem0 runs an extraction model call to decide what's worth keeping. In kgai the agent that's already doing your work records the decision itself, so capture adds no pipeline and no extra model calls.

The read path. Mem0 retrieves through embeddings fused with keyword and entity signals, which is the right shape for fuzzy recall over prose. kgai recall is deterministic, lexical matching plus graph traversal with no embeddings in the read path, and it returns only decisions still in force. The same store gives the same answer on every machine.

What you operate. Mem0 needs an embedding model and a vector store, or its hosted platform. kgai has no server and no daemon. Team sync is opt-in, into an S3 bucket you own, and every writer appends to a shard of their own, which is why parallel recording never ends in a textual conflict.

Choose Mem0 if you're building a product that should remember its users across sessions, or you need semantic recall over large amounts of conversational prose. That's its home ground and kgai doesn't attempt it. Choose kgai if the memory you keep losing is your dev team's why. It's decision-level memory for teams where the LLM does most of the work. No per-user personalization, no conversation memory, and thin capture if humans write everything by hand. A closer cousin on the personalization side is Zep, compared in kgai vs Zep.

They don't overlap, and some teams will sensibly run both. The question is only which memory you're missing today.

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.