Why I Let My AI Agent Maintain My Personal Wiki

Why I Let My AI Agent Maintain My Personal Wiki (Andrej Karpathy's Idea)

A few months ago, Andrej Karpathy, an OpenAI co-founder now working at Anthropic, published a short document that fits in a single file. No code, no tool to install, no product. Just plain text describing a complete method for managing personal knowledge. I want to walk through what's actually in it and why I think it holds up.

The Starting Point: Obsidian and the Maintenance Problem

Obsidian is a free note-taking app. Every note is a plain text file that sits on your disk, and you can link one note to another. Enough links, and Obsidian shows you a "graph view" — a web of connected notes that many people describe as a second brain.

The catch is obvious to anyone who has actually tried this: those links don't create themselves. Writing a note, then remembering to link it to related notes, then keeping that web consistent as it grows, is real ongoing work. Karpathy's method doesn't replace Obsidian. It changes who does that work.

The Problem With How Most People Use AI on Documents

Karpathy opens by describing the pattern most of us already use: upload a folder of documents, ask a question, the model pulls the relevant chunks and answers. This is what tools like NotebookLM or a document-aware ChatGPT session do.

The issue is structural: the model rediscovers your knowledge from scratch on every single question. If you asked a hard question yesterday and the model stitched together five sources into one answer, that synthesis isn't saved anywhere. Ask a related question tomorrow, and it starts over.

The Actual Idea: An Agent-Maintained Wiki

Karpathy's proposal is that the agent builds and maintains a persistent wiki — a linked set of text files sitting between your raw sources and your questions. When a new source comes in, the agent doesn't just index it. It reads it, pulls out what matters, integrates it into what already exists, updates the relevant entity and summary pages, flags where the new material contradicts an older claim, and keeps definitions current.

He describes his own setup plainly: a coding agent open on one side, Obsidian open on the other. The model edits based on the conversation, follows links, checks the graph view, reads existing pages as it works. His summary line is the clearest part of the whole document: Obsidian is the IDE, and the wiki is the code the agent is writing.

Three Layers

The architecture has three parts:

1. Raw sources — everything you've collected: articles, research, images, datasets. The key property is that they're immutable. The agent reads them but never edits them. This is your ground truth.
2. The wiki — a folder of text files the agent generates and owns: summaries, entity pages, concept pages, comparisons. This layer belongs to the model.
3. The schema — a single document (named AGENTS.md, CLAUDE.md, or the equivalent for whichever agent you use) that describes how the wiki is organized, the conventions it follows, and the process for ingesting a source, answering a question, or doing maintenance. You and the model develop this document together over time.

Three Operations

• Ingest. You drop a new source into the folder and ask the agent to absorb it into the network. It reads the source, talks through the key points with you, writes or updates a summary page (its own territory), updates the index, updates related pages, and adds a log entry. Karpathy notes a single source can touch 10 to 15 pages. His stated preference is to ingest one source at a time and stay involved — reading summaries and steering — rather than batch-ingesting many sources at once. Slower, organic growth compounds better, because each new addition links into material that's already been digested.
• Query. You ask a question. The agent finds the relevant pages, reads them, and composes an answer with citations. The detail worth stressing: a good answer can be written back into the wiki as a new page. A comparison you asked for, a connection you noticed mid-conversation — these are usually worth something and normally just disappear into chat history. Here, your own exploration accumulates the same way an ingested source would.
• Lint. A periodic health check. You ask the agent whether the wiki is healthy, and it looks for contradictions between pages, claims a newer source has already superseded, orphan pages with no links in or out, concepts that come up often but have no page of their own, and gaps a quick search could close. Karpathy adds that the agent is also useful for proposing new questions or sources worth chasing down. It's the same idea as linting code, applied to prose.

Two Special Files

• index.md is a content map: every page, linked, with a one-line summary, organized by category, updated on every ingest. When a question comes in, the agent reads the index first and decides from there whether to dig deeper. Karpathy claims this scales surprisingly well — on the order of 100 sources and hundreds of pages — and that it saves him the infrastructure of embeddings-based retrieval entirely. I haven't tested it at that scale myself, so I'd treat that specific claim as his experience rather than a proven result, but it's worth checking against your own use case.
• log.md is a chronological, append-only journal. His tip: open every entry with the same template, so you can pull the last few entries with a simple command.

A Note on Tooling

At some point it's worth building an actual search tool over the wiki, and Karpathy names one option for local Markdown search. But he's explicit that this comes later. Reaching for a search engine on day one is exactly the wrong way to start; the index file is enough at first.

On the Obsidian side, a few plugins came up: a web clipper that turns an article into Markdown on the way in, the graph view for visualizing the wiki's shape, a plugin for generating diagrams or slides from pages, and a query plugin for running structured lookups over your notes. Worth adding: since the wiki is just a folder of text files, you get git-style version history for free if you want it.

Why This Actually Works

Karpathy's real point is about maintenance economics, not tooling. The hard part of running a knowledge base was never reading or thinking. It's the small, constant upkeep around it: updating references, keeping summaries from going stale, flagging when new information contradicts something old, staying consistent across dozens or hundreds of pages.

His line, and the one I keep coming back to: people abandon a wiki because its maintenance cost grows faster than its value. That's the whole story — it's not a discipline problem or a time problem, it's an economic one. Models don't get bored, don't forget to update a reference, and can touch fifteen files in a single pass. The cost of maintenance trends toward zero.

What This Is and Isn't

Karpathy is upfront that the document is intentionally abstract. It describes an idea, not one specific implementation. Your folder structure, file formats, and tooling depend on your domain and on which agent you're using. The intended way to use it is to hand the document to your own agent and develop a version that fits you together; the document's only job is to transmit the pattern.

There are two practical ways to start. The one he recommends, and the one I used myself: copy the full gist, paste it to your agent, and ask it to set up the structure and write the schema file that matches what you actually do. The second is a community-built skill that wraps the same idea into a single install command — unofficial, not built by Karpathy, but reportedly tested across a wide range of agents.

The Short Version

This isn't a tool. It's a division of labor: one folder you fill and never touch, a second folder the model owns and maintains, and one document that tells it how. People abandon wikis because upkeep gets more expensive than the value it returns. Whoever actually does the maintenance is what decides whether the system survives, and that's the part this idea changes.