Dead ends are documentation. Keep the paths your team rejected.
In March your team spent a week evaluating a graph database and said no. In July an AI agent proposed it again, confidently, and the one person who remembered the week was on vacation. So the team spent another week arriving at the same no.
Shipped code documents itself. It has tests, comments, a commit history. The paths you didn't take have nothing, and they're the ones that keep coming back.
The options that lost are the most useful history
Nobody re-proposes the thing you built. They re-propose the thing you didn't, because the rejection lives in a closed Slack thread or in the head of whoever argued it down. Every new hire walks the same corridors, and every fresh AI session is a new hire with excellent confidence and zero tenure. An agent that can't see the dead end will suggest it, on the merits, exactly like your team did the first time. That's the failure mode behind an AI re-proposing the database you rejected.
The economics are lopsided. Re-litigating a settled question costs a week of evaluation, argument, and sheepish convergence on the old answer. Recalling the recorded answer costs a second.
Struck through, still queryable
This is where kgai's design gets opinionated. We build it, so judge accordingly. The store is an append-only, immutable decision log. When a decision loses, it isn't deleted, it's superseded through an explicit link that carries the reason. Recall returns only decisions still in force, so the dead ends never clutter what an agent reads before editing. But they stay in the graph, struck through and queryable, and asking for an element's history returns the whole chain, the losers included, with why each one lost.
Rejections also get captured at the moment they're cheapest to capture. The agent that just chose option B over option A knows precisely why A lost, right then. kgai records at that write boundary through a skill and hooks, so the rejection enters the log while the reasoning is still concrete instead of six months later from memory.
And a rejection isn't forever. When the constraint that killed an option goes away, you record a new decision that supersedes the old one, reason attached, and the reversal becomes part of the same history. Repeal needs a record too.
No daemon, no server, sync opt-in over an S3 bucket you own, MIT. The dead ends your team paid for are documentation. Start keeping them where the next agent will actually look.
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.