Karpathy’s LLM Wiki: a second brain the model keeps up to date

In the first article of this series I described a second brain as an external memory that answers questions instead of merely storing notes. This one describes the method my own system is built on.

The idea itself is older than language models. Renaissance scholars kept commonplace books, notebooks of excerpts from their reading arranged under subject headings, and the Polish gentry kept silva rerum, household books into which they copied anything worth remembering. In the twentieth century the German sociologist Niklas Luhmann built a card index of some 90,000 cards in which every note referred to others. He wrote dozens of books and hundreds of scholarly articles, and by his own account he owed that output to the card index. The name “second brain” was popularized by Tiago Forte, author of the 2022 book Building a Second Brain. His method rests on four steps: capturing material, organizing it, distilling its essence, and putting it to use in your work. All of these steps, however, were carried out by a person, who decided what to save, organized the notes, and made sure the cross-references stayed current.

In April 2026 Andrej Karpathy, one of the founders of OpenAI and former head of AI at Tesla, published a short note on a pattern he called the LLM Wiki. In short: a language model builds and maintains an organized wiki from your materials, while you supply the sources, ask the questions, and make the calls.

Karpathy stresses that he is not publishing a program or a set of instructions, only a description of an idea. You paste that description into your own AI assistant and work out the details together with it. That is why the pattern is easy to overlook: there is nothing to install. My own knowledge base has run on it since June 23, 2026, so I can describe not only the idea itself but also what it leads to after more than three months of daily use.

The problem the LLM Wiki solves

The most common way of working with a model and documents goes like this: you upload files, ask a question, and the model retrieves matching fragments and assembles an answer from them. That is how NotebookLM works, how files attached to a chat work, and how most document search systems work.

This approach works, but it has a flaw that Karpathy names directly: the model rediscovers the knowledge from scratch every time. If an answer requires putting five documents together, the model puts them together for every question, and the result of that work disappears with the conversation. Nothing accumulates. If two sources contradict each other, the model has to notice it all over again with every question the contradiction affects.

The LLM Wiki works the other way around. The model does the work of synthesis once, when a source is added, and saves the result as lasting pages. By the time you ask the next question, the connections already exist, the contradictions are already flagged, and the summary already reflects everything read so far.

Three layers

The pattern divides the system into three parts, and each has a different owner.

The sources belong to you, and nobody changes them. They are articles, documents, transcripts, and meeting notes. The model reads and cites them but never edits them. They are the point of reference: six months later you can check what was actually written, not what the model remembered of it.

The wiki belongs to the model. It consists of plain text files: pages describing concepts and specific entities (people, tools, projects), comparisons, and analyses, densely linked to one another. The model creates these pages, updates them with every new source, and keeps them consistent. You read them.

A rules file ties the two layers together. It is a document in which you tell the model how to run the wiki: which pages to create, how to name them, and what to do when a source is added. Karpathy calls it the key configuration file, because it is what makes the model behave like a disciplined editor rather than a chatbot answering one-off questions.

The split between sources and wiki answers a question almost everyone asks at the start: why should the model write the synthesis and not the sources themselves? The sources have to stay untouched, because only then can you check whether the synthesis is true. The synthesis, on the other hand, can be rewritten as often as needed, because you can always go back to the material it came from. If the model edited the sources, after a few months there would be nothing left to go back to.

Karpathy compares this setup to a programmer’s work: Obsidian, where you browse the notes, plays the role of the editor, the language model is the programmer, and the wiki is the code that the programmer writes and revises.

Three operations

The first operation is ingesting a source. You add new material, and the model reads it, discusses the key takeaways with you, and works them into the wiki. According to Karpathy, a single source can change 10 to 15 pages, because new information concerns many entities and concepts at once.

The second operation is asking a question. You ask, and the model looks for the answer in the wiki rather than in the raw files and gives it to you along with its sources. Karpathy points out something important here: a good answer should not vanish into the chat history. If it required a comparison or an analysis, it goes into the wiki as a new page, so questions build the system just as sources do.

The third operation is a health check. From time to time you ask the model to review the state of the wiki: contradictions between pages, claims made obsolete by newer sources, pages nothing links to, and concepts that appear in the text but have no page of their own.

Two files help you find your way around the wiki. The index lists every page with a one-sentence description, and the model starts every search there. The log is a chronological record of what happened: every ingested source, every health check. The index tells you what is in the wiki, and the log tells you where that knowledge came from and when it entered the system.

Why it works

Most personal wikis maintained by hand die for the same reason: the upkeep grows faster than the value. Reading an article and thinking it through is a pleasure. Updating links across twenty pages, revising a summary, and noticing that a new figure contradicts an old one is tedious work nobody enjoys. After a few weeks the wiki falls behind, and then nobody trusts it.

The model does not get bored with this work and does not forget a link. In a single pass it can update a dozen or more files. The cost of upkeep drops close to zero, and the human role shifts to where it matters most: choosing sources, asking questions, and judging what it all means.

Karpathy also recalls an idea from 1945. Vannevar Bush described the Memex, a personal device for storing documents connected by trails of association. Bush left one problem unsolved: who would maintain those trails. In Karpathy’s view, the language model now fills that gap.

How it works for me after more than three months

I work in Obsidian, and Claude Code maintains the wiki. At the beginning of October 2026 my knowledge base held 374 source notes and 421 synthesis pages, and the log had 901 entries. The numbers alone say little. What says more is what I had to add to the pattern along the way, because Karpathy deliberately describes only the skeleton.

I keep knowledge about the world separate from records of my own work. Of those 421 pages, 67 describe my business: servers, tools, projects, decisions. The other 354 are general knowledge, such as notes from books I have read. At first everything went into one wiki: the first interview about AI I ingested ended up next to the pages for my servers and projects. Less than three weeks in, I separated the two layers, because one describes facts from my work and the other describes other people’s views and findings, and the model should always know which of them I am asking about.

Alongside the wiki I keep records. Projects, contacts, tools, and documents are not knowledge to synthesize but matters that have a status and change from day to day. They have their own pages written from fixed templates, and the wiki pages link to them.

A statement without a measurement is marked as a hypothesis. The model writes fluently, so a conclusion sounds just as certain as a verified fact. I once carried a statement about a bug into my notes and into a brief for a developer without anyone having measured it, and the measurement then showed a completely different bug. Since then I give every statement about the state of things together with its source, and if I have no source, I say plainly that it is a hypothesis.

A log entry carries a time, not a sequence number. I often work in several conversations with the model at once, and each of them appends to the same log without seeing the others. As a result, sequence numbers started to repeat. The time comes from the clock, so no conversation has to guess how many entries came before it.

Each of these changes went into the rules file. Since July it has grown from 1,329 to 3,836 words, and I have edited it on 15 separate days. Karpathy writes that the rules file evolves together with the system. In my case every mistake that happened twice ends with a new rule.

What the pattern does not solve

The pattern does not give you a ready-made system. Karpathy’s note describes a shape, not an implementation. The structure, the naming, and the rules have to be worked out for your own work, and working them out takes longer than setting up the tools.

The LLM Wiki does not remove the need to check. The model organizes the notes and suggests connections, but it does make mistakes. It can record something it merely inferred as an established fact, or decide that two matters are related when in reality nothing connects them. Responsibility for what the system claims stays with the person, which is why the sources have to stay untouched and the health checks have to be regular.

The system works best with a single owner. Karpathy mentions a wiki for a team, fed by the company’s conversations and documents, with people approving the changes. I describe a system for one person, though. A shared base with several authors requires settling permissions and resolving conflicting entries, and that is a different job.

What comes next in this series

In the next article I will describe building such a system from scratch: where to start, what to bring over from old notes, and when the wiki starts answering questions better than searching through files. If you would rather build a second brain on your own materials together with me, I describe the scope on the second brain service page; I deliver it in Polish. The case study shows how the team workshop runs.

Source: Andrej Karpathy, “LLM Wiki”, April 2026.