Andrej Karpathy’s llm-wiki

I’ve been slowly catching up with Andrej Karpathy’s llm-wiki concept.

Anyone currently working with AI agents probably has a question somewhere in the back of their mind: what kind of memory should you give an LLM, and how? A variety of approaches have emerged — from MEMORY.md files to RAG — but I don’t think there’s a single right answer. What matters most is finding the technique that’s appropriate for your particular use case.

Local wiki, in that regard, seems like a promising alternative with solid performance relative to its technical complexity. Typically, things start with a single Markdown file. As content grows, it splits into an index file and a collection of content files — naturally evolving into a tree structure. But if you can build a wiki-style document set instead, I suspect it would allow significantly more information to be navigated more efficiently than a tree structure. That’s because a wiki is a collection of many documents bound together in a graph structure. The catch is that the wiki format demands considerably more effort to build and maintain than you might expect.

Karpathy proposed a structure where the construction and maintenance of the wiki is delegated to an LLM — and he named this concept llm-wiki. The core idea is simple: humans inject the raw source material, while the LLM handles building, navigating, and managing the wiki. The problem is that he intentionally wrote the document abstract. And precisely because of that, I keep running into moments of uncertainty — like: on what basis should an incoming document be split? This, actually, is something that happens constantly in real-world wikis. A document starts as a short single page, then gets split when it becomes too large. Or independently accumulated knowledge later finds an unexpected connection. And since I’m aiming for team use rather than personal use, there are additional layers of complexity to think through.

One thing that gives me comfort, though, is that this is an era where we can build first and verify with our own eyes, instead of just imagining. I plan to dig deeper into this for a while.