You are three months into a codebase with Claude Code. You ask it to add search. It suggests Elasticsearch. Your team evaluated Elasticsearch in the spring, rejected it on cost, and moved on. Nothing in the repo says so, the person who made that call is on another team now, and the agent has no way to know. So you relitigate it, again.
This is the part of AI-assisted development that nobody's tooling is quite solving. The agent writes code fluently. What it cannot do is remember why your code is the way it is, what your team already tried, and what got ruled out. That knowledge lives in people's heads and dead chat threads, and every new session starts from zero.
The obvious move is to bolt on a memory layer. There are good ones. mem0, Graphiti and Cognee are the three you will run into first. They are all worth knowing. But if what you actually want is a shared record of your team's decisions wired into your coding agent, each of them solves a related problem, not that one, and getting them to do your job means taking on their complexity. Here is the honest version of why.
What these tools are built for
All three are memory layers for agents and applications. Their job is to remember facts about a user or an agent, and to track how those facts change over time. That is a real and hard problem, and they are good at it. It is just a different problem from recording the decisions a team makes while building software.
mem0 is the easiest to reach for. It is a vector-first memory layer, Apache-2.0, with a hosted platform and a clean Claude Code integration over MCP that captures and recalls automatically. The catch for our use case is what it stores and how. It distills text into user-scoped facts, and when a new fact contradicts an old one it reconciles them by updating or removing the old fact. For personalization that is exactly right. For decision history it is the wrong shape, because the thing you most want to keep, the reason approach A was rejected, is the thing that gets overwritten.
Graphiti, from the team behind Zep, is the richest of the three and the closest in spirit to what decision memory needs. It is a graph-first framework that builds a temporal knowledge graph. When new information contradicts an old fact it does not delete the old edge, it marks it invalid and keeps the time boundaries, so you can ask what was true then and what is true now. It also lets you define your own entity and edge types. That temporal, non-destructive model is genuinely the right primitive. The cost is operational. You run a graph database (Neo4j, FalkorDB or Neptune), an LLM and an embedding pipeline, and you ingest data as structured episodes. It is powerful, and it is a lot to stand up and keep running.
Cognee sits in between. It is an open-source memory engine, Apache-2.0, that turns data into a knowledge graph and can run anywhere from a single Postgres instance to a full graph-plus-vector stack. It has a Claude Code plugin and supports custom ontologies. What it does not have is built-in versioning or supersession of facts, so the part where a decision replaces an earlier one, with the earlier one preserved, is something you would build yourself.
The two gaps for team decision knowledge
Strip away the differences and the same two gaps show up in all three.
The first is semantic. None of them models a decision as a first-class thing. There is no built-in notion of a decision, its rationale, the alternatives that were considered and rejected, or a link from a new decision to the one it supersedes. You can approximate some of this by defining a custom ontology, most cleanly in Graphiti, but you are building the model, not using one.
The second is operational. These are memory layers for facts, and to make one serve a whole team you have to run a shared, multi-author backend that everyone reads and writes, with some notion of review. That means a vector store, or a graph database, or both, plus an LLM doing extraction on every write, plus the service that fronts it. For a team that wanted its decisions to stop getting relitigated, that is a real infrastructure project before the first decision is even recorded.
None of this is a knock on the tools. It is what happens when you use a general memory layer for a specific job it was not designed for.
What decision memory actually needs
Write down what the coding-team use case really requires and the list is short and specific:
- A decision as an immutable record, not a fact that gets edited in place
- The rationale attached to it, so the why survives the person who made the call
- Supersession as a first-class link, so a reversal keeps the old decision and the reason it died
- Rejected approaches and dead ends kept on purpose, because "we tried X, it cost us a day, here is why we stopped" is worth more than X quietly missing
- A shared store the whole team and their agents read and write
- All of it inside the coding loop, recalled before the agent touches an area and captured as decisions are made
That is a narrower target than "remember everything about the user," and narrowing it is what lets you skip most of the machinery.
Where kgai is different
We build kgai, so treat this as the interested party's account, but the design follows directly from that list.
kgai is not a general memory layer, and that is the point. It records one thing, the structural decisions your team makes while coding, as an immutable graph. Every decision carries its rationale. When a decision is reversed the new one supersedes the old one by an explicit link, and the old one stays in history with the reason it died. Dead ends are kept on purpose. Recall returns only the decisions that are currently in force, so the agent reads the current picture before it changes code, and the superseded ones stay available when you are auditing why direction changed. The first issue ever filed on our own repo was that recall was handing back superseded decisions, which taught us the hard way that keeping dead ends and serving them are two separate problems.
The operational story is the part that differs most from the tools above. kgai is local-first. The store lives inside your project directory. There is no vector database, no graph server, no embedding pipeline, and no service to operate. It installs as a Claude Code plugin in two commands. Capture happens in the session and a hook at the end of the turn catches anything the model forgot to record. The graph is rebuilt deterministically from the log, so the same decisions produce the same graph on every teammate's machine. Team sync is opt-in, over an S3 bucket you own, and it is conflict-aware rather than last-writer-wins. Git-remote sync is supported too but still experimental, so S3 is the path I would lean on today. Since 1.0 you can also set one machine-wide default remote with kg remote --global, so each new project syncs without per-project setup. On a store of a million decisions across thirty writers, a decision lookup answers in about a hundred milliseconds. kgai hit 1.0 in July 2026, and from that release the on-disk log format, the kg CLI surface and the JSON output shapes follow semver, so a breaking change to any of them means a major version bump. It is MIT licensed.
The honest tradeoff is the flip side of the scope. If you want an agent to remember arbitrary facts, conversation history, or a user's preferences across products, kgai does not do that and mem0, Graphiti and Cognee do. Use them for that. kgai is for the case where the thing you keep losing is your team's decisions, and where standing up a memory service to hold them is more than you want to run.
Which to reach for
If you need general agent or personal memory over changing facts, these are strong, and Graphiti in particular has the most serious model of time and history. If you specifically want your team's decisions, their rationale, their reversals and their dead ends to survive, recalled inside Claude Code without operating a backend, that narrower shape is what kgai is built for.
The plugin is open source, stable as of v1.0.0, and installs in two commands. Details, the benchmark, and what still does not work well are on kgai.dev.
claude plugin marketplace add kgaidev/kgai
claude plugin install kgai@kgai-marketplace
Top comments (0)