Karpathy's LLM Wiki (2026): What It Is, How to Build One, and How It Scales to a Company

TL;DR

An LLM wiki is a folder of Markdown pages that a language model writes and maintains for you from the sources you give it. Andrej Karpathy described the pattern in an idea file published as a GitHub gist on 4 April 2026. The model reads each source once and folds it into linked summary, entity and concept pages, so in Karpathy's words "the wiki is a persistent, compounding artifact." That beats re-retrieving raw documents, because the synthesis is done once and improved rather than rebuilt from chunks on every query. It works well for one person and a few hundred pages. Sentra, the managed organization memory for teams and AI agents, is the same idea run for a whole company: it reads Slack, email, meetings, docs and project tools continuously, keeps each fact with its source and the newest version on top, and follows each source tool's permissions.

What is an LLM wiki?

Karpathy's gist is deliberately abstract, meant to be pasted into an agent such as Claude Code or OpenAI Codex, which builds the specifics with you. Its starting point is that most document chat works like retrieval-augmented generation (RAG): retrieve chunks at question time and generate an answer. Nothing accumulates between questions.

An LLM wiki changes where the work happens. When a source arrives, the model summarizes it, updates the pages for the people, projects and concepts it mentions, and notes where it contradicts what the wiki already says. The human chooses sources and asks questions. The gist's reasoning is that people abandon wikis because maintenance grows faster than value, and a model can do that maintenance at almost no cost.

The three layers

• Raw sources. Articles, papers, transcripts, images and data files. They are immutable: the model reads them but never edits them, so they stay the ground truth you can always check.
• The wiki. Markdown pages the model generates and owns: source summaries, entity pages, concept pages, comparisons and an overview. You read it; the model writes it.
• The schema. A configuration file such as CLAUDE.md for Claude Code or AGENTS.md for Codex that tells the model how the wiki is organized, what conventions to follow and what to do on each operation. You and the model refine it as you learn what works.

The three operations

• Ingest. You add a source. The model discusses it with you, writes a summary page, revises related pages, updates the index and appends a log entry. One source can touch 10 to 15 pages, and Karpathy ingests one at a time so he can steer.
• Query. The model reads the index, opens the relevant pages and answers with citations. A good answer, such as a comparison, is filed back as a new page, so your explorations compound too.
• Lint. Periodically the model health-checks the wiki for contradictions between pages, claims that newer sources have made stale, orphan pages with no inbound links, concepts mentioned but missing their own page, missing cross-references and gaps worth a new source.

index.md and log.md

index.md catalogs every page with a link and a one-line summary; the model reads it first when answering and updates it on every ingest. log.md is an append-only, dated record of ingests, queries and lint passes, with a consistent prefix per entry so command-line tools can read it. The gist says the index alone works at about 100 sources and hundreds of pages.

The usual tool stack

The wiki is a directory of Markdown files, so the tooling is ordinary. Karpathy uses Obsidian to read it, with its graph view and Web Clipper, while Claude Code or Codex does the writing and git keeps the history. Optional extras include qmd, a local Markdown search engine, once the index gets too long.

LLM wiki vs RAG

RAG and an LLM wiki both ground a model in your documents. The difference is when the understanding happens. RAG does it at query time, every time, from chunks chosen by similarity. An LLM wiki does it at ingest time, once per source, and keeps the result. Answers get faster and more consistent, and contradictions surface when a source arrives instead of hiding in two retrieved chunks. Our guide to agent memory vs RAG covers the same trade-off for AI agents, and AI knowledge base vs wiki compares the human-maintained version.

How to build your own LLM wiki in an afternoon

You need a coding agent (Claude Code or Codex), a folder under git and, optionally, Obsidian. The schema file below is a starting point you will change within a week.

1. Create the folders. Make a repository with three directories: raw for sources, wiki for the generated pages, and the repository root for the schema file. Run git init so every change is recorded.

2. Write the schema file. Save the starter below as CLAUDE.md if you use Claude Code or AGENTS.md if you use Codex. Our Claude Code memory guide explains how Claude Code loads that file at the start of every session.

3. Add five to ten sources. Clip articles with the Obsidian Web Clipper or drop PDFs and transcripts into raw. Start with a narrow topic.

4. Ingest one source at a time. Read the summary and the pages it touched, and correct the agent in conversation. Any correction you repeat belongs in the schema file.

5. Ask questions and file the answers. When an answer is worth keeping, tell the agent to save it as a page and link it from the index.

6. Lint weekly. Ask the agent to run a lint pass, list what it found and fix what you approve. Commit after each pass so you can compare versions.

7. Open the folder in Obsidian. The graph view shows which pages are hubs and which are orphans.

# Wiki schema

You maintain a Markdown wiki about <topic> in ./wiki.
Sources live in ./raw. Never edit, move or delete anything in ./raw.

## Page types
- wiki/sources/<slug>.md: one summary per source, with a link to the raw file.
- wiki/entities/<name>.md: people, companies, products, projects.
- wiki/concepts/<name>.md: ideas, methods, recurring themes.
- wiki/answers/<slug>.md: answers to questions worth keeping.
- wiki/index.md: every page, one line each, grouped by type.
- wiki/log.md: append-only history of every operation.

## Conventions
- Link pages with [[wikilinks]]. Every page links to at least one other page.
- Every claim cites the source page it came from.
- When a new source contradicts a page, keep both claims, mark the conflict
  under a "Contradictions" heading and say which source is newer.
- Dates use YYYY-MM-DD.

## Ingest
1. Read the new file in ./raw and summarize the key points for me.
2. Write wiki/sources/<slug>.md.
3. Create or update every entity and concept page it touches.
4. Update wiki/index.md.
5. Append to wiki/log.md: "## [YYYY-MM-DD] ingest | <title>".

## Query
1. Read wiki/index.md first, then the relevant pages.
2. Answer with citations to wiki pages.
3. If I say "file it", save the answer in wiki/answers and index it.

## Lint
Check for contradictions, stale claims superseded by newer sources,
orphan pages, concepts without their own page and missing links.
Report findings, fix only what I approve, then log the pass.

Where a personal LLM wiki breaks for a team

The pattern was designed for one curator. Karpathy lists a team wiki fed by Slack threads, meeting transcripts, project documents and customer calls among the possible uses, but the mechanics in the gist assume a single person steering one agent over one folder. Two critiques published after the gist set out what changes at company scale. Innobu's enterprise reality check (in German, 17 May 2026) argues that the pattern works as a personal tool and fails as a company platform, citing missing role-based access control, no transactional writes, no compliance-grade audit log and scaling limits at a few hundred pages. Pebblous's report on the LLM wiki adds that a wrong connection written into the wiki contaminates every later answer, and that contradictions between teams and concurrent edits are hard to resolve in plain Markdown.

Permissions

A personal wiki has one reader. A company has HR channels, board decks, contracts and private projects, and once the model compiles a page from several sources, the page no longer knows who could see each input. Either everyone sees everything or someone maintains a second permission system by hand.

Scale

The gist puts the comfortable range at about 100 sources and hundreds of pages. A company produces more than that in Slack in a week, and past that point you need search, deduplication and a way to decide which page is authoritative.

Many writers and sources changing at once

Twenty people and several agents ingesting in parallel will update the same entity pages at once, and git merge conflicts in model-written prose are slow to resolve. One-at-a-time ingest is a strength for one person and a bottleneck for a team.

Sources that are conversations, not documents

Most company knowledge lives in Slack threads, email, meeting transcripts, tickets and pull requests. These arrive continuously and change meaning as replies come in, and clipping them into a raw folder by hand does not keep up.

Keeping the newest version with its source

In a company, launch dates move, prices change and owners leave. Lint catches some of this after the fact. A team needs it at write time, with the current value on top, the older value kept for context, and both pointing back to the message or document they came from.

From personal LLM wiki to organization memory

Sentra keeps the shape of Karpathy's pattern and replaces the parts that only work for one curator. The table maps each piece of an LLM wiki to how a company runs it.

The result is knowledge compiled once and kept current, without anyone steering ingests or running lint passes. Our explainer on what a company brain is covers the broader category this belongs to.

When to build your own and when to use a managed one

Build it yourself when one person or a small research group owns the knowledge, the sources are documents you choose, everyone involved may see everything, and the wiki stays in the hundreds of pages. That covers personal research, course notes and due diligence on one company. The setup above takes an afternoon and costs only your agent subscription.

Use a managed one when the knowledge belongs to a company rather than a person. The signs are that most of it lives in Slack, email and meetings; different people may see different things; several teams and agents need the same answers; and facts change weekly. The work then is connecting sources, enforcing permissions and keeping the newest version on top without a curator. Sentra's Team plan for 2 to 20 people is listed at $16 per user per month and is currently free as a launch special; Enterprise, which adds API and MCP access for agents, is priced on request.

Frequently Asked Questions