Andrej Karpathy quietly published an 800-word gist proposing a structured layer of LLM-written markdown pages that compound, cross-link, and lint themselves. Here is what the pattern looks like, why it beats raw RAG, and how Agent Vault already runs about 60% of it.
What Karpathy Actually Proposed
The architecture has three layers. Raw sources are immutable. The wiki sits on top -- a directory of markdown entity pages linked with [[wiki-link]] syntax. The schema is a config doc (Karpathy uses the CLAUDE.md convention) defining how the wiki behaves.
The LLM Wiki
Karpathy's April 2026 gist
A structured synthesis layer that compounds, ages well, and beats raw RAG on the trade-offs that actually matter.
Three-Layer Architecture
Raw sources, wiki pages, schema config
The Three Operations
Karpathy describes exactly three operations against the wiki, and they are remarkably symmetrical. 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.
One source touches 10-15 existing wiki pages on ingest, not one isolated chunk in a vector store.
The Three Operations
Plan
Audit
Redirect
Test
Launch
Ingest, Query, Lint
The Three Operations Loop
Every interaction with the wiki is one of three operations. The arrows show how they feed each other.
Ingest
Read a new source, update 10-15 existing pages, log it
Query
Search the wiki, synthesise with citations, promote good answers
Lint
Flag contradictions, stale claims, orphan pages, missing links
The dotted return arrow is lint feeding back into ingest -- the maintenance loop that prevents wiki rot.
Why This Beats RAG
Vector-store RAG retrieves raw fragments per query -- the fragments are dumb, do not know about each other, and cannot flag contradictions. The wiki inverts the cost model: knowledge is compiled once on ingest, then read cheaply forever. When the LLM answers a question it is reading three or four pre-synthesised entity pages, not a hundred raw fragments.
RAG vs LLM Wiki
Re-retrieves raw fragments per query
Reads pre-synthesised, cross-linked pages
How Agent Vault Implements About 60% of This
Agent Vault is the production system we run for Jordan James Media's client portfolio. About 200 entity pages across 12 projects, mirrored to a Supabase table, with an ingest-on-correction hook that auto-promotes user pushback into a new entity page. The pattern maps almost perfectly to Karpathy's three layers -- memory files are entity pages, MEMORY.md is the index, and CLAUDE.md is the schema.
Related Reading on This Stack
A few adjacent posts and pages that explore how we build and ship knowledge systems at Jordan James Media:
- Content marketing service -- the entry point for knowledge-base engagements
- Playbooks hub -- repeatable processes we have codified for clients
- Tools and calculators -- live utilities we have shipped on the same stack
- Case studies -- knowledge-base patterns applied to real client work
The cross-references are already there. The contradictions have already been flagged.
— Andrej Karpathy
What This Means For Your Stack
Start small. One markdown directory. One CLAUDE.md. One index.md. One log.md. Let your LLM read it, write to it, and lint it. 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.
Apply This Pattern to Your AI Tooling
We have been deploying LLM-wiki style knowledge systems for clients across plumbing, automotive inspection, and legal services. If you want help mapping your existing knowledge into this pattern, the entry point is our content marketing service.
Explore Content MarketingStart Your Own Wiki
One directory, one schema doc, one index file, one log. Let your LLM read it, write it, and lint it.
Get More AI Architecture Insights
Patterns we are testing in production, monthly. No newsletter platforms, no scheduling tools -- just whatever we built recently and what we learned shipping it.
Frequently Asked Questions
Is the LLM Wiki pattern a replacement for RAG?
Not strictly. The wiki sits on top of -- or in place of -- vector-store retrieval, depending on the use case. For knowledge that needs to compound and reconcile over time, the wiki wins. For one-shot search across a static document set, RAG can still be the right tool. Many teams will end up running both.
How big can the wiki get before it stops working?
Karpathy does not give a hard number, but the practical ceiling is whatever fits in the LLM's context window when reading index.md plus a small handful of entity pages. With current frontier models that is comfortably tens of thousands of pages.
What is the minimum viable version of this pattern?
One folder. One CLAUDE.md schema doc explaining your conventions. One index.md listing every entity page. One log.md with grep-friendly date prefixes. The LLM does the rest.
Social Media Carousel
7 cards • Download as ZIP (images) or PDF (LinkedIn)
The LLM Wiki
Karpathy's April 2026 gist
A structured synthesis layer that compounds, ages well, and beats raw RAG on the trade-offs that actually matter.
Three-Layer Architecture
Raw sources, wiki pages, schema config
One source touches 10-15 existing wiki pages on ingest, not one isolated chunk in a vector store.
The Three Operations
Plan
Audit
Redirect
Test
Launch
Ingest, Query, Lint
RAG vs LLM Wiki
Re-retrieves raw fragments per query
Reads pre-synthesised, cross-linked pages
The cross-references are already there. The contradictions have already been flagged.
— Andrej Karpathy
Start Your Own Wiki
One directory, one schema doc, one index file, one log. Let your LLM read it, write it, and lint it.
Share This Article
Spread the knowledge