An LLM wiki is a knowledge base that an AI reads, writes, and keeps current for you. Instead of retrieving fragments from raw files on every question, the way RAG tools do, the model files each new source once into a set of linked markdown pages, then maintains them. Cross-references, contradictions, and synthesis are already there when you ask. Andrej Karpathy named the pattern; Google Cloud published a file format for it.
How is an LLM wiki different from RAG?
Most people use LLMs and documents through retrieval augmented generation. You upload files, the model finds relevant chunks at query time, and it writes an answer. It works, but nothing accumulates. Ask a question that needs five documents stitched together and the model does that stitching from scratch every single time.
An LLM wiki inverts the order. When you add a source, the model reads it and integrates it into an existing set of pages: it updates the entity page, revises the topic summary, and notes where the new source contradicts an old claim. The knowledge is compiled once and then kept current. When you later ask a question, the reconciled view already exists. The wiki is a compounding artifact; RAG is a lookup that starts over each time.
What are the three layers of an LLM wiki?
The pattern has three clean layers, and keeping them separate is most of what makes it work.
- Raw sources. Your curated, immutable source documents: articles, papers, notes, data. The model reads them but never edits them, so you always have a source of truth.
- The wiki. A directory of model-written markdown: summaries, entity pages, concept pages, an index, an evolving synthesis. The model owns this layer completely. You read it; it writes it.
- The schema. A configuration document, such as a CLAUDE.md for Claude Code or an AGENTS.md for Codex, that tells the model how the wiki is organized and what to do on each operation. This is what turns a general chatbot into a disciplined maintainer, and you refine it over time as you learn what works.
What operations keep the wiki current?
Three recurring operations do the work. Ingest: you drop in a source and the model files it, often touching ten to fifteen pages, then appends a line to a log. Query: you ask against the wiki and the model answers with citations, and a good answer can be filed back as a new page so your explorations compound too. Lint: every so often the model health-checks the wiki for contradictions, stale claims, orphan pages, and missing links.
Two files carry navigation as the wiki grows. An index.md catalogs every page with a one-line summary, read first at query time. A log.md records what happened and when, newest first, with a consistent heading so it stays greppable. At the scale of a few hundred pages this indexing works well without any embedding database.
Is there a standard format for it?
Yes. Google Cloud published the Open Knowledge Format, a minimal and tool-agnostic specification for exactly this kind of knowledge base. It is deliberately thin: a directory of markdown files with YAML frontmatter, no schema registry and no required tooling. Conformance asks only that every file has parseable frontmatter with a non-empty type field, and that reserved files (index.md, log.md) follow a set structure. Karpathy's write-up is the practice; the Open Knowledge Format is a portable format for the artifact, so you can move a wiki between tools.
Which tools do you need?
Less than you would expect. The wiki is just a git repository of markdown files, so you get version history and diffs for free. Obsidian is a common front end because its graph view shows which pages are hubs and which are orphans, while the model edits on the side. At small scale the index file is enough to find things; as the wiki grows you can add a local markdown search engine so the model can look pages up directly. None of it is required to start.
The same first-class-agent shift shows up in software, not just knowledge work: see agent-native architecture. And because a coding agent maintaining files behaves best on tidy inputs, the habits in clean code for AI agents apply here too. For the wider picture, browse the Learn AI section.
Why does this pattern work?
The hard part of a knowledge base was never the reading or the thinking. It was the bookkeeping: updating cross-references, keeping summaries current, flagging when new data breaks an old claim, holding dozens of pages consistent. People abandon wikis because that maintenance grows faster than the value. A model does not get bored, does not forget a cross-reference, and can edit fifteen files in one pass, so the cost of maintenance falls to near zero. Your job becomes curating sources and asking good questions; the model does everything else. It is close in spirit to Vannevar Bush's 1945 Memex, a private, curated store where the links between documents matter as much as the documents, except now something is willing to do the upkeep.
FAQ
Is an LLM wiki the same as RAG?
No. RAG retrieves raw chunks at query time and re-derives the answer each time. An LLM wiki integrates each source once into maintained pages, so the synthesis and cross-references persist and improve as you add more.
Do I have to write the wiki myself?
No, that is the point. You curate sources, direct the work, and ask questions. The model writes and maintains the pages. You review the results rather than authoring them.
What tools do I need to start?
A capable coding agent, a folder of markdown files under git, and a short schema file describing your conventions. Obsidian and a local search tool are helpful additions, not requirements.
Does it scale?
For a personal or team knowledge base of up to a few hundred pages, a plain index file works well and avoids embedding infrastructure. Beyond that you can add a local search engine over the markdown without changing the pattern.