All analyses
Playbook

The AI second brain that maintains itself: the Karpathy method.

·14 min read

Everyone has access to the same LLMs. The model is no longer an edge; the only one left is the context you give it: readings, decisions, clients, years of accumulated intel. A model "custom-trained" on a singular brain, without a single line of fine-tuning. Notes scattered across Notion, Google Docs or Apple Notes are useless: the AI cannot read them.

The method that changes this was formalized by Andrej Karpathy in the spring of 2026: let an LLM agent build and maintain a personal wiki in plain-text markdown. Three layers, three operations, zero infrastructure.

The missing system to turn a stock of sovereign data into an operational AI brain, and make that asset the one competitive advantage the arrival of AI does not flatten.

1. Why every second brain dies (and discipline has nothing to do with it)

How many note-taking apps end up abandoned within months?

Notion installed over a weekend, abandoned three months later because nothing can be found. Apple Notes turned into a graveyard of fragments without context. Thirty Google Docs titled "draft", "notes", "untitled 47", scattered across the Drive, never reopened. A To read folder on the desktop weighing twelve gigs.

The reflex is always the same: I lack discipline.

It's wrong. And it matters to establish, because as long as that belief holds, you keep paying for the next app hoping it will save you. None will. The problem is not in the tool, and it's not in the person using it.

The real blocker is bookkeeping: the silent maintenance of a knowledge system. Updating links between pages, keeping summaries current, noting when a new source contradicts an old belief, filing the new note in the right place, cross-referencing concepts. Nobody drops a notes system because reading or thinking is too hard. People drop it because keeping the base up to date is an invisible job that grows faster than the value it returns. Andrej Karpathy framed it cleanly a few weeks ago:

« Humans abandon wikis because the maintenance burden grows faster than the value. »

The problem is not a reading flaw or a method flaw. It's the maintenance that ends up wearing down every successive second brain.

In 2026, that brake just dropped. LLMs don't get bored. They can touch fifteen files at once without forgetting a cross-reference, re-read an entire base on every ingestion to spot what changes, what contradicts, what reinforces. They don't have a bad mood on Sunday night. The maintenance cost drops to almost zero.

2. What Karpathy revealed in April 2026

Brief context on the source, because it matters. Andrej Karpathy is the former director of AI at Tesla, a founding member of OpenAI, and one of the most followed voices on practical LLM use. His explanations have one quality: they crystallize patterns several months before they are productized or packaged by the tools on the market. When he describes what he does with his own tools, it's worth listening.

On April 2nd, 2026, he posted on X. What follows is not a research paper, it's a tactical note that deserves three readings to fully grasp what he describes:

« Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). »

Three days later, he published a detailed gist that formalizes the pattern. The number he drops casually mid-text is the one that shifts the conversation: he maintains one of these wikis at about 100 articles and 400,000 words, with no RAG, no embedding pipeline, no custom infrastructure. Just markdown files in a folder, and an LLM agent that maintains them.

For anyone who has touched retrieval-augmented generation in an enterprise context, that line is a slap. The industry duct-tapes vector stacks, tunes chunk sizes, benchmarks rerankers. And a respected voice in the ML community says, casually: at my scale, none of that is necessary, a markdown wiki is enough.

The metaphor he uses makes the pattern intelligible in one go:

« Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. »

The human reads, navigates, asks questions, validates. The LLM writes, refactors, files, links. The wiki (the entire body of knowledge) becomes an object maintained by the user, but edited by the machine. That's exactly the division of labor that was missing to keep people from cracking after three months.

And it's all in plain-text markdown. Meaning: readable by any AI, any tool, in any system, for the next thirty years at least. No proprietary format. No vendor lock-in. No abstraction layer that will betray the user when today's app changes ownership or pricing.

That property is what separates a real second brain from Notion, Apple Notes, Google Docs. Those are visual silos designed for human eyes. They are not designed for an AI to read, link, maintain. In 2026, that's a fatal architecture mistake.

3. The architecture, no bullshit

Here is the pattern. It fits in three layers and three operations.

Layer 1: Raw. The folder of raw sources: articles captured via Obsidian Web Clipper, YouTube/podcast transcripts, screenshots, voice notes, papers. Everything that comes in goes through here. Immutable. The AI reads this folder, it never writes to it. The equivalent of archives.

Layer 2: Wiki. The pages the AI generates and maintains from raw: concept pages, entity pages (the people, companies, tools in play), atomic idea pages (the claims held or explored). Plus two special files: an index.md that catalogs the wiki, and a log.md that journals every ingestion, every question, every maintenance pass chronologically. This layer belongs entirely to the AI. You navigate, you read, but you almost never edit a page by hand.

Layer 3: Schema. A single file. It's called CLAUDE.md (or AGENTS.md, depending on the agent used). It describes how the AI should file: filename conventions, wikilink rules, YAML front-matter to include, citation rules, what it is not allowed to do (for instance, never re-edit a raw file). That's what turns a generic chatbot into a disciplined librarian. Without that file, an LLM improvises every session; with it, you have a system.

And three operations make the whole thing run:

  • /ingest: a source is dropped into raw/. The agent reads it, summarizes in two sentences what it takes from it, and proposes the pages to create or update. The human validates. The agent writes five to fifteen files at once, cross-referencing everything that exists. A single source touches ten pages of the wiki. That's where the compounding magic happens.
  • /query: a question is asked. The agent reads the index, drills into three to five relevant pages, answers with wikilink citations. No generic hallucination: the answer comes from the user's base.
  • /lint: periodic health audit. The agent surfaces a list of orphan pages (no inbound link), broken wikilinks, contradictions between pages, pages too old in active domains. The human drives the fixes, the agent executes.

Setup in one command. Literally paste this into Claude Code, in an empty folder:

Help me set up a LLM wiki that fits my needs and workflows
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

The agent will read the Karpathy gist, ask a few questions on the concrete case (domains to track, sources ingested, frequency, language), and generate a first CLAUDE.md + the folder structure raw/, concepts/, entities/, ideas/, index.md, log.md. Ten minutes later, the second brain is live. A first source in raw/, an /ingest, and the machine is running.

What you need: Obsidian (free), Claude Code, a git folder for versioning, and the schema file. Zero infra. No vector base, no chunking, no reranker, no stack to maintain. All the complexity goes into a single markdown file readable by a human.

In our AI implementation studio, we install this pattern with French-speaking SMBs before even mentioning a RAG or embeddings. In 80% of cases, that's all they need to solve their "internal documentation problem". To look at a concrete case, get in touch.

4. The daily shift: consuming becomes training

Here is the side effect that changes everything, and only surfaces after the first weeks of regular ingestion.

Before. A 45-minute YouTube video on an interesting topic. Two or three things learned. Three days later, 80% forgotten. Three weeks later, maybe one fuzzy sentence left. Consumption time evaporates. Passive consumption.

Today, the gesture is four steps:

  1. A piece of consumption: video, podcast, long-form article, whatever.
  2. Capture via Obsidian Web Clipper, in one click. Five seconds.
  3. Drop into raw/. No need to think about filing. The filename follows the schema convention, that's it.
  4. Run /ingest. The agent takes over: it reads, identifies which concepts get enriched (or need creating), updates entity pages (people cited, tools mentioned), drops one or two new ideas/ if the source defends a singular claim, and shows the changes for validation.

What changes is not the time spent: it's what is left behind. Each video becomes a permanent context block inside the AI. Three months later, on a complex question, the AI no longer answers with its general knowledge (the same as the competitor using the same API). It answers with the user's culture: their readings, past decisions, clients, angle, opinions updated at every ingestion.

The virtuous loop is immediate. The more you consume, the more useful the AI becomes. Intel-gathering stops being a guilty to-do list, it becomes a compounding asset. You filter better what you let in, too, because you know what comes in stays — really.

And there is an inverse compounding, more subtle, that only shows after a month or two: the AI spontaneously cross-references a video ingested today with an article dropped three months earlier and long forgotten. It surfaces the connection in a query response. The reaction is mechanical: "oh right, I had forgotten that". Those connections, nobody would make by hand.

The punchline fits in one line: before, we consumed and forgot. Now, we consume and the AI gets better. Same gesture, completely different ROI.

5. Why it beats RAG at SMB scale

Now the B2B angle, because that's where the majority of enterprise AI projects collapse.

When an SMB walks in with "we'd like to query our internal docs with an AI", the default reaction in today's market is: you need a RAG. Vector database, embeddings, chunking, reranker, ingestion pipeline, incremental updates. A quote that stings and a stack to maintain afterwards. Even more if it has to sit on AWS with clean MLOps.

Except that at the real scale of most SMBs (a few hundred internal documents, a few tens to hundreds of thousands of useful words), an AI-maintained wiki beats a RAG on three dimensions:

  • Cost. No vector stack to pay for, no embedding tuning, no orchestration pipeline. The marginal cost of an ingestion is a few context tokens.
  • Readability. When an executive wants to understand why the AI answered a given thing, they open the wiki and read the cited pages. No vectorial black box. It's traceable, debuggable, contestable.
  • Maintenance. The agent that ingests updates the base on the way. No cron job re-indexing, no drift between index and source. The wiki is always up to date because it's the mandatory pass-through for every new source.

Karpathy points it out: he runs this at 100 articles and 400,000 words. That's exactly the scale of a department's docs, a product team's, a legal team's in a mid-sized company. Most projects clients describe as "our internal RAG" fall well below those thresholds.

What this approach solves in a company is not what executives describe at first. The market's standard pitch, "the AI summarizes your documents", misses the real pain. The real pain is that every internal knowledge system already attempted died for the same reason: nobody keeps the maintenance up over time.

That parameter is exactly what the method flips:

The maintenance job that killed every internal wiki already attempted moves to an agent that doesn't burn out.

Once maintenance friction is removed, the internal base stays populated, current, queryable. Not because "AI was added on top", but because the cause that made teams quit after six months was removed.

Honesty on limits. Beyond about a thousand bulky documents, the index starts to degrade and index + drill reading gets slow: Karpathy himself switches to CLI search tools at that stage. If the corpus is very heterogeneous (scanned PDFs, dense tables, multimodal documents), preprocessing remains useful. If row-level multi-tenant permissions are needed, a flat markdown folder isn't enough. But 80% of B2B SMB cases fall below those thresholds. And cases that exceed them can start with a wiki in the meantime, without technical debt.

For an SMB that has been sold (or is about to sign) a substantial RAG project, thirty minutes before signing are worth it. Often it's an AI-maintained wiki that solves the real problem, for a fraction of the budget and with a time-to-value of days instead of weeks or months. Let's talk.

6. How to build one, concretely

What goes in:

  • Company documentation: team info, client files, deals in flight, contracts, internal processes, technical systems and stacks, meeting notes, sales debriefs, incident retrospectives.
  • Professional intel: articles, podcasts, papers, threads, videos in a given domain. The most immediate personal case.
  • Active projects: pitches, product ideas, R&D, user tests, experience reports.
  • Personal life: any topic where you make repeated decisions over time.
  • One-off projects: a market study, a due diligence, the follow-up of a training, the writing of a book.

What you need, really:

  • Obsidian (free).
  • Claude Code.
  • A git folder for versioning.
  • A CLAUDE.md or AGENTS.md file describing the schema.
  • A raw/ folder.

That's it. The setup command, to paste into an empty folder:

Help me set up a LLM wiki that fits my needs and workflows
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Operational tip, because that's the mistake 80% of starters make: don't try to file everything in advance. Don't sketch the tree of concepts on a whiteboard before starting. Drop five to ten sources into raw/: things already consumed recently, not an ideal "to-read list". Run /ingest on each. Let the agent propose a structure. The schema emerges from real sources, not the other way around. The wiki is an organic object that crystallizes as the raw feeds it. Pre-figuring the whole architecture means falling back into the Notion trap: a weekend filing empty folders, then abandoning three months later.

The gesture is small. You drop, you validate the changes, you read. You ask a question when you need to. The rest takes care of itself.

7. The tech was missing. It's here.

Today, there's an LLM agent that doesn't get bored, that edits fifteen files at once without forgetting a cross-reference, and that costs a few cents per session. The method fits in a file. The setup fits in a command. The format fits in plain text, readable in thirty years.

In 2026, a second brain is useless if the AI cannot read it. And conversely: the AI stays generic as long as it has no access to a proprietary context. The wiki is what reconciles the two.

For executives who want this pattern adapted to the reality of their company (a real manual-task replacement, not yet another AI gadget), a 30-minute call is enough to scope the case. Get in touch.

For the step-by-step walkthrough of the personal setup (Obsidian + Claude Code + the first CLAUDE.md + the first ingest), reach out. We can run the first session together.