The LLM Wiki: compiling knowledge instead of retrieving it

The pattern comes from a short public gist by Andrej Karpathy, and it is a folder layout rather than a product. Nothing needs to be installed. It divides the work between material you never touch, pages a model writes, and a file in which you state the rules the model has to follow. It has since produced a string of follow-up write-ups and at least one desktop implementation, but the original is a page of instructions you can paste into an agent.

The middle layer carries the idea. A wiki page is not a summary of a document: it is a page about a concept, assembled from every source that touched it. A page called "retrieval evaluation" might be fed by nine papers read over seven months, rewritten each time one of them changed the picture. That is the difference between a folder of summaries and a knowledge base, and no amount of searching over the source folder produces it. The unit being an idea rather than a document is the same move Niklas Luhmann's slip box makes, described in Zettelkasten and evergreen notes; the difference is who does the writing.

The schema is named AGENTS.md in Karpathy's version because that is the filename several coding agents read on startup. In a Claude Code setup the same role is played by CLAUDE.md, and in a hand-rolled script it can be any file you prepend to every prompt. The name matters only in that the agent has to load it. The contents matter enormously.

A schema that says "keep the wiki up to date" produces sprawl: near-duplicate pages, summaries masquerading as concepts, and confident sentences with nothing behind them. A useful one is closer to a style guide with enforcement rules, and most working versions cover the same eight things.

• Scope. What belongs in the wiki and what does not. Without this the agent will happily write a page about every proper noun it encounters.
• Granularity. One page per concept, project or entity, with a rule for when to split a page that has grown two subjects and when to merge two pages that turned out to be one.
• A page template. Typically: a one-sentence definition, current state, how it got there, open questions, related pages, sources. A fixed shape is what makes fifty pages comparable.
• Titles that state something. A page titled "Caching" collects everything; a page titled "Cache invalidation is done on write, not on read" states a claim that can be checked and, when it stops being true, corrected.
• Dates on everything. Every claim carries the date of the source it came from, so a reader can tell a current fact from a fact that was true in March.
• Contradiction handling. The default should be explicit: when a new source disagrees with a page, keep both with their dates and mark which supersedes which, rather than silently overwriting. Silent overwrites destroy the history that made the wiki worth compiling.
• Provenance. Every claim links back to a file in raw/. More on this below; it is the single rule that separates a checkable wiki from a plausible one.
• Prohibitions. What must never be written down: credentials, personal data, anything under a confidentiality obligation. An agent with filesystem access will otherwise copy whatever it finds.

Twenty to forty lines is enough for a first version. The schema is not something you get right in advance. You write it, run one ingest, read every page it produced, and then add the rules whose absence you can now see.

Ingest is the compile step. A new source arrives, the agent decides which concepts it touches, and it updates those pages: adding a claim, revising one that changed, creating a page for something that appeared for the first time. A good ingest prompt is a plan-then-write split. First pass: read the schema and the new source, then output the concepts it touches, marking each as new, changed or unaffected, with the sentence from the source that justifies it. Second pass: for each affected concept, read the existing page and write the revised version in full. Asking for both at once tends to produce a rewrite that quietly drops half the page it was meant to extend.

Batching helps more than it looks. Ingesting a week of material at once lets the agent notice that the same constraint appeared in three separate sources, which a strictly one-source-at-a-time ingest cannot see.

Query runs against wiki/, not against raw/. This is the part that is easy to miss: the pattern does not remove retrieval, it improves the corpus retrieval runs over. Search a folder of fifty synthesized pages, or simply load the relevant ones whole, and the model answers from material that was written to be an answer. Keep a path back to raw/ for the cases where the page is not enough.

Lint is the operation people skip and the one that keeps the wiki from rotting. A lint pass walks the whole tree looking for duplicate or near-duplicate pages, contradictions between pages, claims with no source link, pages nothing links to, and stale material whose date has passed the point where it should have been rechecked. Monthly is usually enough. Treat the output as a report you read, not as edits you accept unseen; a lint that silently rewrites pages is a second compiler with no supervision.

Retrieval-augmented generation embeds your documents into a vector store and, when a question arrives, fetches the most similar chunks and hands them to the model. It is well understood, cheap to stand up, and covered in detail in local RAG. A compiled wiki does the same synthesis work, but earlier, and stores the result. The two are not competitors so much as two places to spend the same effort.

Read the last two rows together and the division of labour is clear enough. If your questions are mostly "where was that mentioned", compilation is expensive overhead over a search index. If they are mostly "what do we currently think about X, and how did we get here", retrieval over raw material will keep handing you fragments to reassemble by hand, at every asking. Most working setups end up hybrid: the wiki as the default corpus, raw search as the fallback when a page cannot answer.

A compiled page is an assertion by a model about material you may not remember. What makes it trustworthy is being able to get back to that material in one step. Three conventions do this well enough, and any of them beats none.

• Inline references. Each claim ends with a link to the source file and a locator: [raw/2026-03-11-postmortem.md#rollback]. Verbose, and the most useful when you are actually checking something.
• A sources block per page. Every page ends with the list of raw files it was built from, in date order. Cheaper to maintain, coarser to verify against.
• Front matter. A machine-readable list of source files and the date of the last ingest, which is what a lint script reads to find pages whose sources have changed.

The rule that gives these teeth belongs in the schema: the agent may not write a sentence it cannot attribute to a file in raw/. Anything it wants to add from its own general knowledge goes in a clearly marked section, or nowhere. Without that line, a compiled wiki gradually fills with reasonable-sounding material that no source ever said, and there is no way to tell which sentences those are.

The compiled wiki is one answer to a question other systems answer differently. The manual answer is a note-writing practice, where you do the synthesis yourself and the value is largely in having done it. The middle ground, where a model suggests links, tags and summaries inside a vault you still own, is in AI-enhanced PKM and agent memory, which also covers how this same three-layer split reappears as an architecture for agent memory: wiki/ as semantic memory, the schema as procedural memory, the raw log as episodic.

The pattern pays off most in any setting that generates source material continuously without anyone choosing to write it: research reading, support tickets, a project's documents, or the record of what was said in meetings, which is the subject of from meeting to knowledge base. The raw layer accumulates whether or not anyone maintains it, and compilation is what turns accumulation into something you can consult.