Building an LLM-native wiki

My whole operation runs out of a folder of plain text files. Projects, clients, decisions, half-formed ideas: all of it in Markdown, all of it in version control, all of it read by an AI agent that treats one small file at the root of the folder as its standing orders.

I set the system up in April. In June, the laptop it lived on died. It would not power on, and nothing was ever recovered from the machine itself. I lost no work. The repository was cloned onto a new machine, the agent read its constitution file, and we carried on that same week. I had planned to write about this system anyway, but that is the moment it earned the article.

What follows is the build: what an LLM-native wiki actually is, the three layers mine uses, the knowledge management habit that keeps it alive, and what it changes for a small team running lean.

Watch the walkthrough

I recorded a tour of the vault itself: the folder structure, the graph of links between pages, and the agent working inside it. If you prefer to see the thing rather than read about it, start here, or watch it on YouTube.

What an LLM-native wiki actually is

An LLM-native wiki is a structured, plain-text knowledge base built to be read by a language model as working context, not only by a human as reference. The idea is usually credited to Andrej Karpathy, who described keeping an LLM-friendly knowledge base instead of trusting a model’s memory or a sprawl of chat threads. The name matters less than the principle underneath it: a model is only as good as the context you hand it, so curating that context is the highest-leverage work you can do.

Mine is an Obsidian vault. Underneath, that just means ordinary Markdown files in a git repository, with Obsidian’s graph view laid on top so I can see how pages link together. Nothing depends on Obsidian, and that is deliberate. If the app vanished tomorrow, every file would still open in anything that reads text. Plain text keeps the knowledge portable. Git remembers every change I have ever made to my own understanding, which turns out to be quietly useful in arguments with myself. The folder structure does the rest.

The three layers: raw, distilled, hot context

Everything lands first in a raw layer. In my vault that is a folder called /raw, split into session summaries, meeting notes, key emails and quickly captured ideas. Nothing in it is tidy, and nothing in it gets edited after the fact. The agent reads from it but is forbidden from writing to it. The only rule is that things get captured at all, because the most expensive knowledge is the kind you had and lost.

The distilled layer is the wiki proper: one page per project, one per client, one per tool, one per decision, one per person. When raw material comes in, the agent extracts what matters and folds it into those pages rather than duplicating anything. A messy note about how I solved a problem becomes a reusable method. Two sources that disagree become a dated decision page that records the conflict instead of silently overwriting it.

At the top sits one small file. Mine is called CLAUDE.md, the agent is instructed to read it before doing anything else, and it functions as a constitution: the canonical facts of the business, the standing rules, the things that should never need re-explaining. It is the most valuable file in the system precisely because it is the most restrained. Everything in it was promoted there on purpose, and things get demoted when they stop earning the space.

The flow runs one way. Capture widely into raw, refine deliberately into the wiki, promote sparingly into hot context. That discipline is what stops the system collapsing under its own weight.

The PKM layer I added on top

The wiki gives you the structure. A personal knowledge management habit gives it a pulse, and without the habit the structure is just empty folders. I think this is the part people underrate. Mine comes down to four repeated motions:

Capture without friction, so nothing worth keeping is lost to the moment.
Distil on a rhythm. Raw material gets turned into wiki entries while it is still fresh enough to be accurate, and in my case the agent proposes the distillation and I review it.
Link related ideas, so value compounds as connections form between pages.
Retrieve through the model. When I need to know what was agreed with a client in May, I ask, and the answer comes back from the wiki with a citation to the page it came from. Not from my memory, and not from a forty-minute trawl through old threads.

The mental model I use is deliberately plain. The wiki is the brain, the canonical store of what is true and what has been decided. Everything else hangs off it: the tools that act are the hands, the inputs that feed it are the eyes, the channels that publish from it are the mouths. Keep the brain clean and the rest of the system has something reliable to draw on.

How I set it up

None of this needs exotic tooling. The specific products matter far less than the shape, and every component has several good alternatives. The build order that worked for me:

Choose a plain-text, version-controlled home. Markdown files in a git repository. Portable, durable, and with a full history of how your understanding has changed.
Build the three layers before any taxonomy. A place for raw capture, a place for distilled pages, one canonical context file at the top. My folder tree grew from use; the elaborate structure I would have designed on day one would have been wrong.
Appoint an agent as the wiki’s keeper, and give it written rules. This is the step that makes the thing LLM-native rather than a tidy set of notes. My constitution file includes rules like: never modify raw inputs, never delete a file without approval (log it to a deletion ledger instead), never invent facts not present in a source, and flag contradictions rather than silently resolving them. The agent does the maintenance a busy human would skip, inside guardrails a busy human wrote down once.
Put the operating rules in the wiki itself. What belongs in each layer, when material gets promoted, what a good page looks like. The agent applies them consistently, and I am not re-deciding the same question every week. I also bookend every working session with a sync script, so the repository and its backups never drift.
Start small and let it compound. Seed the hot-context file with the handful of facts you repeat most often. I also run a rule of two: any method I have used successfully twice gets codified into the wiki as a reusable skill, no exceptions. A system that grows from real use stays useful. One that starts fully built rarely survives contact with reality.

The benefits, plainly

The obvious one is that I stopped repeating myself. Context that used to live in my head is written once and read on every task, so every piece of work starts further along, and the output is steadier because the model is drawing on the same canonical context each time.

The one I did not fully appreciate until June is durability. A dead laptop cost me a morning of setup, not months of accumulated knowledge, because plain text in version control does not rot and does not live in one machine. Chat histories and scattered documents would not have survived that week. The wiki did not notice it.

And the quiet one is compounding. Every distilled page makes the next task slightly easier, and every codified method is one I never have to reinvent. A few months in, the wiki stopped being a cost I maintained out of duty and became the most productive asset in the operation.

What this means for SMEs and agencies

This is where the system stops being a personal preference and starts being a commercial one. Small teams feel the cost of scattered knowledge more sharply than anyone, because they have the least slack to absorb it. Three problems in particular get materially better.

Workflow management

The hardest part of running lean is that too much depends on one or two people knowing how things are done. A canonical, model-readable wiki externalises that. The standing instructions, the house style, the way you approach a given type of work: all of it lives in context the model reads on every task. New work picks up the established way of doing things without anyone stopping to explain it, and the people in the team spend their time on judgement rather than repetition.

Time analysis

The raw layer is, almost by accident, a log of where effort actually goes. Because capture is timestamped and version-controlled, you accumulate an honest record of how work really unfolded: how long things took, where the friction sat, which tasks ran long and why. My vault writes a session log for every working day, and looking back through a month of them tells me more about my own estimates than memory ever has. Most small teams have no idea where their time goes. This gives you a way to find out without imposing a tracking process on anyone.

Project management

For any discrete piece of work, the wiki becomes the single source of truth: the context, the decisions, the current state, in one canonical place. The immediate payoff is that onboarding and handover stop being expensive. Anyone, or any agent, can pick up a thread by reading the relevant pages rather than booking time with whoever holds it in their head. For an agency juggling several streams of work, that reduction in context-switching cost is significant, and the knowledge does not leave when a person is unavailable.

What I would tell a small team starting out

Start with capture, not structure. The instinct is to design an elaborate system before writing anything down. Resist it. Put raw material somewhere consistent and let the structure emerge from what actually accumulates.

Keep the hot-context file ruthless. Its value is its restraint, and the moment it becomes a dumping ground the model loses the signal in the noise. Promote slowly. Demote without sentiment.

Distil on a rhythm, because raw capture decays. The longer it sits, the harder it is to refine accurately. A modest, regular pass through new material keeps the distilled layer trustworthy.

And hand the maintenance to an agent, with written rules. Most knowledge bases die because upkeep falls entirely on a person who is busy. Mine survives because the upkeep does not depend on me having a free afternoon.

Frequently asked questions

What is an LLM-native wiki? It is a structured, plain-text knowledge base designed to be read by a language model as working context. Knowledge is captured in raw form, distilled into clean entries, and the essentials are promoted into a small canonical file the model reads on every task.

How is it different from a normal internal wiki? A normal wiki is written for people to reference. An LLM-native wiki is also written for a model to consume as context, which means it is layered by how much detail is needed, kept in plain text, and version-controlled so its history is legible.

Do I need to be technical to set one up? You need a plain-text editor, a version-controlled home for your files, and a capable agent to help maintain it. The underlying habit (capture, distil, link, retrieve) is not technical at all. The discipline matters more than the tooling.

How long before it pays off? The benefit compounds. You feel small gains within weeks as context stops being re-explained, and the larger advantage arrives over a few months as the distilled layer grows and the system starts doing real work for you.

The system behind the work

I did not build this as a productivity experiment. I built it because person-bound knowledge is one of the quietest and most expensive problems a small operation carries, and because the tools to fix it properly only became practical recently. The result is a single source of truth that runs my workflow, records where my time goes, and holds the context for everything I am working on. It survived the death of the machine it lived on. Most businesses could not say that about what is in their founder’s head.

This is the system I run at Laurelin Labs, and it is the foundation everything else is built on.

By Piers Butler, founder of Laurelin Labs. Watch the vault walkthrough on YouTube or explore the frameworks behind the work.

Building an LLM-native wiki: the system I use to run workflow, time and projects