Karpathy's LLM Wiki: Turn AI Research Into a Living Markdown Knowledge Base

You upload 20 PDFs to an AI tool, ask a few questions, and get decent answers. The next day, you ask a sharper question, and the model starts over: retrieve, stitch, infer, forget.

No accumulation. No durable synthesis. No memory you can inspect.

Karpathy’s LLM Wiki pattern fixes that by changing the unit of work. The LLM should not only answer. It should compile knowledge into a Markdown wiki that keeps improving.

RAG retrieves at runtime. LLM Wiki compiles knowledge into a readable, editable, traceable middle layer.

What It Is

LLM Wiki is not one fixed product. Karpathy’s gist is an idea file you can give to Claude Code, Codex, Cursor, ChatGPT, or another agent so it can instantiate the workflow for your project.

The architecture has three layers:

raw sources: the immutable inputs. PDFs, articles, meeting notes, images, spreadsheets, transcripts. The LLM reads them but does not edit them.
wiki: the LLM-maintained Markdown layer. Summaries, entities, concepts, decisions, contradictions, indexes, and cross-links live here.
schema: the rule file. Claude Code uses CLAUDE.md. Codex uses AGENTS.md. Cursor uses .cursorrules. This tells the LLM where files live, how pages are formatted, and what workflows to run.

Your job is to curate sources, ask questions, and steer the work. The LLM handles filing, linking, updating, and bookkeeping.

Karpathy’s framing is the useful one: Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.

Why It Beats Plain RAG

Plain RAG is useful, but it rebuilds the answer at query time.

LLM Wiki compounds:

New sources update old pages instead of becoming isolated summaries
Contradictions are flagged instead of blurred into a single answer
Important concepts become reusable pages
High-value answers can be written back into the wiki
index.md can act as the first navigation layer before you need vector search

This is not smarter search. It is search converted into durable structure.

Best Use Cases

Long-running research

You spend weeks reading papers, reports, interviews, and competitor notes. Chat history fragments the work. LLM Wiki turns each reading session into an incremental update.

Product and project memory

Requirements, customer feedback, meeting notes, and technical decisions tend to scatter across tools. LLM Wiki can compile them into current status, decisions, open questions, and risks.

Books and courses

Each chapter can update characters, concepts, arguments, themes, and disputes. The result is not a folder of summaries. It is a navigable companion wiki.

Long-lived AI agent work

Multi-session agent work often fails because every session starts cold. A wiki gives the next session a stable answer to: what did we do, why did we do it, and where are we stuck?

When Not To Use It

If you only have a few documents and a one-off question, do not build a wiki. Put the documents in context and move on.

If the source material is messy, do not rush into automated compilation. An LLM can make bad inputs look more coherent than they are. Clean the source layer first.

For high-compliance or high-stakes factual work, keep human review. LLM Wiki can preserve sources and contradictions, but it does not transfer responsibility from you to the model.

There is also a scale limit. Once the wiki grows into hundreds of pages, one index.md will stop being enough. At that point, add local search, layered indexes, or a Markdown search tool such as qmd.

Minimal Folder Structure

Start small. A docs/wiki setup is enough.

docs/
  raw/
    sources/
    assets/
  wiki/
    index.md
    log.md
    current-status.md
    concepts/
    entities/
    decisions/
  AGENTS.md

If you use Claude Code, replace AGENTS.md with CLAUDE.md. The rules matter more than the filename.

Initialization Prompt

Give your agent Karpathy’s gist and ask it to instantiate the pattern for the current project.

Read https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
and set up an LLM Wiki for this project.

Use this structure:
- docs/raw for immutable source files
- docs/wiki for generated Markdown pages
- AGENTS.md for the maintenance rules

Before editing, propose the page conventions, log format, and ingest workflow.
After approval, create the initial files.

The point is not file generation. The point is the schema. Without rules, the LLM is a helpful organizer. With rules, it becomes a repeatable wiki maintainer.

Daily Workflow

LLM Wiki has three basic operations: ingest, query, and lint.

Ingest: Add New Sources

Drop a source into docs/raw/sources, then tell the agent:

Ingest docs/raw/sources/customer-interview-2026-05-17.md.

Do not overwrite raw files.
Update the relevant wiki pages, index.md, current-status.md, and log.md.
Flag contradictions instead of silently resolving them.

One ingest may touch 5 to 15 wiki pages. That is the point. The source is not stored as a lonely summary. It enters the existing knowledge graph.

Query: Ask Through The Wiki

Do not ask the AI to jump straight back to raw sources. Make it start with index.md, then drill into relevant pages.

Using docs/wiki/index.md as the entry point, answer:
What changed in our pricing assumptions after the latest customer interviews?

Cite the wiki pages you used.
If the answer reveals a new decision or unresolved question, add it to the wiki.

Good answers should not die in chat history. Comparisons, decisions, open questions, and new connections should be written back.

Lint: Keep The Wiki Healthy

Run a health check every few sessions.

Lint docs/wiki.

Find:
- stale claims
- contradictions between pages
- orphan pages
- concepts mentioned often but missing their own page
- pages that need source citations

Propose fixes before editing.

This is where long-term knowledge systems usually fail. People stop maintaining links, consistency, and status. LLMs are good at that tedious work.

Example: Competitor Research

Suppose you are researching three AI coding tools. Structure it like this:

docs/raw/sources/
  tool-a-pricing.md
  tool-b-docs.md
  tool-c-review-notes.md

docs/wiki/
  index.md
  current-status.md
  concepts/context-management.md
  concepts/agent-permissions.md
  entities/tool-a.md
  entities/tool-b.md
  entities/tool-c.md
  decisions/positioning-gap.md

After the first ingest, the LLM creates entity pages for each tool and concept pages for the recurring themes.

Then you ask:

Which competitor is weakest for enterprise onboarding, and why?

The agent reads index.md, then the relevant entity and concept pages. If the answer produces a useful conclusion, it writes the enterprise onboarding gap into decisions/positioning-gap.md. The next competitor analysis reuses that judgment instead of rediscovering it.

Optional Tools

At small scale, the filesystem plus Markdown is enough.

Add tools only when the workflow asks for them:

Obsidian: graph view, backlinks, Dataview queries
Obsidian Web Clipper: save web pages as Markdown
Git: inspect wiki history and roll back bad updates
qmd: local Markdown search once index.md gets too large
Marp: generate slide decks from wiki content

Do not start with a stack. Start with the three layers.

Rules Worth Enforcing

First, raw sources are immutable. The LLM never rewrites them.

Second, every update touches log.md. Without a timeline, the wiki loses operational memory.

Third, contradictions are explicit. Do not let the model smooth them away.

Fourth, wiki pages stay short. One page owns one concept, entity, or decision. If it gets long, split it.

Fifth, read directly before adding RAG. Karpathy’s practical point holds: at moderate scale, index.md plus Markdown pages can be enough. Complex retrieval should be a response to growth, not the starting move.

LLM Wiki is not about making AI remember more. It is about turning each reading session and each answer into structure the next session can inherit.

Before you drop another document pile into a chat window, ask the sharper question: do you need one answer, or do you need a knowledge base that gets better every time you use it?

Karpathy gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f Reference implementation: https://github.com/Ss1024sS/LLM-wiki