kgai vs Mem0, Zep & Memov for a dev team's shared memory
Four good tools that remember four different things. This page says plainly which is which — including what kgai doesn't do — so you can pick in ten minutes.
We build kgai, so read accordingly. Every claim about the other tools comes from their public docs and repos; if we got something wrong, tell us — team@kgai.dev — and we'll fix it.
Different tools remember different things
None of these is a drop-in replacement for another. The real question is what do you need remembered?
Your team's decisions. Why the code is the way it is — what changed, the reasoning, and the alternatives you rejected. Shared by every dev and every AI on the team.
Your users. A memory layer that learns preferences and facts about a person across sessions, to personalize an assistant or app.
Facts over time. A temporal knowledge graph built from your conversations and documents, with real time-validity on every fact.
Your sessions. A git-like timeline of one developer's agent sessions — prompts, responses and diffs you can search and replay.
What each one is, underneath
| kgai | Mem0 | Zep / Graphiti | Memov | |
|---|---|---|---|---|
| Unit of memory | A decision — what changed, why, what was rejected — mutating a small graph of domain elements | Facts about a user, extracted from conversations | Entities + facts with validity windows, extracted from text | Session snapshots — prompt, response, plan, diff |
| How it's captured | By the agent itself, during normal work — a skill records, a hook catches what it forgot. No pipeline, no extra LLM calls | LLM extraction pipeline per exchange (add / update / delete) | LLM extraction pipeline per episode | Session recorder |
| History | Immutable, append-only. New decisions supersede old; dead ends stay queryable; kg as-of replays any past date | Reconciled — memories are updated or deleted as facts change | Non-destructive — contradicted facts are invalidated but kept | Immutable snapshots, rollback via branches |
| Deterministic? | Yes. Content-addressed events, deterministic ids — every machine replays the log to a byte-identical graph, verifiable with kg export --canonical (sha256) | Extraction depends on the LLM run | Extraction depends on the LLM run | Snapshots are deterministic, per machine |
| Team sync | Any S3 bucket you own. Write-once per-writer shards — parallel writers can't produce a textual conflict; real contradictions surface as an explicit branch to resolve | Hosted platform; per-user / per-agent scoping | Runs as a service; team story via Zep Cloud | Per-repo timeline; no multi-writer merge story |
| What you operate | Nothing. Embedded engine in the plugin — no server, no database, no API key | Vector store + LLM/embedding keys, or the hosted platform | Graph DB (Neo4j / FalkorDB) + LLM calls, or Zep Cloud | Local tool + MCP server |
| Retrieval | Lexical + graph traversal; no embeddings, by design — the asking agent bridges synonyms by rephrasing | Semantic vector + keyword hybrid — stronger fuzzy recall | Semantic + graph + keyword hybrid | Semantic search over session history |
| Works with | Claude Code plugin (automatic); any agent or script via the kg CLI; MCP endpoint in cloud beta | SDKs (Python/TS), MCP, many framework integrations | Python SDK, REST, MCP | MCP (Claude Code, Cursor, …) |
| Measured at scale | 1,000,000 decisions / 30 writers: ~100 ms decision lookups, byte-identical clones — numbers | Benchmarks target conversational recall (LoCoMo) | Benchmarks target conversational recall (DMR, LongMemEval) | — |
| License | MIT, local-first; hosted cloud in beta | Apache-2.0 + hosted platform | Apache-2.0 engine + Zep Cloud | MIT |
Sourced from each project's public README and docs, July 2026. Corrections welcome.
What about the others?
The three columns above each stand for a whole category. If you're evaluating one of these, here's where it fits:
Same category as Zep: builds a knowledge graph + vector index from your documents with an LLM pipeline. Strong at ingesting arbitrary content; same trade-offs on determinism and infrastructure.
Same category as Mem0: memory for an assistant or its users — self-editing agent state, memory-OS research, user profiles. General agent memory, not a record of a team's engineering decisions.
A session recorder for Claude Code: compresses past sessions so the next one starts informed. A different job than a decision graph — teams happily run it side by side with kgai.
Closest neighbours in spirit: dev-knowledge logs and repo wikis for coding agents. kgai differs on the deterministic graph, byte-identical replay and conflict-free team sync.
Built for one job: a team that must not lose its why
Everything below follows from one design choice: memory as an immutable log of decisions instead of a mutable pile of extracted facts.
- The why survives, verbatim. Nothing is overwritten — new decisions supersede old ones, and "how did this get this way?" always has an exact, dated answer.
- Dead ends are memory too. Rejected approaches stay in the graph with the reason they died, so neither a new hire nor an AI re-walks a path the team already proved wrong.
- Deterministic, verifiably. No LLM in the storage path means the same log replays to the same graph on every teammate's machine — and you can check it: kg export --canonical digests match, sha256-for-sha256, tested to a million decisions.
- Sync without a server. A bucket you own is the whole backend. Write-once shards make textual merge conflicts impossible by construction; genuine contradictions become explicit branches, and the resolution is itself a recorded decision.
- Remembering costs no tokens. Capture rides the coding session your agent is already having — no extraction pipeline, no embedding bills, no background jobs.
- Nothing to babysit. No database to upgrade, no service to monitor, no API key to rotate. Local-first: reads and writes are instant and work offline.
Six commands, lifetime total
Prebuilt engine for Linux & macOS downloads itself. No Go, no compiler, no database.
Any S3-compatible bucket you own. No server, no accounts to manage, no lock-in.
Capture and recall are automatic in the session. Ask by hand anytime: kg search, kg history.
The claims above are tested numbers
Full latency table, including the slow paths we haven't fixed yet, on the performance section.
Asked by people choosing
Can I use kgai and Mem0 together?
Yes, and it can make sense: they don't overlap. Mem0 remembers who the user is; kgai remembers why the code is the way it is. An agent can read both.
Zep also keeps history — how is kgai different?
Zep's temporal graph is genuinely good, and it's the closest tool to kgai on this axis. The difference is what goes in and how: Zep extracts facts from prose with an LLM (probabilistic, needs a graph database and extraction calls), while kgai stores explicit decisions written by the agent as it works — deterministic, replayable, no infrastructure. Zep answers "what was true when"; kgai answers "what did we decide, and why".
What happens when two people decide the same thing differently?
Both decisions survive — sync cannot lose either, by construction. The element shows up in kg conflicts as a branch with both heads; anyone resolves it by recording one new decision that supersedes both. The branch and its resolution stay in history.
What if kgai the project disappears?
Your store is an append-only NDJSON log of content-addressed events sitting in your repo (and your bucket, if you sync). It's plain text — readable, greppable and portable without our code. MIT-licensed engine, no hosted dependency in the free tier.