Why KAUT

Why KAUT — not Memory, not RAG, not a Wiki

Every team that puts AI agents on a real codebase rediscovers the same problem: the agent starts every session with amnesia, re-explores the project, asks the same questions — and keeps making the most expensive kind of mistake, code that compiles and passes tests but quietly breaks a business rule it had no way of knowing about. The "why" of a project is usually written nowhere. Three familiar tool categories promise to fix this. Each fails in its own characteristic way, and KAUT is built precisely around those failure modes.

The failure modes

Memory systems remember the wrong thing

Cross-session agent memory stores conversations: what was discussed, what the user prefers, what worked last Tuesday. That is episodic and personal — useful, but it is not knowledge about the system. Nobody can verify a recollection, no mechanism flags it when the code moves on, and it lives inside one agent's context format, unreadable to your team.

Ask the two questions and the difference is obvious:

• Memory answers "what did we talk about?"
• KAUT answers "how does this project work, and why?"

KAUT is the project's documentation, written AI-first: organized by domain, source-bound, freshness-checked, trust-labeled — and readable by any agent and by humans. The boundary is enforced in the write path: personal notes never enter the store; project knowledge never stays trapped in one agent's memory.

RAG retrieves text, not truth

Retrieval-augmented generation indexes whatever text exists — code, docs, tickets — and serves the best-matching chunks. Two structural problems:

1. No freshness contract. A chunk from a file rewritten three months ago still embeds beautifully and still ranks first. Retrieval has no notion of "this was true at commit X and the world has moved"; stale text is served with exactly the same confidence as fresh text. For an agent that acts on what it reads, that is not a nuisance — it is the bug factory.
2. The wrong selection. RAG is at its best over text that is already there. But the knowledge that hurts most is the knowledge that is written nowhere: the decision made in a hallway in 2019, the invariant that spans four services, the reason the obvious refactor was rejected twice. There is nothing to retrieve.

KAUT inverts both choices. It stores only what passes the litmus test — expensive to re-derive, not cheaply visible in the code — as short distilled docs a model reads whole: no embeddings, no chunking, no ranking. And every doc is anchored: it names its source files and the commit it was derived at, and on every read the engine diffs those sources against the tracked main branch — in git, at git speed, with no model calls. When the sources moved, the verdict flips to stale and the answer says "re-check this, here is what changed" instead of pretending. When git cannot prove anything, KAUT errs toward stale — a false "stale" costs a re-check; a false "fresh" ships a bug.

RAG over your codebase and KAUT are not rivals: retrieval finds where things are said; KAUT holds what the code does not say.

Wikis and auto-generated docs rot silently

A wiki is only as alive as the discipline of its editors, and LLM-generated documentation is worse: plausible prose, unverified at birth, abandoned at the first commit that contradicts it. The failure mode is identical — silent rot. The page looks authoritative long after it stopped being true, and nothing warns the reader.

In KAUT, a doc cannot exist without typed source bindings and a commit anchor (the contract is validated at the door), and it cannot stay wrong silently — its sources are diffed on every read. The write path completes the picture with a layered gate:

• Mechanical layers (route tables, package graphs, service maps) are regenerated from the code — never hand-written, never hallucinated, always reproducible.
• Operational facts an agent verified in this session (a runbook step, a fixed procedure) land at agent tier through the pipeline.
• Judgment-tier knowledge — decisions, domain semantics, contracts, anything where being wrong is expensive — never lands without a human (under the recommended write policy; which layers are gated is configurable per store): updates queue as drafts, and the owner reviews the batch in one sitting, one keystroke per doc.

A wiki decays by default. KAUT's default is to confess.

What this buys you

• Trust routing instead of blind faith. A verdict is attached to every answer: healthy + precise coverage = usable as-is (skip the re-derivation you'd otherwise pay); stale, broken, or coarse-altitude = confirm in code first. Knowledge informs the agent — it never authorizes actions by itself.
• Injection containment. The store is read by AI agents, so an out-of-pipeline edit is an attack surface, not a convenience. Anything not byte-identical to the last pipeline commit is withheld entirely (tampered) until restored or legitimately landed.
• Upkeep that costs git, not GPUs. Freshness checks are pure git comparisons. The repair loop is placed where it is cheapest: the change site (touched names the docs your diff owes an update), the read site (refresh hands back a delta bundle — exactly which sources changed, against which commit to re-derive), and honest usage telemetry (digest) so you can see whether maintenance keeps pace with rot.
• Legacy codebases first. Years of undocumented decisions, original authors gone, business rules visible only as side effects — precisely where AI tools underperform today and precisely what KAUT was built for: making legacy codebases AI-native.

Where it sits in your stack

KAUT is a standalone product. One clone, zero dependencies, no services: connect the bundled MCP server to whatever harness you already use (or invoke the CLI from any skill or prompt) and the full loop works — lookups with verdicts, gated writes, the draft queue, telemetry. Nothing else is required.

It is also a deliberately narrow knowledge layer: it knows; it never operates. That makes it compose cleanly with whatever drives your agents — the sibling project TAUT integrates KAUT natively (one setup answer), but any orchestrator, or none at all, works the same. Your repository is never modified either way.

Next: Getting Started · Core Concepts