Turning Karpathy's LLM Wiki idea into Kiro setup
Karpathy's LLM Wiki pattern — an LLM maintaining its own compounding knowledge base over immutable sources — mapped cleanly onto Kiro. Steering files become the schema, hooks handle ingest and lint, and the whole thing runs as configuration, no code.
"The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else." — Andrej Karpathy
Andrej Karpathy's LLM Wiki idea is actually a quite simple one. I'll explain it in simple terms and demonstrate how I built it in Kiro IDE.
Karpathy sees a gap: RAG knowledge bases are one-way. LLMs can read from them but not update them. Letting the LLM update the RAG knowledge base isn't a good idea either, since that's the source of truth. But how about we let the LLM maintain its own version of it and compound it over time? He presents the pattern as a personal, curated knowledge store with associative trails between documents, but the basic idea can be applied in any context.
Karpathy is trying to build persistent LLM memory that LLMs are in full control of reading and writing. I don't think it's something we weren't doing already — but he gives the idea real structure. The wiki has an
index.md that points to what content sits in what file. It's personal, tool-agnostic, not shared with any tool provider, and doesn't depend on any infrastructure. The LLMs maintain it themselves. Humans shouldn't get in the middle of that organization work.The reason this works is about maintenance, not intelligence:
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.
The LLM wiki gist is deliberately abstract. It describes the pattern and leaves the instantiation to you and your agent. This post is the instantiation I did in Kiro , start to finish. No code, just configuration — which turned out to be the point.
The pattern has three layers and three operations:
- Layers: raw sources (immutable), the wiki (LLM-owned markdown), the schema (the rules telling the LLM how to maintain the wiki).
- Operations: ingest (a new source arrives), query (you ask a question), lint (periodic health check).
Why Kiro fits
I noticed that every concept discussed in LLM Wiki has a direct counterpart in Kiro. Nothing had to be invented.
The diagram shown above is the whole architecture. On the left, the three-layer design from Karpathy's gist and the three operations. On the right, the Kiro implementation: steering files become the schema, hooks drive the operations automatically, and two project folders hold the read-only raw sources and the read-write wiki. Kiro sits in the middle, orchestrating the LLM on one side and the files on the other, with the user supplying direction.
The mapping that made this almost-trivial to build:
| llm-wiki concept | Kiro feature |
|---|---|
| Schema | Steering files in .kiro/steering/ |
| Auto-action on new source | fileCreated agent hook |
| On-demand lint | userTriggered agent hook |
| Immutable sources | A raw/ directory the schema forbids editing |
| Wiki as codebase | A wiki/ directory with version history via git |
Steering files are Kiro's way of injecting persistent rules into every agent session — exactly what Karpathy's "schema" document is. Hooks are event-driven agent triggers — exactly what you want for "when a file shows up in raw/, ingest it."
What I built
I asked Kiro to scaffold the environment. The result is this tree:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
my-wiki/
├── .kiro/
│ ├── steering/
│ │ ├── wiki-schema.md
│ │ ├── ingest-workflow.md
│ │ ├── query-workflow.md
│ │ └── lint-workflow.md
│ └── hooks/
│ ├── ingest-on-new-source.kiro.hook
│ └── lint-wiki.kiro.hook
├── raw/
│ └── assets/
└── wiki/
├── index.md
├── log.md
├── sources/
├── entities/
└── concepts/The schema as always-on steering
wiki-schema.md is the single most important file. It's marked as always-on steering, so every Kiro chat session starts with the wiki's constitution loaded. It defines the three layers, the page types, the required frontmatter, the linking conventions, the citation rules, and the log entry format. Crucially, it encodes the hard rules: never modify raw/, never invent citations, never delete a wiki page without confirming.This is what turns a generic chat agent into a disciplined wiki maintainer. Without it, you get a helpful assistant that forgets the conventions between sessions. With it, you get consistent behavior across weeks or months of use.
Workflows as manual steering
The three operations — ingest, query, lint — are each their own steering file, but set to manual inclusion. You pull them in by typing
#ingest-workflow or #query-workflow in chat. This keeps the always-on context lean while giving you (and the hooks) a way to invoke the detailed recipe when you need it.The ingest workflow, for example, is explicit about sequence: read the source, discuss takeaways with the user first, only then write files, update affected pages, flag contradictions, update the index, append to the log, report back. A single ingest might touch 5-15 wiki pages. The workflow makes that routine rather than chaotic.
Hooks that close the loop
This is where the Kiro implementation does something interesting. Two hooks turn the wiki into a live system:
- Ingest on new source — a
fileCreatedhook watchingraw/**/*. Drop any file intoraw/and the agent wakes up with instructions to run the ingest workflow against it. The friction of "remember to ingest this" disappears. - Lint the wiki — a
userTriggeredhook that shows up as a button in the hooks panel. One click runs a full health check: orphans, broken links, stale claims, unflagged contradictions, missing pages, index drift, log hygiene.
You could add more. A
fileEdited hook on wiki/index.md to validate links. An agentStop hook that reminds you to commit. A postTaskExecution hook that runs a mini-lint after every ingest. The building blocks are all there.Raw and wiki as separate trust zones
The
raw/ directory holds the immutable layer. The schema forbids writes to it. The wiki/ directory is the agent's playground — it creates, updates, and links pages freely there. This separation maps exactly to the read-only / read-write split in the diagram, and git gives version history over both for free.What the workflow feels like
Once the scaffolding is in place, the day-to-day loop is extremely simple:
- Find a source you want to include — a paper, an article, a chapter of a book.
- Drop the file into
raw/. - The ingest hook fires. Kiro surfaces the key takeaways and asks what to emphasize.
- You approve, maybe redirect. Kiro writes the source page, updates the entities and concepts it touches, flags anything that contradicts what's already in the wiki, updates the index, appends to the log.
- Later, ask questions. Kiro consults the index first, drills into the relevant pages, answers with citations. If the answer is real synthesis — a comparison, a connection, an argument — Kiro offers to file it back as a synthesis page so it compounds instead of evaporating into chat history.
- Every week or two, click "Lint the wiki" and fix what it finds.
Where to go next
If you want to try this yourself, the full pattern is in Karpathy's gist . The Kiro-specific instantiation is what's documented above.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article