Write it down
In short: Most retrieval setups are stateless: every question starts from zero, finds the same fragments and throws the synthesis away. Karpathy's LLM wiki pattern fixes that by having the model maintain a durable artifact — plain markdown in a git repo, with a schema file that defines the rules and a lint pass that hunts contradictions. The reason it works is economic rather than technical: wikis die because humans will not maintain them, and a model does not get bored. Your knowledge is the asset. The model is a commodity.
The question we get asked most often is some version of "which model should we use to make this smarter?"
It is almost always the wrong question, and there is a cheap way to prove it. Take the thing your AI keeps getting wrong, and ask whether the knowledge it needed was ever actually written down anywhere. In our experience it usually was not. It lived in someone's head, in a Slack thread from March, or in a PDF that three people have opened.
No model fixes that. Which is why the highest-return work is nearly always upstream of the model.
The flaw in how most companies wire this up
The default setup is retrieval: point the model at your documents, let it find the relevant passages, generate an answer. It works, and it has a property most people never notice.
It is stateless. As Andrej Karpathy put it when describing the problem, each query forces the model to "rediscover knowledge from scratch." There is "no accumulation" — the system has to "find and piece together the relevant fragments every time."
Sit with what that means economically. The thousandth question about your pricing rules costs exactly as much reasoning as the first. Every hard-won synthesis is generated, used once, and thrown away. You are paying repeatedly for the same thinking and keeping none of it.
What to build instead
In April 2026 Karpathy published a pattern for the alternative — a plain-prose file describing how to have a model build and maintain a wiki for you. It picked up thousands of forks within weeks, which tells you how badly the gap was felt.
The structure is three layers, and it is deliberately unremarkable:
Raw sources. Immutable. The documents, articles and exports as they came in. Never edited.
The wiki. Markdown pages the model writes, organised by concept, entity and synthesis. This is the layer that grows.
The schema. A single configuration file — CLAUDE.md or AGENTS.md —
holding the conventions: how pages are structured, how a new source gets
ingested, how answers get formatted. Karpathy's description of its job is the
sentence worth stealing: it "is what makes the LLM a disciplined wiki maintainer
rather than a generic chatbot."
Three operations run against it. Ingest: drop in a source, the model reads it, writes summaries, updates cross-references across the pages it touches, and appends to a log. Query: search the wiki, answer with citations, and file genuinely new insight back as a page. Lint: periodically sweep for contradictions, orphans, stale claims and gaps.
The reason it actually works is not technical
Companies have tried internal wikis for thirty years. They rot. Not because the idea is wrong but because maintaining one is unrewarding work that nobody's review depends on, so it stops happening about six weeks in.
Karpathy's observation is that this specific obstacle has just been removed: "LLMs don't get bored, don't forget to update a cross-reference."
That is the whole unlock. The pattern does not make the model smarter. It moves the maintenance burden — the cross-referencing, the summarising, the tidying, the part humans reliably abandon — onto something that does not mind. What is left for people is the part that was always the valuable bit: curate the sources, direct the analysis, ask good questions.
Why plain markdown beats a product
There will be a vendor along shortly offering this as a platform. Before you buy it, note what the plain-text version gives you.
Karpathy's framing: "the wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free."
That sentence carries more than convenience. Version history means you can see when a claim changed and why. Branching means you can propose a restructure without breaking what works. Plain text means every model, current and future, can read it without an integration — and it means the knowledge is yours, not held inside someone's product on a subscription. For a company whose competitive advantage is what it knows, that last point is not a detail.
It is also why the file that configures your agent deserves more care than it
usually gets. Most teams write four lines in CLAUDE.md and never return. It is
the highest-leverage document in the repository.
The operation nobody runs
Of the three, lint is the one that gets skipped, and it is the one that decides whether the thing stays trustworthy.
A wiki maintained by a model accumulates errors as readily as insight. A source gets superseded. Two pages end up disagreeing. A page is written and never linked from anywhere. None of that announces itself — it just quietly degrades the answers, and because the answers still sound confident, nobody notices for months.
This is the same hole we keep arriving at from different directions. In the Firefox result, the thing that made an agentic pipeline work was a referee that could not be argued with. In multi-agent systems, the named failure is a verification agent that rubber-stamps after minimal checking. Here it is a lint pass that never runs.
Where we would start in a real company
Pick one domain that people repeatedly ask about. Pricing rules. How a particular client likes things delivered. Why a decision was made the way it was. Narrow beats comprehensive, because you find out within two weeks whether it works.
Write the schema file first. Before any content. What is a page, what goes in it, how is a source recorded, what does a good answer look like. This is the document that decides whether you get a maintainer or a chatbot.
Keep raw sources immutable. The value of the wiki depends on being able to trace a claim back to where it came from.
Put it in git. Not because everyone will use git, but because you want the history and you do not want the knowledge living in a vendor.
Schedule the lint. Monthly, with a person reading the output. An unaudited knowledge base becomes a confident liar.
The honest summary
Everyone in your market can rent the same models you can, at the same price, this afternoon. The model is a commodity and it is getting cheaper. What nobody else can rent is a well-maintained, structured, current account of how your company actually works.
That is the asset. It has always been the asset. What changed in 2026 is that the tedious part of building it — the cross-referencing, the summarising, the endless tidying that killed every wiki you have ever seen — can now be handed to something that does not get bored.
The cheapest way to make your AI smarter is to write things down. It was also the cheapest way to make your company smarter, long before any of this.
Frequently asked questions
How do you make an AI system smarter without changing the model?
Give it a better body of written context and a defined structure for using it. Most business questions fail not because the model cannot reason but because the reasoning it needs was never recorded anywhere — it lives in people's heads, in chat threads and in PDFs nobody has read since. Writing that down in a form the model can navigate produces a bigger jump than any model upgrade available to you.
What is the LLM wiki pattern?
A pattern published by Andrej Karpathy in April 2026. Instead of asking a model to answer from documents each time, you have it maintain a wiki: a folder of markdown pages it writes and cross-references itself. Raw sources stay immutable, the wiki holds the model's synthesis, and a schema file defines the conventions. Its point is accumulation — each ingested source makes the next answer better rather than starting from zero.
Why markdown rather than a database or a dedicated tool?
Because a folder of markdown in a git repository gives you version history, branching and collaboration without building anything, and stays readable by both people and models. It also means no vendor holds your knowledge. Karpathy's own framing is that the wiki is just a git repo of markdown files, and you get the rest for free.
Is this the same as RAG?
No, and the difference is the point. A retrieval system is stateless — it finds fragments and reassembles an answer, then discards the synthesis, so the thousandth question costs as much thinking as the first. A wiki keeps the synthesis as a durable page that later answers build on. Retrieval finds; a wiki accumulates.
What still has to be done by a person?
Choosing what goes in, directing what gets analysed, and asking good questions. The pattern moves the maintenance burden — the cross-referencing, the summarising, the tidying — onto the model, because that is the part humans reliably abandon. Judgement about what matters stays with you.
About the author
Filip has spent his career between media and technology — filming for ŠKODA, Pilsner Urquell and Range Rover, then co-founding a startup in San Francisco, working with a YC-backed company and serving as CIO at Renato. He built ZEUS Legal AI and now runs the systems Salamon Capital operates on.