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

For most of my working life, knowledge lived in the wrong places. It sat in my head, in half-finished documents, in chat histories I would never read again, and in the gap between what I knew and what anyone else could find. Every new task started with the same quiet tax: re-explaining context that already existed somewhere, just not anywhere useful.

An LLM-native wiki removed that tax. It is the closest thing I have to an operating system for my own work, and it is built on a simple idea: if you keep your knowledge in a form a language model can read, you stop being the only person who can run your business.

This is how I built mine, what it does for workflow, time analysis and project management, and why I think it is one of the most useful systems a small team or agency can adopt this year.

What an LLM-native wiki actually is

An LLM-native wiki is a structured, plain-text knowledge base designed to be read by a language model as working context, not just by a human as reference. It is the same instinct behind any good internal wiki, write things down so they are not trapped in one person’s memory, but optimised for a different reader.

The approach is often called a Karpathy-style wiki, after the AI researcher who described keeping an LLM-friendly knowledge base rather than relying on a model’s memory or a scatter of chat threads. The principle underneath it is what matters: a model is only ever as good as the context it is given, so the highest-leverage thing you can do is curate that context deliberately.

In practice this means three things. Your knowledge lives in plain text, so it is portable and durable. It is version-controlled, so you can see how it changes over time. And it is layered, so the model is given the right amount of detail rather than everything at once.

That last point is the whole game. Most knowledge systems fail because they are either too thin to be useful or too dense to be read. An LLM-native wiki solves this with a distillation pipeline.

The three layers: raw, distilled, hot context

I structure the wiki in three layers, and each one earns its place.

The first is the raw layer. This is where everything lands, unfiltered: captured thinking, decisions, observations, transcripts, working notes. There is no pressure to make it tidy. The only rule is that it gets captured, because the most expensive knowledge is the kind you had and lost.

The second is the distilled layer, the wiki proper. Raw material is periodically refined into clean, durable entries: the version you would want someone to read in six months. This is where messy capture becomes structured understanding. A note about how I solved a problem becomes a reusable method. A scatter of related observations becomes a single, coherent page.

The third is the hot-context layer. This is a small, carefully maintained file that holds the essentials a model needs on every single task: the canonical facts, the standing instructions, 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 has been promoted there on purpose.

The flow runs in one direction: raw, then distilled, then hot context. Capture widely, refine deliberately, promote sparingly. That discipline is what keeps the system from collapsing under its own weight.

The PKM layer I added on top

The wiki gives you the structure. A personal knowledge management layer gives you the habit, and without the habit the structure is just empty folders.

This is the part I think people underrate. The Karpathy-style wiki is the architecture; the PKM practice is what makes it live. I built mine around four repeated motions:

Capture without friction, so nothing worth keeping is lost to the moment.
Distil on a rhythm, turning raw material into entries while it is still fresh enough to be accurate.
Link related ideas, so the value of the system compounds as connections form between pages.
Retrieve through the model, asking it questions against my own knowledge base rather than searching my memory.

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 canonical, and the rest of the system has something reliable to draw on.

How I set it up

You do not need anything exotic to build this. I have kept the description tool-agnostic on purpose, because the system matters more than any particular product, and most of the components have several good options.

Choose a plain-text, version-controlled home. The wiki should live in plain text, Markdown is ideal, inside a version-controlled repository. Plain text keeps it portable and future-proof. Version control gives you a full history of how your understanding has changed, which turns out to be quietly valuable on its own.
Build the three layers. Create a space for raw capture, a space for distilled entries, and a single canonical context file at the top. Do not over-engineer the folder structure. The layers matter; the taxonomy can grow as you learn what you actually store.
Appoint an agent as the wiki’s keeper. This is the step that makes it LLM-native rather than just a tidy set of notes. Use a capable coding or writing agent as the maintainer of the wiki: it reads the hot-context file at the start of every session, helps distil raw material into entries, and keeps the structure consistent. The agent does the maintenance you would otherwise skip.
Write the distillation rules. Decide, in writing, what belongs in each layer and when material gets promoted. These rules sit in the wiki itself, so the agent applies them consistently and you are not re-deciding the same thing every week.
Start small and let it compound. Seed the hot-context file with the handful of facts and instructions you repeat most often. Add to it only when something proves it deserves to be there. A system that grows from real use stays useful; one that starts fully built rarely survives contact with reality.

The benefits, plainly

The first benefit is that I stop repeating myself. Context that used to live only in my head is written once and read many times. Every task starts further along.

The second is consistency. Because the model works from the same canonical context each time, the output is steadier and more predictable. The system has a memory even when I do not.

The third is durability. Knowledge captured in plain text and version control does not rot the way chat histories and scattered documents do. It is still there, still readable, still mine, long after the conversation that produced it has gone.

The fourth is leverage that compounds. Each entry makes the next task slightly easier. After a few months the wiki is not a cost centre you maintain out of duty; it is the most productive asset in the operation.

What this means for SMEs and agencies

This is where the system stops being a personal indulgence and starts being a commercial advantage. Small teams and agencies feel the cost of scattered knowledge more sharply than anyone, because they have the least slack to absorb it. An LLM-native wiki addresses three problems that quietly drain small organisations.

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 build a quiet record of how work really unfolds: how long things took, where the friction sat, which tasks ran long and why. Over time that becomes a dataset about your own operation. You can look back honestly rather than from memory, sharpen your estimates, and see patterns you would never notice task to task. Most small teams have no idea where their time goes; this gives you a way to find out without imposing a heavyweight 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, all in one canonical place. The immediate payoff is that onboarding and handover stop being expensive. Anyone, or any agent, can pick up the thread by reading the relevant context rather than booking time with whoever holds it in their head. For an agency juggling several streams of work at once, that reduction in context-switching cost is significant. The knowledge does not leave when a person is unavailable, and it does not have to be rebuilt every time attention moves on and comes back.

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; resist it. Get into the habit of putting raw material somewhere consistent, and let the structure emerge from what you actually accumulate.

Keep the hot-context file ruthless. Its value is in its restraint. The moment it becomes a dumping ground, the model loses the signal in the noise and the whole advantage erodes. Promote things into it slowly, and remove things that have stopped earning their place.

Distil on a rhythm. Raw capture decays; the longer you leave it, the harder it is to refine accurately. A regular, modest pass through new material keeps the distilled layer trustworthy.

And let the agent do the maintenance. The reason most knowledge bases die is that upkeep falls entirely on a person who is busy. Handing the routine maintenance to an agent is what makes the system sustainable rather than aspirational.

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 the cost of scattered, person-bound knowledge is one of the quietest and most expensive problems a small operation carries, and because the tools to solve 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, captured once, refined deliberately, and read by a model on every task. For an SME or an agency, that is not a marginal improvement. It is the difference between a business that depends on whoever is in the room and one that has a brain of its own.

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. Explore the frameworks behind the work.