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

*"Mem0 gives assistants memory of their users. kgai gives dev teams memory of their decisions. A fair comparison of two tools that barely overlap."*

Start with what you want remembered, because that decides this comparison before any feature does. Mem0 remembers people. kgai remembers [decisions](https://kgai.dev/blog/what-is-decision-memory). 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](https://kgai.dev/blog/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 kgai

Two commands, MIT, nothing leaves your machine until you configure a bucket:

```
claude plugin marketplace add kgaidev/kgai
claude plugin install kgai@kgai-marketplace
```

Source: https://github.com/kgaidev/kgai
See how kgai compares to other tools: https://kgai.dev/compare
All notes: https://kgai.dev/blog/

---

Canonical: https://kgai.dev/blog/kgai-vs-mem0 · Written by kgai maintainers · kgai is MIT open source