LLM Wiki, Opened Up — The ‘Automatic Memory’ Myth and a Schema That’s Just a Few Lines#

2026-06-28

In my previous post, I Decided to Call Them Harness Skills, I resolved to open the door I’d kept shut and examine external, battle-tested patterns one by one. I wrote that I’d start absorbing the least invasive ones first. The very first target was LLM Wiki. This post is the actual follow-through on that resolution. I applied something I only knew conceptually to a real repository, and in the process I corrected two misconceptions.

A Quick Recap: What LLM Wiki Is#

LLM Wiki is a pattern proposed by Andrej Karpathy that went viral in April 2026. In one line: “turning a pile of raw documents into a Wikipedia that the LLM maintains directly.”

Why this is new becomes clear when you compare it to RAG (Retrieval-Augmented Generation, which retrieves relevant fragments from raw sources at query time and generates an answer). RAG digs through the raw sources anew every time a question comes in. It repeats yesterday’s analysis again today, and it has to rediscover the connections between documents every single time. Knowledge doesn’t accumulate.

LLM Wiki is the opposite. When a new source arrives, the LLM reads it, extracts the key information, and integrates it into the existing wiki. It updates concept pages, revises summaries, and flags the spot where a new source contradicts an old claim. Because it compiles knowledge once and keeps it current, the wiki grows richer over time. To borrow Karpathy’s analogy: Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.

Up to here is what I covered in the previous post. The trouble began the moment I started looking closely in order to actually apply it.

First Misconception — “It Updates Its Memory on Its Own”#

The vague impression I’d picked up was that “once you install LLM Wiki, the agent builds and updates its memory automatically, on its own” — as if it were autonomous memory spinning away in the background. But when I read the original document myself, this turned out to be false.

Karpathy’s original pattern is thoroughly human-in-the-loop. In his own words: “I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize.” And he nails it down: “The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means.”

In other words, the wiki springs into action the moment a human speaks to it — “organize this source for me,” “give it a health check.” It’s not magic that spins on its own to update memory. Tellingly, the very thing Karpathy set himself against is “an AI that allegedly gets better the more you use it” — that is, implicit, magical, background memory. LLM Wiki touts the exact opposite as its strength: being explicit and file-based.

So where did the “automatic” impression come from? What’s automated is the labor, not the trigger. Once you say “organize this,” all the tedious maintenance that follows is automatic.

The part of this pattern that drew me in most was exactly this: what gets automated. Karpathy points out that the real bottleneck in maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping (the chore of recording and updating material without gaps, like keeping a ledger). The reason people abandon wikis is that this bookkeeping burden grows faster than the value. The LLM doesn’t get bored and can touch fifteen files in one pass. Because the cost of maintenance converges to zero, the wiki survives.

In short, “automatic memory that updates itself” is actually the thing Karpathy kept at arm’s length, and the real value lies in a division of labor where the human sets direction and the LLM takes on the bookkeeping.

Second Misconception — “There Must Be Some Special Technology”#

I once heard someone remark, “LLM Wiki? It’s nothing special. A few lines of text is all there is to it.” At first it sounded dismissive, but after reading the original I found it was technically an accurate observation.

LLM Wiki has no separate library, no vector database, no special runtime. It has exactly two components. One is a folder convention (a place for raw sources and a place for wiki pages); the other is a single operating-guideline document called the schema. This schema tells the LLM how the wiki is structured and by what rules to update it. Turning a chatty chatbot into a disciplined wiki maintainer comes down to this one page.

So “a few lines of text is all there is to it” is true. It’s just that the value isn’t in those few lines, but in the result that piles up over time as you follow those rules. The skeptical view that there’s no magic technology is correct. But the real effect comes not from technology, but from steadily operating it and accumulating knowledge.

One more thing became clear here. What Karpathy released is not a “ready-to-use finished product” but an “idea file.” He wrote at the top of the document: “This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.” And he reiterates at the end: “This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice.”

In other words, Karpathy’s gist is a meta-template. Paste it into your agent, and the agent works with the user to produce the actual schema fit for that user’s domain. The application is left to each person. This connects with another insight from the previous post — in this era, you share the idea rather than the code, and the agent fills in the rest.

So I Applied It Myself#

Once I cleared away the misconceptions, the application was actually simple. Here’s how I brought LLM Wiki into this blog repository.

First, I created a wiki/ directory following Karpathy’s three-layer structure exactly.

To this I added index.md (a catalog read first when answering a query) for indexing and log.md for a chronological record. And so as not to leave it an empty shell, I fed in the LLM Wiki research itself as the first source, so that one full lap of raw → pages → index → log actually ran.

The crux is what comes next. So I wouldn’t have to retype long instructions every time, I kept the schema as a file and referenced it with a single line at the entry point. That is, I added one line to CLAUDE.md: “When working with the wiki, follow wiki/SCHEMA.md.” Because CLAUDE.md is always auto-loaded into context, that single line keeps the agent perpetually aware of the wiki’s operating rules. This blog already references .cursor/rules/ and .memory/ the same way, so it was a natural fit.

Finally, I made a /wiki slash command that formalizes the three operations: ingest / query / lint. But this is a convenience, not a requirement. The original pattern has no commands; you can just say in plain language, “organize this article into the wiki,” and it works the same way. The command merely standardizes that instruction so it runs by the schema’s rules without a lengthy explanation each time.

One option remains here. If you want it to update fully unattended, without lifting a finger, you can attach a hook that runs ingestion automatically whenever a file is added to raw/, or a scheduled agent that runs daily. But that’s an extension beyond Karpathy’s original concept. The reason he deliberately keeps a human in the loop is that deciding what to emphasize and what to discard requires human judgment. Run it fully unattended and the wiki’s quality can degrade. So for now I chose to start with the basic form, where a human pulls the trigger.

Opening One Door I’d Kept Shut#

What I gained from this application isn’t a directory structure but two corrected understandings. One: LLM Wiki is not magic that remembers automatically, but a division of labor where the human sets direction and the LLM takes on the bookkeeping. Two: its core is not grand technology but “a schema that’s just a few lines” and the knowledge that piles up on top of it.

In the previous post I wrote that I’d guard against “the feeling of doing well sliding into the illusion that there’s nothing left to learn.” Actually opening up the low-invasiveness LLM Wiki this time, I found it was philosophically almost identical to the repository-based memory (.memory/) I was already using — yet I could learn a more refined skeleton from it: “sources are immutable, the wiki is owned by the LLM, discipline comes from the schema.” Rather than tearing everything down and starting over, I picked one good idea and absorbed it.

I’ve opened one door. I intend to open the next one the same way.

Related#

• I Decided to Call Them Harness Skills — Breaking the Illusion of Doing Well and Opening Up My Harness — the post this one grew out of. It’s where I named LLM Wiki a “harness skill” and resolved to start absorbing external patterns.

References#

• Andrej Karpathy — LLM Wiki (gist)
• Andrej Karpathy — tweet on LLM Wiki