What is an LLM wiki?

An LLM wiki is a knowledge base of linked Markdown pages that a language model writes and maintains from a set of raw sources, instead of searching those sources from scratch for every question. Andrej Karpathy described the pattern in April 2026 in an “idea file”: a one-page description meant to be handed to a coding agent, which then builds the system.

His point in one sentence from that file: “the wiki is a persistent, compounding artifact.” Every new source is folded into pages that already exist, contradictions get resolved once, and the next question starts from that work rather than from the raw documents.

Three layers: sources, wiki, schema

Layer	What it is	Who writes it
Raw sources	Articles, papers, PDFs, images, data files. The source of truth, never edited	People collect them
The wiki	Summaries, one page per entity and concept, comparisons, an overview, all linked	The model, entirely
The schema	A file such as AGENTS.md that defines structure, conventions, and workflows	People and model together

Two files keep the wiki navigable. index.md is a catalog of every page by category, updated on each ingest. log.md is an append-only record of what happened when. Karpathy browses the result in Obsidian, which shows the links as a graph, and keeps it in Git for history.

Three operations: ingest, query, lint

• Ingest. Add one source. The model summarizes it, discusses the takeaways, updates the index, edits every entity and concept page the source touches, and appends to the log. Karpathy notes one source can touch 10 to 15 pages, and prefers to ingest one at a time.
• Query. The model reads the index, opens the relevant pages, and answers with citations to them. A good answer can be filed back into the wiki as a new page, so questions make the wiki better.
• Lint. A periodic health check: contradictions, stale claims, orphan pages, concepts mentioned but missing a page, absent cross-references, gaps in the data.

At the scale Karpathy describes, about 100 sources and a few hundred pages, the index file is enough to find things; no embeddings or vector database are needed. Past that, he points to local search tools.

LLM wiki vs RAG

Retrieval-augmented generation (what RAG is) searches the raw documents at question time and hands the best passages to the model. An LLM wiki does the reading in advance. Both answer from your own content; they suit different situations.

	LLM wiki	RAG
Work happens	When a source arrives	When a question arrives
Best size	Up to a few hundred curated sources	Thousands to millions of documents
Answers come from	Pages the model already synthesized	Passages retrieved from originals
Strength	Connections across sources, resolved contradictions	Fresh data, exact quotes, huge corpora
Readable by people	Yes, it is a wiki	Not directly, it is an index
Main risk	Errors compound in pages that get reused	Missing context when retrieval picks the wrong passages
Permissions	Mixed sources end up on shared pages	Enforced per document at query time

The last row decides most business cases. A RAG system can check who is asking and only retrieve documents that person may see. A compiled wiki merges sources into shared pages, so a summary can leak what a single document would have kept restricted. Build one wiki per audience, or keep RAG where access rights vary.

What an LLM wiki looks like in a company

Karpathy lists business wikis among the use cases. The pattern fits where a team keeps asking the same questions of a slowly growing pile of documents:

• Product knowledge. Data sheets, certificates, and supplier PDFs folded into one page per product family, with the contradictions between versions flagged by lint.
• Support. Solved tickets and manuals turned into answer pages that the support team, and a support agent, read first.
• Onboarding. Process documents, decisions, and meeting notes as a wiki a new hire can browse and ask.

Four rules make it safe:

1. Sources stay untouched. The model may write the wiki, never the originals. Every page links back to the sources it came from.
2. Lint on a schedule, review by a person. Errors in a wiki get reused. The health check finds them; someone who knows the domain decides.
3. The log is the audit trail. What came in, what changed, when. That record is what makes the wiki trustworthy months later.
4. Mark who wrote each page. A field such as author: human keeps a page off-limits for the model, which may read and link it but never rewrite it; author: agent pages can be rewritten, and a person promotes them after review. Without the split, an agent-written wiki drifts toward generic phrasing, and a human-written one goes stale.

FAQ

Who came up with the LLM wiki? Andrej Karpathy, former director of AI at Tesla and a founding member of OpenAI, described it in April 2026, first in a post on X titled “LLM Knowledge Bases” and then in a GitHub gist called llm-wiki.

Is an LLM wiki the same as a second brain? Similar goal, different author. In a second brain a person writes the notes. In an LLM wiki the model writes them and the person curates the sources and the rules.

Do I need a vector database for an LLM wiki? Not at a few hundred pages; an index file works. Larger wikis add search, at which point the setup starts to look like RAG over the wiki.

Which tools does it need? A coding agent that can read and write files (Claude Code, Codex, or similar), a folder of Markdown, and optionally Obsidian to browse it and Git for history. The idea file contains no code; the agent builds the rest.

Can an LLM wiki replace RAG? For a curated, slow-moving knowledge base, often yes. For large, fast-changing document sets with per-user permissions, no. Many systems end up with both: a wiki for the synthesized knowledge, retrieval for the long tail.

See what answers from your own content feel like with the free Chat With Your Website demo, which builds a retrieval index of your site on the fly. Knowledge bases on company documents, wiki or RAG, with the permissions they need, are part of our AI integration work.