Everyone can become a knowledge builder

How to build an LLM wiki with Claude Code, and what changes when it moves from one person to a team.

Philosophers from Aristotle to Heidegger, Putnam and Wittgenstein have argued about what ontology and meaning are since the ancient Greeks, without ever agreeing. Now we deploy these things with language models, and influencers add their own vocabulary to the eternal language battle.

On day two of my executive leadership training with Quadriga, I gave the group an exercise that shouldn't have worked. They got a link to a gist by Andrej Karpathy. They got a link to a Google Drive folder with a real dataset from one of our projects: political voices on X. And they got a task: set up an LLM wiki that helps you analyze this data and produce reports or interactive dashboards. Ninety minutes. The audience was new to agentic ways of working and had exactly one brief introduction to Claude Code behind them.

The exercise setup was brutal, and I knew it.

Some participants went to lunch while their Claude was still running, ingesting sources into their wiki. One got her credit card blocked, not because the costs exploded but because her bank flagged the charge from an AI company she'd never paid before. Billing is still the least polished part of this whole experience. A few ran into token limits. And yet: after ninety minutes, more than half the group had a working LLM wiki, some of them producing detailed, well-structured analysis reports from the data.

I want to be careful with that number. A workshop success is not proof of adoption, and the people in that room won't all keep their wikis alive. But the exercise validated one assumption I had on my mind at the start: it is genuinely accessible for a broad, non-technical audience to use a coding tool like Claude Code to build the context that makes an AI fit for their individual purpose and their individual knowledge. The entry barrier has fallen.

From prompting to knowledge building

A while ago I wrote that with AI, we are all becoming product makers, because prompts are products. I think there's a next shift behind that one. When agents can create and maintain their own knowledge structures, the craft moves from writing a good prompt to designing the knowledge system the agent works in.

Everyone can become a knowledge builder.

Can, not will: it is a possibility, not a necessity. Every wave of new tools, like spreadsheets, web publishing, no-code or vibe coding, produces the same hype: now everyone will use it. In the end, not everyone does. I expect the same to happen here. But those who really use the new approach will have a disproportionately large advantage, because your own knowledge system is able to keep improving itself, continuously and independently of new technology developments. So I think it makes absolute sense to engage with this more deeply.

I asked Claude what to call this role. Knowledge engineer? Knowledge architect? The old label "knowledge engineer" belonged to the expert-systems era of the 1980s, when specialists encoded rules into machines. What's new is that this work no longer needs a specialist. So I'll stay with knowledge builder.

This didn't start with Karpathy — but he gave it a shape

People have been working this way for a while. Teresa Torres runs much of her work, research and writing included, on an Obsidian vault that Claude Code reads and maintains, and has shown the setup in several long walkthroughs (Behind the Craft with Peter Yang, December 2025; How I AI with Claire Vo, January 2026). Nate B. Jones has been making the case since mid-2025 that Claude Code is a general-purpose agent for knowledge work, not a programming tool (June 2025, December 2025). And Eric Bowman, today CTO at King and formerly part of Zalando's technology leadership, put it bluntly on LinkedIn in August 2025: "Using Claude Code as a basic tool for knowledge work is simply the most incredible technological breakthrough I've ever seen."

Then, in April 2026, Andrej Karpathy published a short gist that gave the pattern a name and a structure. The LLM wiki has three layers. A folder of raw sources, articles, PDFs, transcripts, data, that never get edited. A wiki of markdown pages the LLM writes and maintains: entity pages, topic pages, summaries, all connected with [[wikilinks]], held together by an index and a log. And a schema file, the constitution of the whole thing, which tells the agent how the wiki is organized and how to work in it. Three operations run the system: ingest a new source, query the wiki, and lint it, a recurring health check for contradictions, stale claims, and orphaned pages.

The core idea is simple: knowledge compounds. It improves and deepens itself. Instead of an AI re-reading your documents from scratch every time you ask something, it reads them once, writes what it learned into pages, and every new source makes the existing pages better connected and more valuable.

The concepts worth understanding

If you want to build your own knowledge system, it is worth understanding the basic concepts such a system rests on. None of them is really technical, and none of them comes from AI. The first two are the ones people find strange: ontology is a concept from philosophy, semantics comes from linguistics. If these terms are new to you or feel odd, this may be exactly the moment to engage with them: through their technical implementation in language models, they have suddenly become vocabulary you need to understand how such systems work and where their limits are.

Ontology. An ontology is, in Tom Gruber's classic definition, an explicit specification of a conceptualization — in plain words: a deliberate answer to the question "what things exist in my world, and how do they relate?" Why does this matter for your wiki? Because the LLM already has an implicit ontology. Trained on much of human writing, it carries default assumptions about what a "customer", a "project", or an "insight" is. If you don't make your own entities and relationships explicit, you get the model's defaults. I ran a small experiment on this: I structured the same research material three different ways — as atomic research in the style of Tomer Sharon, as a plain research repository, and with my own method. Three different structures, three different sets of entities and relationships, three different systems to think with. Our experience from client projects points the same way: the work that goes into a wiki's structure decides whether a team accepts it internally, and how well it performs when you ask it questions and judge the results.

Semantics. Closely related, and the reason naming is hard work rather than decoration. When you call something a "learning" instead of a "note", you've made a semantic decision the agent will follow from then on. Words in a knowledge system are load-bearing.

Markdown and Obsidian. The tooling question turns out to be almost boring. Plain markdown files win, because both humans and agents read them without any translation layer, they live in ordinary folders, and no vendor sits between you and your knowledge. Obsidian is a comfortable window into those files, but it's optional. The files are the system. One detail matters: each file starts with a few lines of YAML, the frontmatter, that name what the file is, what state it is in and what it belongs to. The schema file, next on this list, defines which of these fields exist and what they mean; the frontmatter is where every page fills them in. That is what turns a folder of notes into something an agent can query, filter and maintain. Karpathy sums up the setup in one line: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

The schema file. In Claude Code this is the CLAUDE.md; the emerging tool-neutral sibling is AGENTS.md. It's the constitution: folder conventions, link format, what the agent may change and what it must never touch. It is where your ontology becomes operational, and the first thing to get right. It is not the whole system, though: how new knowledge gets in and how the wiki is kept in shape is a loop of its own, and I come back to it under evals.

OKF. In June 2026, Google Cloud published the Open Knowledge Format, a vendor-neutral specification for exactly this pattern: knowledge as a directory of markdown files with a few lines of metadata on top. Three things in it are worth knowing:

• Every page names its type: a source, a concept, an analysis. That is where we are back at ontology, because the type says what kind of thing the agent is reading and which evidence belongs to it.
• Two fixed files, a catalogue and a log, make visible which pages exist and what has changed.
• Provenance and a verification status, added in July, let a page say where a claim comes from and whether someone checked it.

The format does not make a claim true. Someone still has to do that. You don't need to read the spec to use the pattern, but its existence matters: what began as Karpathy's weekend project now has a shared specification behind it. OKF is developed in the open on GitHub and keeps moving, and not much has been written about it yet. I think it is a powerful approach. That is my assessment, not a statement about adoption.

Lint. Karpathy's lint operation is a recurring session where the agent checks the wiki for contradictions, outdated claims, and dead ends. In a workshop last week I called this weeding, and I've grown fond of the image: a library needs a librarian, and a wiki needs a gardener. The agent does the planting. Someone still has to walk the beds.

Evals. Lint tells you whether the wiki is tidy. It does not tell you whether the answers are right. That is what evals are for, and there is no standard yet, so let me describe what we do at Bolt.

The starting problem. The User Insights Wiki there holds years of driver research. When we started, the researcher who had done most of it had left the company, and the team asked the obvious question: how do you evaluate driver research without a driver researcher? Our first answer was to reproduce one of her studies. Ingest only the raw interview transcripts, let the wiki generate its insights, then compare them with her original report. My partner Jochen made a prediction in that call: we'd reach 85 percent of her quality. Let's find out.

How the evals work today.

• A set of questions with a hand-written answer key. Every expected point is traced back to a research document, and a rubric says how to grade.
• Two agents, kept apart. One answers and sees only the wiki. The other grades and sees only the question, the answer and the key.
• A few questions are traps with no real answer, and the wiki has to say so. Claiming certainty on an open question scores zero.
• The key rule: the answer key comes from the research and from domain knowledge, never from reading the wiki you are about to grade.

Why it matters. That last rule is why the researcher came back, as a freelancer, to harden exactly this wiki. The agent can plant and weed. Only the people who know the domain can say whether an answer is true, and that judgment, written down as evals, is the core contribution knowledge workers make to a system like this.

And the evals pay back. One question about gaps in the corpus was answered wrong by every run, with product wishes instead of gaps. The model wasn't the problem. The wiki's structure had no place for absence.

Here's how these concepts interlock. The ontology decides what exists, the schema makes it operational, the frontmatter carries it on every page, lint keeps it tidy, and evals tell you whether it is true. There is one research finding worth keeping in mind for all of it: models get measurably worse when you flood them with context. A small, curated slice of the right pages beats dumping everything in. That is why the index and the structure matter more than the size of the wiki.

Build it yourself

Here is where I have a strong opinion, and the learning research backs it up. The generation effect, replicated across 86 studies with a medium effect size, says you retain what you construct and forget what you consume. It's one of the better replicated findings in memory research. The transfer to LLM wikis is my interpretation, not a measured result, but it matches everything I saw in that training room. Ninety smooth minutes of watching an agent build something can feel like understanding. It isn't, yet.

Six weeks after the Quadriga training I ran the pattern a second time at Working Products #11, a two-hour online workshop on 8 September. This time we did the opposite of brutal. Jochen had built a starter kit: 71 Trustpilot reviews of Vinted, 14 transcripts of automated user tests we had run with workshop participants earlier, a schema file with ten fixed concepts, and a prompt that builds the whole wiki. Participants didn't design anything. They picked a lens, buyer trust or whatever their own product question suggested, and let the agent run. In my own run it spawned 39 sub-agents and worked through two million tokens. Most teams had a wiki of several dozen pages before the breakout ended. One team running Codex was still watching 45 agents work after nine minutes, which is its own small lesson about how these tools differ.

Two workshops, same pattern, opposite setups. In July, nobody was handed anything but a gist and a dataset; everybody had to build their wiki from scratch. In September, everybody was handed a starter kit, ready-made prompts and a schema distilled from what we had learned in wiki projects with clients, and the agent did the building. I found myself asking what, exactly, they had learned.

It depended on where the thinking went. The teams that got the most out of it were the ones who argued with the result. One participant pointed out that "what are the five biggest pain points" is a counting question, and a wiki of prose pages doesn't count well. Another team, for the same reason, had the agent derive tables from the wiki and queried those with SQL. And when the polished analysis reports appeared at the end, I asked the room whether 85 thin, inconsistent sources could possibly support them. They couldn't, and that was the lesson. The wiki was given. The judgment wasn't.

So there's a question every executive should sit with for a moment: do you want a memory, or do you want understanding?

I think the answer is not to reject the automation, and not to insist that everyone types their own schema either. It's to move up one level. The shift is not "I build a wiki and sort my knowledge into it." The shift is "I build systems that maintain my knowledge." The thinking work doesn't disappear, it migrates: away from filing individual notes, up to choosing the lens, designing the ontology, the schema, the rituals of maintenance. That is where the generation effect lives now. Let the agent do the filing at 2am. Keep the design decisions.

This is also why I believe a knowledge system that someone else sets up for you and hands over as finished is bad AI UX. A pre-built wiki, delivered as an artifact, produces exactly the passive relationship the research warns about: you trust it, you stop checking it, you slowly stop thinking alongside it. I'll admit the starter kit sits close to that line. What kept it on the right side, I think, is that the schema was offered as something to argue with, not something to accept, and the data was thin enough that the arguing was easy to start. In our work at PoDojo we've made this a principle: we help organizations build these systems themselves, because the self-efficacy is not a side effect of the build, it is the point of it. The system you want is not one that thinks for you. It's a critical partner that keeps you thinking.

From the individual to the team to the organization

Where is this heading? The individual level, I'd argue, is solved in its outline: accessible, cheap enough, and standardizing. The interesting friction starts at the team level.

Plain markdown pushed to a git repository, where an agent picks it up and works it into a wiki, is unglamorous and works. We run part of our own company knowledge exactly that way. But I don't want to oversell this. The team story has open problems.

A second learning came out of the Working Products session, and it is about the surface. One participant took the finished wiki home, ran it through Cursor for an onboarding case of his own, and came back with a verdict I've heard from clients too: the report is nice, but what a team actually wants is something to ask questions of, a Q&A tool or a Slack bot sitting on top of the pages.

Underneath that verdict sits a harder problem, and it showed in the workshop itself. If you were not part of the research team and have no first-hand experience of Vinted and its trust issues, it is very hard to tell from the wiki whether the results are right and whether you can trust them. That is the real design task for the interface: the natural-language experience has to present sources and results in a way that lets empathy and judgment arise. Not just an answer, but the path back to the person who said it.

At Bolt we learned the same thing from the other side. Three things stuck:

• Slack is a social surface. The wiki answers researchers and product managers inside Slack, and the answers are visible to others. That visibility drives adoption more than any feature does: if a team sees a colleague query the wiki every day, they start too. A private chat interface would have lost that.
• Every answer carries its evidence chain. A question in Slack produces a report that links back to the facts and the transcripts it was built from, so a product manager can check the claim rather than take it on faith.
• Snippets beat transcripts, and video beats text. Nobody reads transcripts and nobody watches full recordings. What people want are snippets. And one researcher put the limit of text precisely: a quote without emotion doesn't carry the pain. A driver saying that the app feels fake is banal on a page and hits you on video.

The wiki is the substrate. The interface is a separate design decision, and it is where the team version starts to differ from the personal one.

First, the base rates are against sustained practice: personal knowledge management has always had a graveyard problem, and most systems get abandoned once the novelty wears off. An agent that carries the maintenance changes the odds — that's the structural difference to every earlier PKM wave — but human curation doesn't drop to zero, and nobody has long-term data yet. Second, if you feed company information into a personal setup, you've built shadow IT, and every CISO reading this just nodded; team versions of this need proper enterprise accounts and a real decision about what data goes in. And third, the point where I have a direction but no proof yet: fifty personal wikis are fifty silos, but the moment you centralize into one team wiki, most people stop working on the structures, and the self-built understanding that makes the individual version powerful starts to thin out. The pattern I find most promising comes from data engineering, and Jochen brought it into our Bolt work: data mesh. Instead of one central wiki, each domain team owns its own, because raw signals cannot be interpreted correctly without domain context, and the domain experts are the ones who have it. The wikis are then connected rather than merged. This is also where OKF earns its place. A minimal shared standard makes wikis interoperable: a skill that works on one wiki works on the next, and a question can travel across them without anyone rebuilding the structure.

The design principle behind it is the same one as at the individual level, applied at team scale: build the system so that thinking is not outsourced but provoked. A wiki that asks its owners questions, surfaces contradictions in its lint runs, and keeps the people around it in the role of builders rather than consumers. One knowledge builder per domain, with the agent as the connective tissue. We're experimenting with this in our own two-person company and with clients, and I'd rather report findings than visions.

The role that emerged from Working Products has a name, and it is older than the tools. Ward Cunningham's original wiki in the 1990s already had a WikiGardener, someone who walks the pages, mends links and pulls out what no longer belongs. Mike Caulfield described the garden as the counter-model to the stream in 2015, a place where thoughts are tended and grow over time rather than scroll past. And Niklas Luhmann tended his Zettelkasten, tens of thousands of cards, by hand for decades. All of them solved the linking, but upkeep stayed manual work. What is new is that the agent now does the planting and much of the weeding, and the gardener's job moves up a level: deciding what belongs in the garden, what the beds are, and whether what grows there is true.

If you're experimenting with your own LLM wiki, or wrestling with the team version of this, drop me a line. We're collecting what works.