The rewrite proposal that comes back every quarter
Q1, someone proposes rewriting the billing service in a different language. The team spends four days on it and lands on no, for three specific reasons involving a payment provider SDK that only ships one binding. Q2, a new senior joins and proposes it. Q3, an agent halfway through a refactor suggests it, politely, with a migration plan. Every time, the same four days, the same no, and nobody has the energy to be the one who says we already did this without being able to show where.
The proposal isn't stupid. That's what makes it immortal. It's a reasonable idea that lost to constraints nobody recorded, so it keeps arriving fresh and has to be beaten fresh.
A no that isn't written down isn't a no
It's a mood. It lasted as long as the people in that meeting stayed on the team and remembered the SDK detail. The reasons decayed faster than the decision did, which is the worst possible order, because now you have a conclusion nobody can defend and a proposal that sounds better every quarter.
Then add AI agents to the payroll. Each session starts with zero tenure and full confidence, and it will propose the rewrite on the merits exactly the way your team did the first time. This is the same shape as an AI re-proposing the database you rejected, scaled up to something that eats a quarter.
Rejected with reasons, and still queryable
We build kgai, so weigh this accordingly. It is a decision log for AI dev teams: append-only, immutable, projected deterministically into a graph. When something loses, it does not get deleted. Supersession is an explicit link carrying the reason, so the rewrite proposal sits in the graph struck through, with the SDK constraint attached and a date on it.
Two properties do the work here. Dead ends stay queryable, so why didn't we rewrite billing has an answer that outlives the meeting. And recall returns only decisions in force, so an agent reading before it edits sees the current shape without wading through every argument the team has ever had. Recall is lexical plus graph traversal, no embeddings in the read path, which means the same store answers the same question identically on every machine.
Capture happens at the write boundary through a skill and hooks, at the moment the reasoning is still concrete rather than six months later from memory. The rest of the shape: no daemon, no server, team sync opt-in through an S3 bucket you own, per-writer shards so parallel writes never cause a textual conflict. At 1,000,000 decisions across 30 writers' shards a decision lookup still answers in about 100ms, though recall and free-text search are slower than that.
It ships MIT as a Claude Code plugin, with a standalone kg CLI for everything outside a session. The next time the rewrite comes back, it meets a dated record instead of tired people. Dead ends are documentation makes the general case.
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.