"kgai vs Zep: a managed context platform and a local-first decision log"
You're giving an agent memory that has to hold up in production. Zep and kgai both keep history instead of overwriting it, which is why they end up in the same shortlists. Almost everything else about them is different, starting with whose memory it is.
What Zep does well. It builds a temporal knowledge graph from chat threads, business data, documents and JSON. When new data invalidates a prior fact, the time it became invalid is stored on the fact and history is preserved. It assembles a context block of the facts most relevant to the current thread, its docs cite sub-200ms retrieval, and it models users and their threads directly, so an agent can carry a running picture of each person. The engine underneath is the open-source Graphiti.
Where kgai differs. Where the memory lives. Zep is a managed service you send your data to, and that's precisely its value, someone else runs it at scale. kgai is local-first with an embedded engine. No server, no daemon. Syncing is opt-in, against an S3 bucket you own, and writers never share a shard, so a textual conflict has no way to happen.
How a memory gets made. Zep extracts facts from what flows through it, using an LLM. kgai records decisions the agent writes explicitly as it works, into an append-only immutable log with a deterministic projection. No model calls and no embeddings in the read path, and the same log replays to the same graph on every machine.
What a memory is about. Zep's graphs are typically about users and what's true of them over time. kgai's graph is about a codebase. Each decision carries the why and the rejected alternatives, supersession is an explicit link with a reason, dead ends stay with the reason they died, and recall returns only what's still in force.
Choose Zep if you're shipping a product whose agents need memory of users, conversations and business data, and you want that run for you at scale. Per-user personalization is its job and kgai simply doesn't do it. Choose kgai if the memory that keeps going missing is your own dev team's why. The unit it stores is the decision, full stop. Not conversation memory, not user profiles, and not much use if agents rarely touch your code.
Zep's engine gets its own comparison in kgai vs Graphiti. If it's the team's decisions you're losing, the install is two commands and the first "why is this like this" answers itself.
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.