The real asset in an AI knowledge base isn't the notes
In every AI-maintained knowledge base, one file carries the owner's judgement and compounds. The wiki pages are the least valuable part.
If you handed an AI agent the same folder of raw material twice, once with a careful instruction file and once without, you would get two different knowledge bases from identical inputs. That gap, not the notes themselves, is where the value sits.
Since Andrej Karpathy’s gist of 4 April 2026 put the “AI knowledge base” pattern in front of a mass audience, most of the attention has gone to the wiki: the folder of AI-generated markdown pages that answers questions the raw sources never could on their own. But Karpathy’s own architecture puts the emphasis somewhere else. His gist describes three layers: the immutable raw sources, the wiki the agent writes, and a schema document, typically a file called CLAUDE.md or AGENTS.md, that tells the agent how the wiki is structured and how to behave. In his words, that file is “what makes the LLM a disciplined wiki maintainer rather than a generic chatbot”.
The file that carries the judgement
Kenneth Reitz’s essay of 6 March 2026 makes the point more concretely than anyone else in the field. His vault runs to 467 files, governed by a roughly 200-line CLAUDE.md he frames explicitly as an “API contract” with the agent. Its most valuable section, on his own account, is not an instruction about what to write. It is a list of prohibitions: “Do not create new files unless explicitly asked… Do not restructure existing folder hierarchies.” The negative space, what the agent is told never to do, is doing as much work as anything it is told to produce.
This pattern repeats across the practitioners who have run these systems long enough to have an opinion worth reading. The instruction file is where an owner encodes what “correct” looks like for their business: what counts as a source worth trusting, what structure the knowledge should take, what must never be touched without asking first. It is judgement, made explicit and durable in a way that used to live only in one person’s head or scattered across a hundred old decisions nobody wrote down.
The wiki pages the agent produces from that file are, by comparison, replaceable. Delete them and point the same agent at the same raw sources under the same instruction file, and you get something close to the same wiki back. Delete or degrade the instruction file, and every page it produces afterwards drifts: Karpathy’s own comment thread through June 2026 records practitioners hitting exactly this failure, an unconstrained agent generating “company, Company, Business, and Organization” as four different entities across different runs, because nothing pinned the vocabulary down.
Why this matters more than the notes
There is a reason this detail keeps showing up as an aside in practitioner write-ups rather than as the headline. It is less visually interesting than a well-organised wiki, and it does not photograph well in a demo. But it is the one artefact in the whole system that is genuinely an operator’s own intellectual property. The raw sources were not created for this purpose. The wiki pages are a derived, regenerable output. The instruction file is the one thing that only exists because a specific person sat down and decided, in writing, how their business’s knowledge should be handled and what the agent is and is not allowed to do with it.
That has a practical consequence for anyone setting one of these systems up: the time worth spending carefully is not on organising the first batch of notes. It is on writing the prohibitions and the structure into the instruction file before the agent starts producing anything, because that file is what every future page inherits, and it is the part that does not get regenerated if it goes missing. A business that treats the instruction file as a five-minute afterthought and the wiki as the real project has the emphasis backwards.
It is also the part of the exercise that has to stay with the person who runs the business, not with whoever is operating the keyboard on a given day. Getting that file right is exactly the kind of hands-on work we do with teams directly, building their own judgement into their own systems rather than handing them something to operate blind, in our AI Working Sessions.