Karpathy's LLM Wiki, But for Your D&D Campaign (And It's Already Live)

Why does AI forget your campaign?

The context window is not memory. It's a whiteboard that gets wiped after every session. A model can hold a million tokens, but quality starts degrading long before that, and when the session ends, everything disappears. The next conversation begins from zero.

In a chatbot that's annoying. In a role-playing campaign it's fatal. You spend three sessions building a rivalry with a smuggler named Elara. You spare her life in a crypt. Two weeks later the Dungeon Master introduces her again — as a man, from a different city, who has never met you. The illusion breaks. The story you were invested in stops being yours. If you've played with a raw LLM, you know exactly the moment we mean: the dead NPC who keeps talking.

RAG was the first serious fix: embed your documents into vectors, store them, and retrieve the relevant chunks at query time. It works — millions of production systems run on it. But it has a structural limit that a 2024 research paper mapped into seven failure points. Three of them matter for a Dungeon Master: chunking splits a character across fragments so the model finds one and misses the rest; re-derivation means every turn starts from scratch, learning nothing; and passivity means the system only ever answers, never noticing that two sources disagree.

Three ways an AI can remember: retrieve, compile, act

The current debate lines up three architectures. They get framed as rivals. They're not — they are three layers of the same stack.

• Retrieve (RAG) — find relevant content at scale. Great at breadth, blind to depth; it re-reads the same books for every exam and never learns the material.
• Compile (the LLM wiki)— Karpathy's idea: compile sources once into a persistent, cross-linked wiki. The knowledge compounds; it just doesn't scale to millions of documents.
• Act (autonomous skills)— Garry Tan's GBrain: knowledge that doesn't sit there but triggers actions, runs on a schedule, works while you sleep. Powerful, and a serious engineering commitment.

The right question isn't “which one wins.” It's what is your agent's job?A Dungeon Master's job is all three at once — which is why it makes such a brutal test case. Here is where we actually are.

Retrieve: RAG over your campaign

The base layer is real RAG. Every article in your campaign's Codex is embedded as a vector and stored with pgvector in Postgres. When the Dungeon Master needs something the structured lookups don't cover, it runs a semantic search over those embeddings and pulls the closest passages.

This is the unglamorous, load-bearing part. It scales, it's fast enough for a live turn, and it's the fallback when the graph doesn't already know the answer. But on its own it has exactly the weakness Karpathy points at: it retrieves, it never compounds. So we don't stop here.

Compile: the Codex is Karpathy's LLM wiki

The Codex is Karpathy's LLM wiki. We shipped it for tabletop RPG instead of research papers. Same three layers he describes:

• Immutable sources — your actual play. The transcript of what happened at the table. The model reads it but never rewrites it.
• The wiki — the Codex: LLM-written entity pages for every NPC, place, quest and thread, with summaries, status, and cross-links. The model owns this layer.
• The schema — the rules for how the wiki is maintained: what counts as an NPC, how backlinks form, what a contradiction is.

And it compounds the way Karpathy describes. When a scene ends, the Dungeon Master doesn't just write one summary — it reads the new events against the existing Codex and updates every page they touch: new cross-references, updated status, a fresh timeline entry. One entry literally reads “The DM keeps this entry.” The wiki grows richer the longer you play.

The payoff shipped this week: the Dungeon Master now reads its own Codex every turn. It doesn't dump the whole wiki into context — it routes to the entities that matter in the current scene, pulls their pages plus one hop of backlinks, and injects a tight memory block. That's the retrieve + compile intersection the whole industry is drawing on a whiteboard, running in a live game.

The problem nobody mentions: coherence, not memory

The “RAG is dead” essays skip the hard half. For a story, remembering is the easy half. The hard half is not contradicting yourself. A wiki that compiles itself will happily compound its own hallucinations — one wrong detail gets cross-referenced into three pages and becomes canon. Karpathy's gist is 200 elegant lines; in production, the lint and verification is 80% of the real work.

So the interesting engineering isn't the compile step, it's the guardrails. The Codex separates what a player may see from DM-onlysecrets, so the memory the Dungeon Master reads can include the twist without ever leaking it to the table. And we don't trust any of it on vibes — we run evals. With the memory block on, the Dungeon Master uses roughly three times more canonical facts per scene and never leaked a secret across repeated runs; with it off, it invented three mutually contradictory backstories for the same character. That gap is the whole product.

Act: what's coming

The third layer is the honest part of the roadmap. Today the Dungeon Master already actsthrough tools — it rolls dice, resolves mechanical combat, registers NPCs, tracks clocks. But those fire reactively, while it narrates your turn. What it doesn't do yet is what Garry Tan's GBrain does: run on its own.

The version we want is a Dungeon Master that keeps the world turning between sessions — advancing a rival's scheme, spending the favor an NPC owed you, letting a threat you ignored grow teeth — so you come back to a world that lived without you. That's the action layer, and it's the honest “coming soon” on the diagram above. The point is that the memory and the wiki are the hard prerequisites, and those already exist.

So which architecture wins?

None of them, alone. The same way databases stopped being “SQL or NoSQL” and became hybrid systems, agent memory is converging into a single stack: retrieve at scale, compile into persistent knowledge, act on it autonomously. The teams still asking which one to pick are asking the wrong question.

We didn't set out to prove a thesis about AI memory. We set out to build a Dungeon Master that doesn't forget your story. They're the same project. And the least forgiving place to test it isn't an enterprise wiki, it's a table of players who will notice the second their dead rival starts talking again.