An LLM wiki is a persistent, compounding knowledge base that an AI agent builds and maintains in structured markdown. Unlike a standard RAG (Retrieval-Augmented Generation) system that retrieves static chunks on every question, an LLM wiki compiles information once into living entity pages and summaries, then keeps them current. Popularized by Andrej Karpathy, the pattern treats your knowledge as a version-controlled codebase, and the model as a disciplined maintainer that cross-references new data into existing files rather than re-deriving context from scratch each time.
The approach leans on the expanded context windows of frontier models to give you a "second brain" that grows more valuable with every source. By keeping a human-readable directory of interlinked text files, you turn the LLM from a generic chatbot into a structured knowledge engine. Synthesis happens during ingestion, so queries become deterministic routing over a curated repository instead of a fresh scramble through raw documents.
What is an LLM wiki? The "stop retrieving, start compiling" idea
The LLM wiki is a shift from "rediscovering knowledge from scratch" to "incremental compilation." In a standard RAG setup, the model retrieves fragments of raw files every time you ask something, often missing broader context or failing to synthesize across documents. The wiki pattern treats the knowledge base as a codebase that is continuously compiled: every new source is a chance for the agent to update entity pages, revise topic summaries, and flag contradictions.
The result is a compounding artifact. Because synthesis already happened during ingestion, the wiki gets richer with every source you add. The agent establishes cross-references immediately and states the relationships between concepts explicitly in the text. Instead of the model piecing together fragments at query time, it navigates a pre-structured map of information it has already processed and filed.
The user–agent split is central. You act as director and curator, supplying high-quality sources and steering the focus of research. The model handles the grunt work of bookkeeping — summarizing, cross-referencing, and maintaining the index. That removes the main reason people abandon wikis: the maintenance burden. Using frontier models like Claude Opus 4.8, the agent works on a local directory of files, turning the filesystem into its working memory.
How is an LLM wiki different from RAG?
The differences come down to infrastructure complexity, retrieval reliability, and cost. RAG is a probabilistic system that relies on vector embeddings and cosine distance to find "similar" text; an LLM wiki is deterministic, relying on intent-based routing through structured navigation, which sidesteps the "retrieval misses" common to semantic search.
- Token efficiency. A naive RAG approach might load several full PDFs (say, 60,000 tokens) to answer one question. A curated markdown wiki covering the same ground often needs only 2,000–3,000 tokens. That 95% reduction happens because the agent is routed to a dense, pre-synthesized summary rather than raw context.
- Infrastructure. RAG needs a pipeline: embedding models, a vector database (Pinecone, Weaviate), and chunking logic. An LLM wiki needs only a folder of markdown files and a capable agent like Claude Code.
- Reliability. RAG systems suffer "silent failures" where similarity search returns irrelevant chunks. In an LLM wiki, the agent reads selectively: it consults a routing file, identifies the specific pages it needs, and reads only those in full.
- Auditability. Vector databases are black boxes. A markdown wiki is a plain-text directory you can version-control with Git, so you can track every change the agent makes and review how its knowledge evolved.
The three-layer architecture: raw, wiki, and schema
A functional LLM wiki is organized into three layers that define how the agent interacts with data.
- Raw sources. An immutable source of truth: original articles, transcripts, PDFs, and images (stored in
/raw/assets/). The model reads from these files but never modifies them. - The wiki. The LLM-owned directory of markdown files representing entities, concepts, and logs. This layer is heavily interlinked with
[[wiki links]]to form a navigable graph of knowledge. - The schema. The configuration layer, defined in files like
CLAUDE.md. It holds the naming conventions and workflow rules — the "disciplined maintainer" layer that stops the agent from acting as a generic chatbot and forces it to follow strict bookkeeping.
During a session these layers work as one system: the agent uses the schema to understand how to process a new file from the raw layer and how to integrate that information into the interlinked pages of the wiki.
The three core operations: ingest, query, lint
Maintenance is governed by three operations.
- Ingest. When a new source lands in
/raw, the agent processes it. A single ingest may trigger updates across 10–15 interlinked pages, append a record to the log, and update the main index. - Query. The agent uses
index.mdas a routing file. Asked a question, it consults the index to find relevant pages and synthesizes an answer with specific citations, avoiding "context-stuffing" by reading only the files it identified while routing. - Lint. A health-check pass: the agent scans the wiki for contradictions, stale claims superseded by newer data, and "orphan pages" with no inbound links.
A typical log.md entry follows a strict chronological format so you can parse it with standard command-line tools:
## [2026-04-12] ingest | The Bitter Lesson — Rich Sutton
- Created: [[The Bitter Lesson]], [[Rich Sutton]]
- Updated: [[Reinforcement Learning]], [[Moore's Law]]
- Status: Integrated; added cross-links to [[Software 2.0]].