Karpathy's LLM Wiki: The Knowledge Base That Beats RAG

On 4 April 2026, Andrej Karpathy quietly published a gist describing a structured approach to managing knowledge with LLMs. He called it an "LLM Wiki." It is 800 words long, contains no code, and proposes something almost every AI tooling vendor is currently building the wrong way.

The pitch is simple: stop re-retrieving raw fragments per query. Start maintaining a synthesised, cross-linked, contradiction-aware layer of markdown entity pages that the LLM reads, writes, and lints over time. The wiki compounds. The wiki ages well. The wiki, unlike a vector store, can actually be read by a human.

We have been operating something like this at Jordan James Media for the last eight months. Our system is called Agent Vault, and it implements roughly 75% of Karpathy's pattern (as of the May 2026 update -- this post originally said 60% and the gap closed by half the same week we wrote it). This post explains the gist, why it matters more than another RAG variant, and what the remaining 25% looks like.

What Karpathy Actually Proposed

The architecture has three layers. Raw sources are immutable: articles, PDFs, transcripts, images. They never get edited after ingest. The wiki sits on top: a directory of markdown files where each file is an entity page covering one concept, person, project, or pattern. The schema is a config document (Karpathy uses the CLAUDE.md convention) that defines the wiki's conventions -- file naming, frontmatter, link syntax, contradiction handling.

Entity pages are linked using [[wiki-link]] syntax. Think Obsidian, but written and maintained by an LLM rather than a human. Each page has a stable identity (a slug) and a permeable body (the LLM updates it as new information arrives).

Two scaffolding files sit at the root. index.md is a content-oriented catalog organised by category -- the LLM reads this first when answering a query so it knows what pages exist. log.md is an append-only chronological log with consistent prefixes like ## [2026-04-02] ingest | Article Title so any agent or human can grep it for forensic history.

The Three Operations

Karpathy describes exactly three operations against the wiki, and they are remarkably symmetrical.

Ingest. A new source arrives. The LLM reads it, scans the index for pages it touches (typically 10 to 15 existing pages), updates each one in place, notes contradictions inline rather than overwriting, then appends a single log entry. Crucially, the source itself is never modified -- only the wiki on top of it.

Query. A question comes in. The LLM searches the wiki for pages relevant to the query, synthesises an answer with inline citations to those pages, and -- if the answer is good enough -- promotes the synthesis into a new entity page. The query operation is itself a content-generation step.

Lint. Periodically, the LLM does a health check over the whole wiki. It looks for contradictions between pages, stale claims that should have been updated by recent ingests, orphan pages (no inbound links), and missing cross-references where two pages obviously relate but do not link. Lint is the maintenance loop that prevents wiki rot.

These three operations are the entire API. There is no chunking strategy, no embedding model selection, no hybrid retrieval, no re-ranker. The "retrieval" is the LLM reading index.md and following links.

Why This Beats RAG

Vector-store RAG retrieves raw fragments per query. Every question is a fresh round trip -- re-embed, re-search, re-rank, re-synthesise. The fragments themselves are dumb. They do not know about each other. They cannot flag contradictions. They cannot prefer the more recent claim.

The wiki inverts the cost model. Knowledge is compiled once on ingest, then read cheaply forever. The cross-references are already there. The contradictions have already been flagged. When the LLM answers a question, it is not reasoning over a hundred fragments -- it is reading three or four entity pages that already represent the synthesis of those fragments.

Karpathy himself captures the trade-off in one line that should be on a poster somewhere: "The cross-references are already there. The contradictions have already been flagged." That is what RAG has been missing.

How Agent Vault Implements About 75% of This

Agent Vault is the production system we run for Jordan James Media's client portfolio -- Pink Slips NSW, Mr Splash Plumbing, Buggo Pest Control, dozens of others. It runs on Claude Code with about 200 entity pages of memory across 12 projects.

Karpathy's entity pages map almost perfectly to our ~/.claude/projects/<project>/memory/*.md files. Each file covers one concept (a client convention, a pricing rule, a failure mode from a past incident). Our MEMORY.md is functionally identical to his index.md -- a content-organised catalog the agent reads first. Our CLAUDE.md files are exactly his schema layer, defining conventions across the wiki.

We also mirror the wiki to a Supabase table called agent_memories so other tools can query it without filesystem access. And we have an ingest-on-correction hook: when a user pushes back on something the agent did, that correction automatically becomes a new entity page within the session. That is Karpathy's ingest operation, slightly automated.

What we do not have yet, candidly: formal [[wiki-link]] syntax (we use raw paths and grep), a multi-page ingest workflow that updates 10-15 pages per source (our ingest is mostly single-page right now), and one consolidated log.md (each session writes its own log file, which is more useful for our case but loses the global grep view). Update from the same week we first published this post: the memory-lint skill now exists in three flavors -- a structural pass at every SessionStart, a semantic pass via Claude Haiku 4.5 weekly (~$0.10/week), and a PostToolUse hook that lints every memory write in real time. First run on the live 442-memory corpus surfaced 4 ERROR-level drift bugs that were fixed the same day.

The Comparison Mental Model

Here is the cleanest way to frame the difference. RAG is a search engine for your documents -- it answers "what did source X say about Y." The LLM Wiki is an encyclopedia your AI writes for itself -- it answers "what do I currently believe about Y, given everything I have read." Those are different questions, and the second one is almost always what you actually want.

A search engine that improves with each query is a fancy index. An encyclopedia that improves with each query is a flywheel. The wiki is the flywheel.

What This Means For Your Stack

If you are building any LLM-powered knowledge product -- internal knowledge base, customer support agent, research copilot, anything that needs to remember and reconcile information over time -- Karpathy's gist is the strongest design pattern we have seen articulated in 2026. It is small enough to implement in a weekend. It is human-readable, which means an engineer can debug it. And it composes: ingest can happen on a schedule, query can happen on demand, lint can happen overnight.

Start small. One markdown directory. One CLAUDE.md schema doc. One index.md. One log.md. Let your LLM read it, write to it, and lint it. After a month you will have something that genuinely compounds. After six months you will have something a new agent can pick up in five minutes -- which is the actual test of whether your knowledge base works.

What's Next

The next obvious builds for Agent Vault are formal [[wiki-link]] enforcement and multi-page ingest workflow -- the two pieces still standing between us and the full Karpathy pattern. We will document those the same way we have documented the rest of Agent Vault: in the wiki itself, where they can be read, updated, and linted alongside everything else. (The memory-lint skill that we originally listed as the next obvious build? Already shipped -- structural, semantic, and write-time, in the week between drafting and publishing this post. The wiki keeps compounding.) If you want help applying this pattern to your own AI tooling, our content marketing service has been the entry point for several recent knowledge-base engagements, and our tools page lists the calculators and utilities we have already shipped on this stack.