"kgai vs engram: two local-first memories with different units"
This is the closest comparison we get asked about. Both tools are local-first, MIT, a single small install with nothing to operate, and both search lexically instead of through embeddings. If you're choosing between them you're already thinking about memory the right way. The split is what a memory is, and whose infrastructure syncs it. We build kgai.
What engram is good at. One Go binary, zero dependencies. Memories live in SQLite with FTS5 full-text search under ~/.engram, agents save them over MCP with structured What, Why, Where and Learned fields, and there's a CLI, an HTTP API and a TUI besides. It works with any MCP agent today, Claude Code, Cursor, Codex, Copilot and the rest. The local database stays the source of truth and cloud replication is opt-in.
Where kgai differs, structurally.
- A note vs a decision. engram's unit is a saved memory with fields. kgai's is a decision that mutates a small graph of domain elements. Supersession is an explicit link with a reason, recall returns only in-force decisions, and dead ends stay in history with why they failed. The full argument is in what decision memory is.
- The log is the source of truth, not a database. kgai's graph is a projection of an append-only, content-addressed log, rebuildable and byte-identical across machines. A decision lookup answers in about 100 ms at 1M decisions across 30 writers' shards, and to be fair about it, recall and free-text search are slower.
- Whose sync. engram replicates through a central cloud endpoint, one destination per installation today (an open issue, #570, asks for per-project routing). kgai syncs to an S3 bucket you own, and per-writer shards mean parallel writers can't produce a textual conflict.
- Reach, honestly. engram speaks MCP to any agent right now. kgai's automatic capture is a Claude Code plugin, other agents go through the CLI, and an MCP endpoint is in cloud beta.
Choose engram if you work across many different agents and want one memory box for all of them today. Choose kgai if you're a team, the LLM does most of the coding, and the memory that matters is the decision record, synced through storage you control. Neither tool personalizes per user, and kgai doesn't keep conversations at all. For the transcript-keeping end of this space, see kgai vs mempalace.
The install is two commands and writes nothing but plain files. Point one project at it and check what the graph holds after a week.
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.