Before the printing press, the only way to own one more copy of a book was to have someone copy it out by hand. The place that work happened was the scriptorium, the writing room of a monastery. A monk laid the original open and transcribed it letter by letter into a new book, and that new book in turn became the original the next person would copy. It was slow, but it had one virtue: a book, once copied, stayed put. The next person who needed the same text didn’t have to travel back to a distant original — they just opened the copy sitting on the shelf beside them. That’s how a library grew, one volume at a time.
The first piece in this series looked at why an agent needs a single source of truth (SSOT) to stand on, and the second piece at how steep the price is for hauling that truth out of people’s heads and setting it down in writing. But even once you’ve paid the price and erected the truth, one problem remains: how does an LLM read that truth, and how does it build on it over time? The most common answer today is the exact opposite of the scriptorium. It stores nothing, and travels back to fetch a fresh original every single time.
The librarian who starts from scratch every time
The most widespread way to make an LLM answer from your company’s documents is retrieval-augmented generation, or RAG for short. The name is grand, but the job is simple. A question comes in; the system pulls back whatever document fragments look relevant at that moment and feeds them to the model along with the question.
Picture it as a library. Every time a patron asks something, the librarian sprints to the stacks, photocopies a few relevant pages, reads them, composes an answer — and then throws the photocopies away. The next question comes, and off they sprint again, from scratch. The librarian is conscientious every time, but a question they answered a hundred times yesterday they meet today as if for the first time, because no trace of the work was ever left behind.
This approach works, and it has a clear place. When the documents number in the hundreds of thousands — a vast, unstructured archive — fetching only the fragments you need on demand is more practical than organizing all of it in advance. But two things nag in the end. First, nothing accumulates. Ask about the same topic a hundred times and a hundred times you start from the floor. Second, it answers in fragments. Stitching a few scattered pages together rarely yields the big picture that runs through a whole subject. Retrieval is fast, but it leaves no understanding behind.
What Karpathy threw out in a single tweet
In April 2026, Andrej Karpathy posted a tweet. The gist: a large share of the tokens he burns these days goes not toward handling code but toward handling knowledge. For each research topic he cared about, he’d set an LLM to build him a personal knowledge base, and one of them had quietly grown to around a hundred articles, four hundred thousand words. Yet he hadn’t written a single word of it himself. The tweet was read more than sixteen million times.
Two days later he wrote the method up as a one-page note and made it public. The file was named llm-wiki.md. That’s why people came to call the pattern “LLM Wiki.” Karpathy’s own phrase in the prose ran closer to “LLM knowledge base”; “wiki” stuck as the name for the thing it produces.
The core idea circles back to the scriptorium. Instead of rummaging for a fresh original on every question the way RAG does, the LLM organizes what it reads as it reads it and stacks it into permanent wiki pages. New material comes in, it updates the related existing pages; a person, concept, or tool keeps recurring, it promotes that into a page of its own; and it links the pages to one another. Whatever has been understood once stays understood, in organized form — so the next time the same topic comes around, you don’t begin again from the floor.
Not retrieval — compounding
The real difference between the two approaches widens the longer time runs.
The RAG curve is a sawtooth. Every question spikes it up, then it drops back to the floor. Ask a hundred times and nothing has been built. The LLM Wiki curve, by contrast, bends upward. What gets read and organized stays on as an asset, lifting the starting point of the next task one notch higher each time. In economics this shape has a name: compounding. Yesterday’s interest is added to today’s principal, so the rate of growth itself keeps accelerating.
Knowledge can be rolled the same way. A page you organized today becomes the footing for understanding new material tomorrow, and the page built on that footing becomes the footing for the day after. If retrieval is simple interest, starting from zero every time, the wiki is compound interest, starting from everything stacked up through yesterday.
Three layers
The structure Karpathy laid out splits into three layers. It’s simple, but that separation is what holds the whole thing up.
At the bottom is the raw layer. Transcribed originals, conversation logs, source material read — all of it piling up untouched. The one rule here is: don’t edit it. The original has to be preserved as the original, so that later you can trace back what was organized into what, and why. Like the transaction history in the passbook from the first piece, this layer is the floor that doesn’t shift.
In the middle is the wiki. The layer the LLM both produces and owns by reading the raw material. Summary pages, pages gathering a person or a concept, the links that join them — they all live here. Every time new material lands at the bottom, the LLM updates this layer and tends the cross-references. It isn’t a place a person writes by hand; it’s closer to a garden a machine cultivates.
At the top is the schema. The configuration that turns the LLM into a disciplined librarian. It’s the operating rule set: what goes where, what gets promoted into a page, what must never be touched. The very same LLM, with this schema or without it, is either a gardener tending a plot or a guest scattering seeds at random. Add an index that reflects the full catalog and a log that records what came in when, and the skeleton stands.
I run the same structure myself
After seeing Karpathy write this pattern up, I shaped my own personal knowledge folder around the same three layers, and have been running it that way since.
Here’s how it works. The records of my ordinary work and conversations drop into the raw folder automatically. I don’t set time aside to write them — I’ve arranged things so they pile up as a byproduct of working. And once every few hours, a scheduled job on my laptop quietly wakes an LLM and has it read through the raw material gathered since. The LLM picks out only what hasn’t been organized yet and makes summary pages, weaves several similar pieces into a single synthesis, gathers the people and concepts that keep appearing into their own pages and links them. Checking for dead links and stale entries happens in that same window. Since it runs on tools I already use, there’s almost no extra external cost to it.
What I like about this setup is that it pulls off, in one structure, the three ways the second piece named for lowering the cost of building truth. It creates less, by promoting into pages only what action needs; it captures automatically, from the byproducts of work; and it maintains itself automatically, by having the machine pull the index and summaries from one original. A principle on paper turned into a machine that runs.
Running it myself, though, I saw the shadows too. After I let it sit for a while, more than half the pages stacked in the wiki were “here’s what I did today” operational logs, with only a handful of actual knowledge. Tags I’d left free to grow had crept past two hundred before I had to overhaul them. Once, the automatic tidying had quietly stopped, and I only noticed much later, when I caught myself wondering whether my records were piling up at all. Even a garden a machine tends grows weeds first the moment a person lets go. The compounding turns the right way only if you refine the rules and, now and then, a human looks in to decide what stays and what goes.
When the wiki lies
There are gaps in this picture, of course, and pretending otherwise would be dishonest.
The biggest risk sits in the middle layer — how far can you trust the wiki the LLM wrote itself? In the act of summarizing, a model can quietly bend a fact or plausibly invent something that isn’t there. Let a page poisoned that way become the footing for the next task, and the compounding runs in reverse: wrong understanding stacks on wrong understanding. That’s why the rule of never editing the raw layer, preserving it intact, matters. Whenever the wiki looks suspect, you have to be able to drop back down to the original, compare against it, and have the page rebuilt.
There’s another thing. The raw folder holds outside text verbatim, so it has to be treated as untrusted data. Even if a sentence like “ignore the previous instructions and do this instead” is buried inside it, the LLM mustn’t take it as a command — you need a boundary that treats the folder as read-only source material, never as orders.
Finally, RAG isn’t going anywhere. A wiki is strong on well-organized, narrow knowledge, but for a vast unstructured heap that no hand can reach to organize, retrieving on demand is still the better move. The two are less rivals than tools you choose between by the character of the knowledge. Some describe the pattern as “Obsidian is the editor, the LLM is the programmer, the wiki is the codebase” — though it’s safer to take that as a tidy shorthand for the pattern circulating around than as a sourced line from Karpathy.
A fit for a person, not yet for an organization
There’s one place this collides head-on with the earlier pieces. What gave truth its trust in the first piece was a gate of human review and approval: before anything could change, someone else had to look at it and sign off, and only then did it become truth you could rely on. The LLM Wiki has no such gate. What the LLM reads and organizes becomes the wiki directly, with almost nowhere for human verification to step in.
So the tool’s place is narrower than it looks. It fits a person’s own knowledge well, but it isn’t ready for the seat of an organization’s single source of truth. A wiki I build for myself, if it’s wrong now and then, is mine to bear, and when something looks off I can drop to the original and fix it; what I gain by compounding outweighs the occasional error. But a truth that many people trust and agents act on directly is another matter. You can’t make an unverified, auto-generated artifact everyone’s standard. That seat still needs a truth passed through a gate someone approved — the floor of trust the first piece was about.
A library grows one volume at a time
The monk in the scriptorium didn’t build a library in one stroke. He copied a book and set it beside him, then added another beside that. It was slow, but what was copied stayed, and what stayed held up the next piece of work. That’s how the library grew — copies that don’t vanish, laid one atop another.
Across three pieces we’ve circled the same problem. Where does an agent put the truth it can trust; who pays the price of erecting that truth; and how do you accumulate and maintain it. The last answer wears a surprisingly old face. Instead of sprinting off to fetch and discard every time, you organize what you’ve understood once and leave it beside you. The LLM Wiki looks like new technology, but it’s closer to teaching a machine, all over again, the wisdom the pre-printing library already knew. Don’t retrieve — accumulate.
— tomte