When Andrej Karpathy posted llm-wiki.md, my feed lit up the way it always does when he ships something. Within 48 hours there were CLI tools, Go binaries, Obsidian vault generators, and at least three blog posts explaining "the new way to think about personal knowledge."

The pattern is genuinely good. I want to be clear about that before I push back on any of it. The core insight — that there should be a persistent middle layer between your raw sources and the answers an LLM gives you, and that the LLM itself should maintain that layer — is the right shape for this moment. Karpathy named something the rest of us were circling around.

But I want to make an argument I haven't seen anyone else make:

The LLM Wiki pattern, as Karpathy describes it, has a ceiling. And the ceiling is exactly the place where it stops being a personal toolkit and starts wanting to be infrastructure.

The pattern, in one paragraph

Karpathy's pitch: stop treating LLMs as one-shot RAG endpoints. Build a three-layer system. The bottom layer is raw/ — your articles, papers, code, screenshots, untouched. The top layer is the wiki — Markdown pages the LLM continuously maintains: summaries, concept pages, entity pages, comparison pages, plus index.md (space) and log.md (time). The connective tissue is the schema — a CLAUDE.md or AGENTS.md that tells the LLM how to organize, ingest, query, and lint.

The killer move is file-back: when a query produces something valuable, you write it back into the wiki as a new page. Knowledge stops evaporating into chat history. Conversations start generating context instead of just consuming it.

If you've been doing RAG for two years and feeling vaguely dissatisfied, that paragraph probably hit you the same way it hit me. It's correct. It's a real upgrade.

So what's the ceiling?

Ceiling 1: The schema is a programming task disguised as a config file

Karpathy's example schemas are clean. They're also written by Karpathy.

Every implementation I've seen in the last 48 hours has a different AGENTS.md, different folder conventions, different page templates, different rules for what gets file-backed. The gist comments are full of tips like "give your index a token budget" and "use a different template per entity type" — which is great advice and also the clearest possible signal that you are now writing software. You just happen to be writing it in Markdown bullet points.

For developers who like that, this is fine. Probably even fun. But zoom out: what fraction of people who would benefit from a persistent knowledge middle layer are willing to write their own schema from a blank file?

Small. The schema layer is the ceiling because it's the part that doesn't scale to new users.

The interesting design question is: what does a schema layer look like when it ships pre-built, but is still flexible enough to specialize? That's not a Markdown question. That's a product question.

Ceiling 2: Your agent doesn't live on your laptop anymore

The Farzapedia example is the most concrete part of the whole thread. Farza took ~2,500 personal items — journals, Apple Notes, iMessage — and let an LLM compile them into ~400 cross-linked pages. The line that stuck with me, and that Karpathy quoted approvingly:

"It's not built for me, it's built for my agent."

This is the right framing. It's also the framing that breaks the file-over-app architecture the moment you take it seriously.

Because if the wiki is built for your agent, and your agent is Claude Code running locally — fine, files work. But your agent is increasingly not that. It's:

A Claude Code session on a remote VPS doing scheduled work
An MCP-connected ChatGPT on your phone
A Slack bot answering questions for your team
An agent in a customer-facing flow that needs to read your product knowledge mid-email
Another agent that another agent spawned

None of those things can cd ~/wiki && grep.

They need a URL, not a file path. A network protocol, not a directory. A reachable server, not the laptop you closed this morning.

Karpathy's pattern assumes a very specific deployment surface: one human, one laptop, one agent process with filesystem access. Violate any of those — and most interesting agent use cases in 2026 violate all three — and the whole thing starts leaking.

This isn't a criticism of the design. It's a description of which scenario it optimizes for. Developer + Obsidian + Claude Code is a real and valuable scenario. It's just not where the field is heading.

Ceiling 3: Lint is doing a lot of unspoken work

Karpathy's loop is ingest → query → file-back → lint. The first three are exciting. The fourth is where every long-running personal knowledge system I've ever seen has died.

Lint, in this context, means: detect contradictions, find expired claims, repair broken cross-links, surface stale pages, deduplicate near-duplicates. Karpathy wisely says human owns verification — and he's right. But verification requires triage, and triage at scale requires more than grep and human attention.

Here's what nobody is saying out loud:

The moment your wiki has more than a few hundred pages, you can't lint it with text tools alone.

You need semantic similarity to find duplicates written in different words. You need access logs to find pages your agent never reaches. You need vector neighborhoods to find orphans. You need a set of capabilities that a Markdown directory, by design, does not have.

Karpathy's pattern is going to produce a generation of beautiful 80-page wikis that quietly rot at 800 pages. Not because the pattern is wrong, but because the maintenance layer requires capabilities that file-over-app deliberately excluded.

What the layer above looks like

If you accept those three ceilings — schema-as-product, agent-as-remote, lint-as-infrastructure — then the shape of the next layer falls out almost automatically. It needs to be:

Cloud-native, because your agents are not on your laptop.
MCP-native, because the protocol of how agents talk to knowledge has been decided, and it's MCP, and pretending otherwise is just relitigating a closed argument.
Schema-included, because the bar for adoption can't be "first, write a thoughtful AGENTS.md."
Vector-native, because lint and discovery and get_related cannot work on text alone past a certain scale.
One-click exportable, because the right answer to "but I want my data" is a Markdown dump, not a refusal to use a database.

These aren't speculative requirements. They're what falls out of the gap between Karpathy's framing and the actual deployment surface of agents in 2026.

Where the file-over-app crowd gets it right (and where they don't)

I want to steelman the pure-files position, because the people defending it are tracking something real.

What they're tracking: lock-in is bad, formats die, services shut down, your knowledge should outlive the company that hosts it. All true. All things I agree with.

What they're getting wrong: they're confusing storage format with deployment surface. You can have your data as Markdown files and have it reachable from a remote agent over a protocol. These are independent decisions. The argument "files are better than apps" is really "open formats are better than closed ones" — and that argument is won by exporting Markdown, not by refusing to run a server.

The cleanest version of this stack keeps Markdown as the canonical representation, vector embeddings as the index, MCP as the access protocol, and schema-as-product as the onboarding experience. The user types into a text box, the agent sees a structured knowledge graph, and the underlying truth is still files you can git clone.

That's the thing I'm building. It's called KnowMine — 11 MCP tools, pgvector under the hood, a SOUL personalization layer, wired into Claude / OpenClaw / the broader MCP ecosystem. Connect it to Claude Code right now and your agent gets a file-back loop with get_related_knowledge discovery for free, no AGENTS.md required.

But honestly, whether you use KnowMine or build your own version is not the point of this post.

The point

Karpathy named something important. The natural reading of his gist is "go build this in Obsidian." And that reading is going to leave a lot of people stuck at the schema-and-lint ceiling six months from now.

The actual lesson of the LLM Wiki pattern is bigger than the implementation he showed:

The middle layer between raw sources and agent answers should be a first-class product, maintained by the agent, persisted across sessions, reachable from anywhere the agent runs, and treated as infrastructure rather than as files in a folder.

If you take that sentence seriously, you don't end up at Obsidian. You end up at a knowledge protocol layer.

That's a different kind of thing.

Honest boundaries

The hosted knowledge protocol approach is not for you if:

You're a developer with under 500 documents and you enjoy writing your own tooling
You have hard requirements for offline / air-gapped operation
You're allergic to any cloud service on principle

In those cases, Karpathy's pattern is the right answer. Use it. The gist is excellent.

But if you're trying to give your agent — across devices, across sessions, across the four different AI tools you use in a week — a knowledge layer that compounds rather than evaporates, then you've outgrown the file-over-app model. You needed a protocol layer about six months ago.

The good news is one exists now. It's at knowmine.ai. Free tier, MCP endpoint, eleven tools, no AGENTS.md required.

Karpathy's LLM Wiki Has a Ceiling — And It's Exactly Where Files Stop Being Enough