The most useful knowledge base I operate has no embeddings, no chunking strategy, and no similarity thresholds. It is a folder of markdown files with an index at the top, and an LLM maintains it. So when Andrej Karpathy published his "LLM knowledge base" pattern — an Obsidian vault where the model compiles raw material into a structured wiki and then navigates it by reading indexes instead of querying a vector store — I recognized it immediately, because a version of that architecture has been quietly running my own development workflow for months. The pattern deserves the attention it got, and it also deserves a more honest accounting of where it wins and where it breaks than the hype gave it.
What Karpathy actually proposed
In April 2026, Karpathy posted the workflow on X with an accompanying GitHub gist, and the architecture has three layers.
The raw vault. Everything starts in a raw/ folder inside an Obsidian vault — a deliberate dumping ground. Web articles clipped with the Obsidian Web Clipper, papers, repo docs, transcripts, your own notes. The one rule is that nothing in it needs organizing. That matters more than it sounds: most knowledge systems die from ingestion friction — tagging, categorizing, filing — and this one reduces ingestion to dragging a file into a folder. (One practical note if you clip web articles: install the Local Images Plus community plugin so images download into the vault instead of breaking when the remote source moves.)
The compiled wiki. This is the divergent idea. Instead of indexing raw documents for retrieval, the LLM reads them and writes new ones — encyclopedia-style articles per concept, a master index.md listing every wiki, sub-indexes per topic, and [[wiki-style links]] between related ideas. The compilation is synthesis, not summarization: the model merges multiple sources into one coherent article, notes where they contradict each other, and builds the cross-references itself. You point an agent like Claude Code at the vault with a prompt like: "Read the files in raw/ about [topic]. Create wiki/[topic]/ with an index.md, one article per major concept, backlinks to related wikis, and update the master index."
The query path. When you ask a question, the model does not search. It reads the master index, opens the relevant wiki's index, reads the specific articles, and follows backlinks if the question spans topics. That is how a human researcher works — check the catalog, walk to the shelf — not how a similarity search works.
The load-bearing distinction, and the part most coverage buried: the LLM is the author of the knowledge structure, not just a consumer of retrieved chunks. During queries it navigates a house it built. It knows where things are because it put them there.
The version of this I already run
Here is my grounding for taking the pattern seriously: my Claude Code sessions on this site's codebase maintain exactly this architecture, automatically, as project memory. There is a MEMORY.md that functions as the master index — one line per topic with a link to a dedicated topic file: translation status, SEO recovery timeline, feature history, server reference. When a session learns something durable, it writes it into the right topic file and keeps the index current. The next session — days later, zero shared context — reads the index, opens only the topic file it needs, and continues as if it remembered.
That is Karpathy's pattern at small scale: markdown files as the store, an index as the entry point, the LLM as both librarian and author. And the observed behavior matches his claims. Retrieval never misses in the way vector search misses, because there is nothing probabilistic in the path — the model follows named links from an index it wrote. When something is wrong, I open the file and read it, because the entire debugging surface is human-readable text. After months of this, the system has never returned a "top-5 chunks" answer that forced me to reassemble the actual insight myself.
Why vector RAG loses at this scale
Traditional RAG earns its infrastructure at enterprise scale — millions of documents, concurrent queries, latency budgets. But most individual developers are managing hundreds of documents, not millions, and at that scale the pipeline introduces three problems the markdown approach simply does not have.
Chunking is a permanent compromise. Every chunk-size choice trades context against noise, there is no universally correct value, and the wrong one silently degrades every query. The wiki approach has no chunks — articles are written at concept granularity by something that understands the concept.
Similarity is not relevance. Vector search returns the most mathematically similar chunks, which are frequently five near-identical paragraphs from one document while the genuinely relevant insight from another sits far down the ranking. The wiki's backlinks encode conceptual relationships — connections a model noticed while synthesizing — which lexical similarity structurally cannot represent.
Embeddings are a black box. You cannot browse a vector store, spot coverage gaps by scanning it, or check whether a document was indexed correctly. A wiki you can open in any editor.
The trade is scale. Karpathy pitched this for personal knowledge bases in the low hundreds of documents; beyond that, compilation time grows and index coherence degrades, and you are back in genuine RAG territory. Using a hosted vector database to manage forty documents was always resume-driven architecture — the honest match for that job is a folder and a capable model.
The limitations nobody leads with
Compilation costs tokens, forever. Every significant ingestion means recompiling the affected wiki. Batching — accumulate raw material, compile weekly — keeps it reasonable, but a continuously updating base pays a real recurring cost that a vector index does not.
The wiki is a snapshot. An article clipped ten minutes ago is invisible to queries until compiled. Traditional RAG indexes new documents in seconds; this does not.
Compilation quality is model quality. Weaker models produce shallower synthesis, lazier cross-references, and worse index structure. Spend frontier-model tokens on compilation; queries can run on something cheaper, because navigating a well-built wiki is the easy half.
It is single-user by design. No access control, no concurrent editing, version history only if you put the vault in git (do).
And one lesson from operating my own index that transfers directly: compile narrow, link wide. A sprawling "everything about AI agents" wiki produces mush — vague articles, backlinks connecting things that are barely related. Tight topic scopes with cross-wiki links between genuinely distinct domains is where the structure starts surfacing connections you had not made yourself. Also review the first compilation of each wiki manually; the model occasionally chooses a granularity that does not match how you think, and ten minutes of restructuring early beats compounding it for months.
Where this leaves the architecture debate
The tools have split into two honest camps: heavyweight retrieval platforms for document collections that genuinely need them, and what Karpathy calls LLM knowledge bases — markdown, indexes, and a model — for the rest of us. The mistake is using camp-one tools for camp-two problems, and the pressure pushing people toward that mistake is mostly aesthetic: a vector pipeline feels like engineering, a folder of markdown feels like cheating.
The underrated part of the markdown design is the exit path. Everything is plain text — if you outgrow it, your files feed directly into whatever you graduate to; if Obsidian vanishes, the vault opens in VS Code. No migration, no lock-in. Infrastructure decisions that keep the exit cheap are the ones you stop regretting.
If you already use Obsidian with Claude Code, the compilation step is the natural upgrade to what you have: I covered the memory side in how Obsidian fixed Claude Code's biggest weakness and the broader setup in my Claude Code second brain walkthrough — Karpathy's insight is that the model should also write that structure, not just read it. For where this sits among the other persistence options, my six levels of Claude Code memory maps the landscape, and his related CLAUDE.md conventions are in my Karpathy CLAUDE.md and skills install guide.
The wiki earns its keep the first time it surfaces a connection between two ideas you never linked yourself — that payoff arrives after roughly twenty articles and one compilation, and no similarity score has ever handed it to me. The prompts I use to compile and query my own vault sit in my prompt library.
