The LLM Wiki in production: four months on Karpathy's pattern, and the rules that keep it working

An LLM Wiki is a knowledge base that an AI writes and maintains for you. You bring the sources and the questions. The model does the filing, the cross-referencing, the summaries and the cleanup. Andrej Karpathy described the pattern in a short gist, and the idea spread fast because it fixes the thing everyone hates about “chat with your docs”: every answer starts from zero.

We have been running Bamboo Tech Studio on one since the spring. It is an Obsidian vault that Claude Code and a handful of other agents maintain alongside two humans. It holds our clients, projects, servers, proposals, decisions and the rules our agents follow. As of today it has more than 660 commits since we put it under git on June 13, 2026, 29 reusable skills, 14 recorded decisions and an agent memory of 81 notes, many of them lessons the agents wrote down for themselves.

Most of what ranks for “LLM Wiki” right now explains the idea or shows a weekend setup. This is the other half: what happens when you actually run a business on it.

The pattern in one paragraph

Karpathy’s version has three moving parts. A folder of raw sources that nobody edits after capture. A wiki of Markdown pages that the model writes and keeps linked. And a schema, a plain document that tells the agent how pages are shaped and which operations exist: ingest a source, query the wiki, lint it for broken links and contradictions. Our copy of the reference schema puts the difference with RAG in one line: “the wiki is a persistent artifact.” Synthesis happens once and stays.

How we adapted it

We did not use the literal layout. Our vault already had a taxonomy for running a company, so we merged the wiki machinery into it on day one of git:

• Semantic folders instead of a wiki/ folder. People and companies live in ENTITIES, client work in PROJECTS, servers and accounts in INFRASTRUCTURE, synthesis in KNOWLEDGE, cross-project choices in DECISIONS. A note lives where its meaning says, so an agent can predict where to look.
• One card per folder, named after the folder. PROJECTS/Some-Client/Some-Client.md. Wikilinks resolve by name, and the graph shows real names instead of dozens of files called project-card.md.
• .raw/ stays immutable. Transcripts, screenshots and exports go in once and never change. Everything the agent writes about them lives elsewhere and links back.
• Two frontmatter schemas side by side. Operational cards (client, server, project) have one shape; synthesis pages (concept, comparison, decision) have another, with a maturity status.
• A schema file per agent family. CLAUDE.md for Claude Code, a shorter vendor-neutral AGENTS.md for Codex and others, and a STANDARDS/ folder that wins whenever they disagree.

What actually carries the value

Karpathy’s gist puts the spotlight on synthesis pages: concepts, comparisons, filed questions. In a wiki that runs a company, most of the value comes from the operational layer:

1. A task register that is the only front door. Every task gets a row and a link to the note that documents it, in the same edit. Closing one needs a line saying what happened, including “closed without doing it, because X”.
2. Skills, not prompts. Recurring work (publishing a site, provisioning a server, cleaning up a hacked WordPress) is a SKILL.md the agent loads and follows. The 29 skills are the closest thing we have to an operations manual, and they get better each time someone corrects them.
3. Decisions with dates and reasons. When a choice is revisited, the agent finds the earlier reasoning instead of re-litigating it.
4. Agent memory as files. (More on how this fits with the other kinds of memory in agent memory in practice.) When an agent learns something worth remembering, it writes a short lesson with the reason and how to apply it. Examples from ours: agents do not know today’s date; an empty result can mean “dropped”, not “absent”; a provider’s “received” is not acceptance.
5. A linter that fails loudly. A 391-line, dependency-free script checks dead and ambiguous links, unregistered tasks, duplicate rows, oversized files and about a dozen secret patterns. It is the wiki’s immune system.

Five failure modes of a shared LLM wiki, and the rule for each

1. One shared cache gets overwritten. The reference schema suggests a single “hot cache” file with recent context. With several people and agent sessions, each session rewrites it wholesale and the previous context is gone. The rule: every operator gets their own hot cache and log; everyone reads all of them, and each writes only their own. When a cache grows past about a thousand words with several live threads, split it into a short index plus one file per thread.

2. Row numbers collide. When several sessions and people add rows to the same register, numbers get reused, and an edit keyed on a row number can land on someone else’s row. The rule: edit rows by unique text, never by number, pull before adding, and take the next free number at write time.

3. Failures get filed as normal states. Something fails and gets recorded as if it had worked. A monitor that only alerts on findings looks identical to a monitor that died. Our standard for this has twelve rules, among them “the default state is never the optimistic one”, “confirm only after the effect lands” and “a rule that lives only in the prompt is not a rule”.

4. Shared folders carry more than you meant to share. Part of our vault is a git subtree we exchange with an external partner, in both directions. The rule: a guard enforces the boundary, so it never depends on someone remembering. A pre-commit hook rejects anything owned by entities that must not leave, decided by ownership fields rather than by folder or note type. Guards like this grow in layers: each time a check proves too narrow, add one.

5. Remote agents get the same door as local ones. The rule: agents running on servers get a smaller door. Ours have no write access to the vault. They read a mirror and can only add files to their own proposals folder, enforced on the server by a hook and tied to their SSH key. A human merges what is worth keeping.

Is it a second brain?

Partly. The “Obsidian second brain” crowd (Google Ads data shows searches for it up more than eightfold in a year) is mostly building a personal one. Ours is shared, and the difference matters. A personal second brain can tolerate drift because one person knows what they meant. A shared one needs the rules above, otherwise each new session and each new person adds noise faster than the agent can clean it.

What a company wiki gives you that a personal one does not: continuity across people and sessions. Any of our agents can pick up a client thread, see the last decision, the open tasks, the server it runs on and the lessons recorded on similar work, without anyone briefing it.

How to start one this week

1. Create the folder and put it under git on day one. History is the cheapest audit trail you will ever get. Ours has more than 660 commits, and it is how we find out who changed what, and why.
2. Write the schema before the first note. Folder map, frontmatter per note type, and the three operations. Keep it short enough that the agent actually reads it.
3. Make the task register the front door from the start. It is much harder to retrofit.
4. Give every operator their own working files. Shared read, private write.
5. Add a linter in the first week, even a crude one. Dead links and unregistered tasks are the first symptoms of drift.
6. Let the agent write its own lessons. A memory folder where each mistake becomes a one-paragraph rule with a reason is worth more than any prompt you will write.

What to put in place from day one

Split the hot cache per person from the start. Write the “failures are not normal states” rule before you need it. Put your first hours into the operational layer (register, skills, decisions, linter) and less into synthesis pages nobody reads yet. The wiki that lasts is the one that runs the work.

If you want to see how this applies to a real operation, or need help setting one up for your team, talk to us. This is the same system we use to build and run the AI agents and automations we deliver to clients, including the WhatsApp agents we wrote about here.