Normally, to get an LLM to answer over your own documents, it reads them fresh every time you ask — you paste them into a chat, or RAG fetches the relevant snippets per question. Whatever the model figures out is thrown away the moment you move on.
Andrej Karpathy floated a different setup (original gist here): let the LLM read your sources once and write what it learns into a lasting, cross-linked set of markdown notes — a wiki — that it keeps maintaining. From then on it answers from its own notes, not the raw docs, so your knowledge accumulates instead of being rebuilt on every question.
The whole thing is just three layers:
1 · Raw sources — the articles, papers and notes you feed it. The LLM reads these but never edits them.
2 · The wiki — markdown pages the LLM owns: one per entity or concept, plus summaries and cross-links. You read these; the LLM writes them.
3 · The schema — a single config doc (think CLAUDE.md) telling the LLM the house rules: what pages to make, how to name them, when to update versus create. This is what turns it from a generic chatbot into a disciplined librarian.
Concretely, the wiki is nothing exotic — it's a directory you could open in any text editor:
A folder of markdown doesn't look like much — so why does it matter? The easiest way to see it: Wikipedia. A huge web of cross-linked pages, kept current by an army of editors. A personal wiki is the same idea shrunk to your own knowledge — people have wanted one for years, but never had the editors to keep it alive. That's the shift: the LLM is the editor. From here I'll get into how you actually build and query one, how it stacks up against RAG, and whether it holds up beyond personal notes — at work.
Here's why that editor earns its keep. The expensive part of a knowledge base was never the reading or the thinking — it's the bookkeeping. Updating the right page when a new fact lands. Fixing the five other pages that referenced the old version. Keeping the index current. Noticing that two notes now quietly contradict each other. That drudgery is exactly why human-maintained wikis rot: nobody keeps up.
An LLM does that drudgery for almost nothing. It can touch fifteen files in a single pass and never forgets a cross-reference. That one shift — near-zero maintenance cost — is what makes a compounding knowledge base actually sustainable. Once upkeep is basically free, you get four things:
Synthesis happens once, not per query. Answers come back faster and cheaper because the hard work was already done at ingest — and the pages get better every time you add a source.
Cross-references persist. The link between two ideas is written down once and reused, instead of being rediscovered on every question.
Contradictions surface. A periodic pass can catch "page A says X, page B says not-X" — something no stateless RAG query ever notices.
Your explorations compound. A good answer becomes a new page, so the next related question starts from where you left off, not from raw chunks.
The human's job shrinks to the two things only a human can do: curate what goes in, and ask good questions. The LLM handles everything in between. So how do you actually run one?
Conceptually, an LLM wiki is just three repeating operations sitting on top of two core files. No pipeline to build — you're mostly writing the schema and then letting a coding agent do the work.
The two core files: index.md is a catalog listing every page with a one-line summary, so the LLM can navigate without reading everything. log.md is an append-only history (## [2026-07-12] ingest | Caffeine & sleep onset) so both you and the model can see how the wiki evolved.
All three reuse the same muscle — the LLM does the reading and the bookkeeping — but they do different jobs. Let's walk through each with its own visual.
When a new source lands, the LLM pulls out the key facts, updates the pages they touch, adds cross-links, and appends to the log. Here's what one pass looks like when a new article hits my sleep wiki:
1A new article lands in sources/. The wiki already has a few concept pages — you can see them in index.md. Nothing about adenosine yet.
2The LLM reads the source guided by the schema — not free-form. It pulls out the entities and claims, and notices adenosine is a new concept that deserves its own page.
3In a single pass the LLM updates caffeine.md (new claim + a [[adenosine]] cross-link), creates adenosine.md, refreshes the index, and logs it. That four-file bookkeeping — done for free — is the whole point.
A query never touches the raw sources. It reads the index, opens the page (or two) it needs, and answers from the already-synthesized text — then files a good answer back so the wiki gets richer:
1A question comes in. The LLM reads index.md first — the one-line catalog — and sees the caffeine page already covers timing and mechanism. No search over raw sources needed.
2Open the one page. The three facts are already stitched together, with citations — that work happened back at ingest. The model reads an answer instead of reconstructing one from scratch.
3The step RAG can't do: file the answer back. A good Q&A becomes a new section, so next time it's already there — your explorations compound instead of vanishing.
Left alone, any wiki drifts: two pages start disagreeing, a page ends up with nothing linking to it, an old fact quietly falls behind a newer source. Lint is a sweep that catches and fixes that drift — the maintenance a human would skip:
1Every so often — nightly, or on demand — lint reads the whole wiki at once and checks for the four messes that pile up as it grows.
2It surfaces three, each a different kind of drift: two pages contradict each other (both live in the wiki — which is right?); one orphan page has nothing linking to it; and one page is stale — a newer source revised a fact, but the page still shows the old one.
3Lint fixes all three in one pass — reconciling the contradiction (old version kept in history), adding the missing link, and updating the stale page to its newer source. The wiki stays consistent without you touching it.
And the SCHEMA.md is what keeps all three consistent. It's the real product here — hand the same schema to a different model six months from now and your wiki keeps its exact shape. The pages are the output; the schema is the thing you actually design.
There's a catch hiding in that last line. Your SCHEMA.md pins down your wiki — but the field names, the folder layout, the way you write links are all just choices you happened to make. Build a wiki with one tool and a different agent can't read it without custom glue, because it has no idea what shape you picked. For a personal wiki that's fine. The moment you want to share one — hand it to a teammate, point another agent at it — every wiki being its own snowflake becomes the whole problem.
In June 2026 Google Cloud shipped a fix: the Open Knowledge Format (OKF), a small open spec (still v0.1) that standardizes the exact markdown folder we've been building — so a wiki one tool writes, any agent can read, no translation (the announcement). The whole spec fits on a page, and that restraint is the design: standardize just enough to interoperate, leave everything else to you. Here's a real OKF page — our caffeine note, in the format:
Strip it to what the spec actually mandates — and, just as telling, what it leaves wide open:
One file per concept. The file's path is the concept's identity — no IDs to hand out or keep unique.
One required field: type. That's the entire mandate. A few optional reserved fields are there if you want them — title, description, resource (a URL), tags, timestamp — and any other field you invent is allowed.
The body is plain markdown. No structure imposed — headings, tables, prose, whatever the concept needs.
Links are ordinary markdown links. [adenosine](adenosine.md), and those links taken together are the knowledge graph. Note it's normal links, not Obsidian [[wikilinks]] — so every page renders on GitHub exactly as written.
Two reserved filenames. index.md for navigation and log.md for history — the same two files we already used, both optional. No manifest, no config, nothing else to learn.
Notice OKF and your SCHEMA.md aren't the same thing, and don't compete. OKF is the envelope — "every page carries a type and links with markdown." Your schema is the house rules inside that envelope — which types actually exist, when to update versus create, what stays private. OKF makes your wiki legible to others; the schema keeps it yours. You want both.
So why wrap your notes in someone else's spec at all? Three payoffs, and they all fall out of the format being boring on purpose:
It's just files. Markdown in a folder — commit it to git beside your code, open it in any editor, render it on GitHub, with no database, SDK, or runtime to stand up. A human and an agent read the very same file.
Writer and reader decouple. The tool that builds the wiki and the agent that queries it never have to know each other. Swap either side for a better one and nothing breaks — the format is the contract between them.
One wiki, many agents. A wiki a teammate compiles, your agent reads without a line of glue. That's the jump from a private folder to a portable, shareable bundle — and it's exactly what makes this worth having at a company.
A portable wiki is a real step up — but it sidesteps the older, sharper question: when is a wiki even the right tool, versus just doing RAG? Time to put the two head to head.
We just watched the wiki answer that coffee question by opening one page. RAG would answer the same question in a completely different way — and that difference is the whole point.
You've probably seen the "RAG is dead" takes. That's not quite it. What the wiki really challenges is narrower and sharper: RAG retrieves and forgets. Ask something that needs five documents stitched together, and a RAG system finds the fragments and re-stitches them — every single time, from scratch. The synthesis is never written down; it's re-derived on every query and then thrown away. NotebookLM, ChatGPT file uploads, most RAG chatbots all work this way. The wiki flips it: do the synthesis once, save it as a page, and read it back later. Karpathy's line for it: "stop re-deriving, start compiling."
Same question, two paths — here they are side by side.
1A real question rarely sits in one place. This one needs three facts, stitched together — the classic case where naive retrieval struggles and synthesis matters.
2The RAG path. Embed the query, pull the closest raw chunks from three different documents, and hand them to the LLM to stitch together now. Good answer — but the synthesis is thrown away, so the next person asking pays for it all over again.
3The wiki path. The index points to a single page that already stitches all three facts together — half-life, adenosine, sensitivity — with citations. The model just reads the answer off it; the synthesis happened back at ingest, so nothing is recomputed.
4Same question, two costs, side by side. RAG re-stitches those three raw chunks every single time and throws the result away. The wiki did that stitching once at ingest, so the query just reads the ready page — and it gets richer each time.
The whole difference in one line: RAG does the synthesis at query time and discards it; the wiki does it at ingest time and keeps it. That's why wiki answers get faster and richer the more you use it, while RAG always starts over from raw chunks.
But be honest about the flip side: the wiki is only as fresh as its last ingest. On a personal wiki you curate, that's a fine trade — but a plain folder of markdown has limits, and the real question is how far it can scale.
The plain version — markdown plus a coding agent — is genuinely enough for a personal wiki, up to roughly 100k tokens / ~100 articles, the point where the LLM can still hold the index in context and navigate by it. Past that, Rohit Ghumare published an "LLM Wiki v2" mapping out what you bolt on — and crucially, it's modular. You add a layer only when you hit the wall it solves.
index.md + schema. Where everyone starts, and where most stay.Two things to notice. First, layer 3 is the tell: at scale, the wiki doesn't replace retrieval — it sits on top of it. Hold that thought for the enterprise question. Second, the schema keeps absorbing more of the design — entity types, supersession rules, what's private versus shared. The bigger this gets, the more the schema is the system.
For a personal knowledge base, the answer is an easy yes — this is the best version of the personal wiki anyone's built. The enterprise is where I'd pump the brakes, because the wiki's whole trick assumes a corpus that's bounded, and curated by someone you trust, small enough that the model can hold the map in its head. Company knowledge breaks every one of those assumptions:
Scale. Millions of documents, not a hundred. The index alone won't fit in context, so you need a retrieval layer no matter what — which is exactly the ground RAG owns.
Permissions — the real killer. Who can see what actually matters at a company. Access control has to live inside retrieval, filtering by ACLs before the model ever sees a chunk — not bolted on afterward. A single shared wiki the model reads freely across is a data-leak waiting to happen.
Compounding cuts both ways. The wiki's best trick is that a good answer gets filed back as a new page, so the knowledge keeps growing. But that only helps if what's saved is actually good — and someone has to make that call. On a personal wiki you make it yourself: you asked the question, so you can tell a solid answer from a shaky one. At company scale that judgment falls apart — thousands of people ask uneven questions, and answers often get filed automatically — so you'd need a real mechanism to decide what's worth keeping, which is hard and costly to build. Get it wrong, and a hallucinated answer becomes a permanent, authoritative-looking page that every later query inherits as fact.
Heterogeneity. Tickets, code, chats, docs, dashboards, across dozens of domains — far messier to compile into one clean set of pages than a folder of papers you chose to read.
So is it useless at work? No — but I wouldn't dissolve the wiki into one big RAG index. The version I actually believe in: a retrieval agent with two tools — one that searches the raw sources, one that queries the LLM wiki — and a prompt that tells it which to reach for. Here's how I'd wire it:
The agent holds two retrieval tools, and a prompt decides which to use: for a concept or entity — what something is, how it works, why — the wiki is the better first stop, since a page already synthesizes it; for an exact citation, a specific case, or a hard fact, raw search over the first-hand sources wins; and for a complex question, the agent queries the wiki to orient itself, then searches the sources for the specifics to cite. That sequencing is also how first-hand outranks second-hand — the wiki is a lead, the raw sources are the record.
ACL is enforced inside both tools — raw chunks by their tags, and each wiki page carrying its own per-page access tag — so nothing a user can't see reaches the model either way.
And the maintenance loop still runs, gated: an answer is only promoted into the wiki after it clears an LLM-as-judge, a curation team, or user up/down feedback — the gate that keeps bad answers from compounding — after which it's re-available to the wiki tool next time.
It was never either/or. They make opposite bets about when you pay for synthesis, and the right call depends entirely on your corpus. Here's the whole decision on one screen:
| Approach | Best when | Retrieval | Freshness | Permissions | Reach for it |
|---|---|---|---|---|---|
| LLM Wiki | Small, curated, stable corpus (personal or single-team) | Read the index, open a page — no search needed | As fresh as the last ingest | Assumes one trusted reader | Personal notes, a project's knowledge, anything you re-derive often |
| RAG | Large, dynamic, multi-domain corpus | Search (hybrid + rerank) on every query | As fresh as the index | ACLs enforced inside retrieval | Enterprise KB, open-ended lookup over many sources |
People have wanted a personal Wikipedia for years, and the one piece that never worked was who keeps it tidy. The LLM finally can. For your own notes, that's a genuinely new thing — a knowledge base that compounds instead of rotting. For the enterprise, it's less a revolution than a second tool your retrieval agent can reach for. Either way the mental shift is the same: stop re-deriving, start compiling.
These are living notes — I'll keep updating as the pattern matures. Thanks for reading.