Letting AI Grow a Knowledge Base: Trying Karpathy’s LLM Wiki

Read the original Japanese article.

When you are running several projects at once at work, university, and in your personal life, you keep running into a familiar knowledge-management problem. You read papers and articles. Important insights emerge from conversations with ChatGPT or Claude Code. You collect notes in Obsidian. You ask agents to update your knowledge base. Then, before you know it, you find yourself thinking, “Where did I see that again?”

The information is somewhere. The problem is retrieving it when you need it. As the collection grows, it becomes more common for notes to go unread, updates to stay isolated from related pages, and contradictions to pass unnoticed.

In this article, I’ll share my experience implementing the “LLM Wiki” pattern proposed by Andrej Karpathy, along with an explanation of the idea.

Why traditional knowledge management fails

Attempts at knowledge management, whether for an individual or a team, tend to stall in much the same way.

The first few weeks go well. Writing things down is enjoyable, and it feels good to see everything getting organized. But eventually, the cost of maintenance reaches a point where it outweighs the value.

Whenever you add something new, you also have to update related pages. If a contradiction appears, you have to fix it. You have to remove outdated information. This is painful for people. Psychologically, writing something new is easier than going back to a page you already wrote and revising it.

The result is a knowledge base that becomes “a graveyard where things are written but never read.” The information is there, but nobody refers to it. Since nobody refers to it, nobody updates it. The knowledge base gradually falls out of use.

The core problem is not an imbalance between the effort of writing information and the effort of rereading it. The deeper issue is that maintenance is a human task.

Karpathy’s idea

In April 2026, Andrej Karpathy shared a simple reversal of this problem in his gist, “llm-wiki.md”. His proposal is to have the LLM write and maintain the wiki, while people place raw sources—articles, papers, notes, and conversation logs—in a designated location. The LLM reads and interprets them, creates knowledge pages, connects them with cross-references, flags contradictions, and keeps the wiki up to date.

That is the “LLM Wiki” pattern.

The important point is that this is more than “a note-taking app with AI.” Karpathy emphasizes that a knowledge base should persist and compound over time.

With conventional RAG or agentic search built on a knowledge base, a system searches source documents and generates an answer for each question. That means the synthesis is performed as part of each query. An LLM Wiki instead keeps building up knowledge that has already been synthesized in the form of a wiki. Once something has been understood, it is recorded and can serve as a foundation for the next round of understanding. This is a distinction between a search-based workflow and one that maintains a persistent, accumulated knowledge artifact; implementations can of course vary.

Karpathy describes the wiki as an artifact that persists and compounds, with cross-references in place and contradictions already flagged. The knowledge recorded in the wiki becomes context when a new source is added. When you read a new paper, an insight such as “this relates to that concept from before” can emerge naturally. The LLM can read the new source while consulting the wiki, so a person does not have to reread everything from scratch. Karpathy’s original gist

The three layers of an LLM Wiki

Karpathy organizes an LLM Wiki into three layers.

1. Raw Sources

This is where primary sources are stored without modification: articles, papers, and PDFs. They are never changed. The LLM reads them but does not write to them.

Keeping them immutable matters because it lets you later verify what can actually be inferred from a source. If a statement in the wiki seems questionable, you can return to the original.

2. Wiki

This is the core of the LLM Wiki. In principle, it is a place where people do not write directly.

Karpathy proposes several kinds of pages:

• Summary pages: one summary page for each raw source.
• Concept pages: pages that bring together a concept or insight found across multiple sources.
• Entity pages: pages that collect facts about specific entities such as people, projects, and organizations.

There are also two special files for navigation:

• index.md: a catalog of all pages, organized as a table of contents by category.
• log.md: an append-only activity log recording what was ingested and updated, and when.

3. Schema

Files such as CLAUDE.md and AGENTS.md belong here. They give the LLM instructions about the wiki’s structure, page formats, naming conventions, and operating procedures.

The LLM reads this schema to understand how it should write the wiki. Changing the schema changes the LLM’s behavior.

Three operations: Ingest, Query, and Lint

Karpathy groups the system’s operations into three categories.

Ingest

Ingest applies a new source to the wiki. The LLM reads and discusses it, writes a summary, and updates cross-references across multiple wiki pages. Karpathy’s example describes updates spanning 10–15 pages at once.

When a new paper is added, for example, the agent can create a summary page, update related concept pages, flag contradictions it finds, add an entry to index.md, and record the operation in log.md.

This groups the maintenance work into one ingest operation instead of leaving each related update for me to remember.

Query

Query means answering questions by referring to the wiki. One important feature is that answers worth keeping can be added back to the wiki.

An insight is recorded once it has been reached. If you ask the same thing later, the LLM can consult the wiki instead of reasoning from scratch.

Lint

Lint checks the health of the wiki periodically:

• Are there contradictory statements, such as facts that disagree between old and new pages?
• Are there orphaned pages that nothing links to?
• Is any information outdated?
• Are there duplicate pages?

Karpathy frames linting as the wiki’s “immune system.” Regular linting keeps a wiki healthy as it would otherwise be left to decay.

Trying it in practice

I implemented the idea in my own environment. I use an Obsidian vault synced through iCloud as the home for the knowledge, with a setup that both Claude Code and Codex can operate.

├── vault/
│   ├── raw/
│   │   ├── articles/         ← Web articles
│   │   ├── papers/           ← Papers and PDFs
│   │   ├── conversations/    ← Conversations with LLMs
│   │   ├── briefings/        ← Daily morning briefings
│   │   └── memos/            ← Notes and miscellaneous memos
│   └── wiki/                 ← Knowledge layer generated and managed by the LLM
│       ├── index.md          ← Catalog of all pages
│       ├── log.md            ← Activity log
│       ├── summaries/        ← One page per raw source
│       │   ├── articles/
│       │   ├── briefings/
│       │   ├── conversations/
│       │   ├── memos/
│       │   └── papers/
│       ├── concepts/         ← Cross-cutting concept pages
│       ├── entities/         ← Accumulated facts about entities
│       └── queries/          ← Archive of valuable answers
└── schema/                   ← Agent instructions (outside the vault)
    ├── CLAUDE.md
    ├── AGENTS.md
    ├── generate-briefing.md
    ├── ingest-article.md
    ├── ingest-briefing.md
    ├── ingest-conversation.md
    ├── ingest-memo.md
    ├── ingest-paper.md
    ├── lint.md
    └── query.md

I handed the foundational setup over to Claude Code. I gave it Karpathy’s gist and an article about an earlier example, then asked it to build a wiki around those design principles.

I’m still refining the schema layer—the CLAUDE.md and individual ingest-skill files—so I’m not sharing their contents yet. Even the first pass generated by the agent was enough to work. When I explained the kind of knowledge base I wanted to operate, it was able to work out and produce much of the schema it needed.

What I customized

1. Integration with Morning Briefing

I already had a script called “Morning Briefing” that generates a Markdown summary of the previous day’s work each morning. I set it up to feed those files automatically into the wiki’s raw layer at raw/briefings/.

A briefing naturally describes what I did and what I decided. Ingesting it means project progress and decisions accumulate automatically in entities/. It seems fairly important for these entities to grow: because they collect facts, they appear to help provide context for conversations and wiki building.

I also added an automatic check in the Morning Briefing script to see whether each briefing has been ingested. If it finds a file that has not been ingested, it calls a second Claude to ingest it automatically. As a result, the briefing generated that day is added to the wiki on the same day.

2. Access from both Claude Code and Codex

I use Claude Code and OpenAI’s Codex together in my workflow. Claude Code mainly handles business tasks and strategic discussions, while Codex mainly handles implementation and code generation.

To let both agents refer to this wiki, I separated the schema layer and prepared both CLAUDE.md and AGENTS.md. Each agent reads its instructions at the start of a session and works with the same knowledge base as context.

3. Mobile notes can be ingested too

The wiki’s raw layer lives in an Obsidian vault. A note written in the Obsidian app for iOS syncs automatically through iCloud and becomes a source for ingest.

All I have to do is jot down a thought while I’m out or whenever something occurs to me in Obsidian. In the next session, Claude reads it, creates a summary in summaries/, and updates related entities in entities/. The experience of seeing notes accumulate in a knowledge base instead of ending when I write them is more satisfying than I expected.

Finally

Knowledge management breaks down not because people are lazy, but because maintenance has been made a human task. What is striking about Karpathy’s “LLM Wiki” is how it reverses that assumption. People just place raw sources. Reading, summarizing, adding cross-references, finding contradictions, and keeping things up to date become the LLM’s job. After implementing it in my own environment, I felt that this was more than a convenient note-taking app: it is a system where knowledge keeps compounding. Something understood once is distilled into the wiki, and that becomes context for reading the next source. Morning Briefing automatically ingests new briefings, so entities are updated day by day; a note I might have tossed into Obsidian becomes part of the knowledge base by the next session. When “write it and forget it” becomes “write it and it accumulates,” the way you relate to information changes.

To be honest, I’m still experimenting with the wiki’s structure, and I changed the way I divide up the directories while writing this article. It continues to work because I don’t need a perfect schema from the start. If I give an agent Karpathy’s gist and explain the kind of knowledge base I want to run, it can build something that works. And if I change the structure later, the LLM can adapt to it.

Once you have the basic structure of a raw layer, a wiki layer, and a schema layer, you can shape the rest around your workflow. You may not need Obsidian, Claude Code, or Codex. I think you can start by choosing one place to put primary sources and running your first ingest. From there, you can grow the system as you use it. I hope you’ll try building an LLM Wiki that works for you.

I plan to keep using mine. If I find new ways to use it, I’ll write another article.