The wiki was supposed to be the team's memory. It's a graveyard.
The page is called "Auth architecture." Last edited fourteen months ago, by someone who left in March. It describes a session store you ripped out last spring and a refresh flow that now lives in another service. Two sentences are still true. A new hire read all of it yesterday and spent a day building against the wrong half.
Nobody neglected that page out of laziness. The problem is structural. Editing a wiki is a separate task from doing the work, and separate tasks need a trigger. Shipping code has one: the build breaks, review blocks you, the deploy fails. Updating the page that describes the code has nothing. No compiler, no reviewer, no test. So it drifts one merged pull request at a time, and what you end up with isn't stale in a way you can repair, it's stale in a way you can't audit. A wiki edit destroys the previous version. When the page asserts something, you can't tell whether that was settled last week or typed in 2024 and never revisited. Same page, same confidence, no difference.
Your AI agents don't read it either. Every session starts cold and re-derives the reasoning, sometimes proposing the exact thing you tried and abandoned. Dead ends are documentation, and a wiki keeps none of them, because the losing option gets deleted when the page is rewritten.
This is the gap we built kgai to close, so from here you're reading the makers. The whole design turns on where capture happens. Our answer is the write boundary: capture rides along with the edit, via a skill and hooks, so whichever session made the structural choice is the one that files it. A wiki asks you to remember later. This asks for nothing. A Claude Code plugin covers the work inside the agent, a standalone kg CLI the work outside it.
Underneath is an append-only, immutable decision log, projected into a small graph deterministically. Nothing gets edited in place, ever. Reversing an earlier call means filing a fresh decision, joined to the old one by an explicit supersession link carrying the reason it lost. Recall returns only the decisions in force, but nothing is discarded: superseded calls and dead ends both stay queryable, so "how did we end up here" has an answer with receipts. Reads are lexical matching combined with graph traversal, embeddings absent from the read path entirely, which is why two teammates querying one store get identical results. Nothing runs in the background, no server to stand up. Team sync is opt-in over an S3 bucket you own, each writer holding a separate shard, so parallel writes never collide as text. License is MIT.
Volume holds up too. Push it to a million decisions across thirty writers' shards and a decision lookup still lands near 100 ms, with the caveat that recall and free-text search run slower than that.
Keep the wiki for the things that deserve prose, the way you'd keep your ADR folder. Just stop pretending it will update 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.