Finally got around to reading Karpathy's LLM Wiki gist (yeah, late to the hype train XD).
And honestly, the whole idea collapses into something pretty simple: "updatable RAG".
1. The problem
When LLMs work with documents, nothing accumulates. Every query - the model retrieves chunks, synthesises from scratch, forgets. Knowledge never compiles. And imo what matters even more: almost no useful info gets extracted from the dialogues themselves.
RAG helps partially (in the broad sense - a folder of .md files is also RAG), but the standard pipeline (which everyone uses) has no built-in update, distillation, or self-cleanup. Knowledge lands in the index once and then just sits there idle. That gap is exactly what LLM Wiki closes.
Karpathy's inversion: between raw sources and you sits a markdown wiki the agent incrementally writes and maintains. Compile once, keep current.
2. Architecture: 3 layers
- raw/ - sources, immutable. The agent doesn't write here.
- wiki/ - the heart of the system; markdown pages (entities, concepts) the LLM writes and cross-links itself. Essentially graph-shaped knowledge.
- CLAUDE.md - just the manual for how to run LLM Wiki. Holds: page format, link conventions, ingest flow, lint rules. The thing that turns Claude from a chatbot into a disciplined wiki maintainer.
Enough for hundreds of pages with zero extra tuning:
3. Operations
Three operations - you immediately want to draw them as API functions:
- Ingest -> add(source: file | list[file]). Drop a source -> agent reads -> discusses with you -> writes summary -> updates index -> edits related entity pages -> appends to log. One source touches 10-15 pages.
- Query -> search(prompt: str). The most important op. Answers your question + (THE KEY PART) automatically files the synthesis back into the wiki as new pages. Exploration compounds instead of dying in chat history. Under the hood it's basically add(source=dialogue).
- Lint -> lint(). No args. Periodically walks the wiki: contradictions, orphan pages, stale facts, missing cross-refs. Trigger - every N user messages, or a changed-lines counter. Easy to attach to /schedule.
Strongly reminds me of Claude Dreaming - I think Dreaming is partially inspired by this pattern (though its function set is a bit different).
4. Indexing
Two special files make the wiki navigable:
- index.md - current state. Catalogue of every page with a one-liner. The agent reads it first on any query - it's the minimum context "what's even in this wiki".
- log.md - log of all events, free-form. Append-only timeline. If lines follow a consistent shape (e.g. \
## [YYYY-MM-DD] ingest | title\), the log greps cleanly with plain unix tools - handy for audit.
index.md can scale further (vector index, BM25, GraphDB, ...) - I'll cover that in a separate post.
5. Takeaways
Here's how I'd frame it: this isn't a choice between RAG and LLM Wiki - they're two points on the same "compounding memory" axis.
RAG doesn't have to be a vector DB - a folder of markdown files is also RAG.
So you can rephrase LLM Wiki as RAG with three things bolted on top:
- A summarisation layer.
- (Almost) free-form authoring of the structure on that summary level.
- Periodic structural audit + self-improvement (CRON).
