Every company has the same disease, and most don't know they're sick until someone quits.
The answer to "how do we actually do X" lives in three places: one person's head, a Slack thread from last March, and a Google Doc somebody started and abandoned. A new hire shows up, asks the question, and gets three different answers from three people. Multiply that by every process you run, and you've got a business that can't remember itself.
The usual fix is a company wiki. You buy Notion or Confluence, you make a beautiful page tree, and within six weeks it's a graveyard. Wikis rot because keeping them current is unpaid, unglamorous work that lands on whoever cares least about being blamed for the doc being wrong.
What changed in 2026 is that you can hand that unpaid job to an AI. Not "search your docs with a chatbot." Actually hand the AI a folder and let it write, structure, and cross-link the whole thing while you sleep. That's the idea behind Andrej Karpathy's LLM Wiki, and it scales down to a solo founder and up to a real team. I run my entire operation on it. Here's the version for businesses.
Get my weekly AI breakdowns — no fluff, no sequences, just useful.
Karpathy's one-sentence reframe
In April 2026 Karpathy posted a gist describing how he runs his personal knowledge base. The tweet hit 17 million views in a few days and the gist picked up 4,000+ forks. The line that stuck with everyone:
"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
Sit with that for a second, because it quietly kills the way most teams think about knowledge. You are not the author of the company wiki anymore. You are the editor. You drop raw material in, and the AI does the writing, the summarizing, and the linking. Karpathy's own wiki is roughly 100 articles and 400,000 words, and he says he wrote almost none of it.
If you've read the full step-by-step method, you know the mechanics. This post is about pointing that machine at a business instead of a person.
The three folders, applied to a company
The pattern is three layers and one schema file. For a company it maps cleanly onto how knowledge actually moves through a team:
company-brain/
├── raw/ # immutable sources the AI reads, never edits
│ ├── slack-exports/ # the threads where decisions actually happened
│ ├── call-transcripts/
│ ├── sops/ # whatever procedures you already wrote
│ └── contracts/
├── wiki/ # AI-owned, the part people actually read
│ ├── index.md # the catalog. AI reads this first, every query.
│ ├── log.md # append-only history of what got ingested
│ ├── processes/ # how we onboard, how we invoice, how we ship
│ ├── people/ # who owns what, who knows what
│ └── decisions/ # why we chose X over Y, so nobody re-litigates it
└── CLAUDE.md # the schema: how the AI runs this wiki
The raw/ folder is the move most teams miss. You don't summarize the messy Slack thread yourself. You export it, drop it in raw/, and the AI reads it, extracts the decision, files a clean page in wiki/decisions/, and links it to the people and processes it touches. The thread stays untouched as the source of truth. The wiki page is the readable version.
CLAUDE.md is the only file you hand-write, and it's short. It tells the AI the rules: read index.md first, never edit anything in raw/, append to log.md after every ingest, flag contradictions instead of silently overwriting. That last rule matters more in a company than a personal vault, because in a business two "sources of truth" that disagree is a real problem you want surfaced, not smoothed over.
What this looks like when it's actually running
I'll stop talking in the abstract, because I run this.
My business operates as a team of five AI employees: a content strategist, a full-stack engineer, a proposal writer, a workspace manager, and a meta-employee that hires and manages the others. They don't share a person's memory. They share a folder. The "company brain" is real files: company/voice.md holds the house writing style, company/boss.md holds the facts about me every employee should act on, and shared/memory/ holds the cross-team knowledge with an INDEX.md that gets read at the start of every session.
Here's the part that sold me. Last week one of my agents pulled an analytics report and learned that a specific blog post was the one driving signups. That fact didn't stay in that agent's head and die when the session ended. It got written to shared/memory/ with a one-line pointer in the index. The next morning, a different agent, doing a different job, opened the index, saw the note, and made a content decision based on it. No standup. No handoff doc. No "hey did you see the thing." The knowledge propagated because the brain is a place, not a person.
That's the whole pitch for a company. Knowledge stops being something you transfer and starts being something the team stands on.
Why not just buy a RAG chatbot
Because for a company knowledge base under a few thousand pages, RAG is the wrong tool and a worse bill.
RAG (the "chat with your docs" approach most vendors sell) chops your documents into chunks, turns each chunk into a vector, stores those in a vector database, and on every question goes fishing for the chunks that look relevant. It works, sort of, but you're paying for it three ways. There's an embedding API bill. There's a vector database to host, which runs $70 to $500 a month for a managed Pinecone or Weaviate at moderate scale. And there's the maintenance every time your documents change.
The wiki pattern reads a roughly 2,000-token index.md and pulls one to three targeted pages. One model call. The token comparison runs 50 to 200 times fewer input tokens per query than naive RAG, and it holds up against optimized RAG on the kind of workload a small company actually has. Infrastructure cost: a folder on disk, versioned with Git, which you already have. Zero dollars a month.
There's a reliability angle too that I care about more than the cost. RAG is stateless. It re-derives an answer from scattered chunks every single time, and chunking breaks things that should stay together, like a process that spans five steps. The wiki did the hard thinking once, at write time, and stored the structured result. The cross-references are real links, not a similarity score that hoped for the best.
I'll say the contrarian part plainly: if your company knowledge base is under a couple thousand pages, a vector database is overkill and you should not buy one. Spend the $300 a month on something that grows the business instead.
The proof this works on business material
You don't have to take my workforce as the only example. A community member ran the experiment on pure business content: three business books, about 155,000 words of source material, fed into the pattern. The AI generated 210 concept pages and 4,600 cross-references between them, unprompted. Nobody sat there linking "pricing strategy" to "customer retention." The machine saw the relationship and wired it.
That's the part that doesn't fit in a spreadsheet. A human-built wiki has the links somebody had time to make. An AI-built wiki has the links that actually exist in the material.
A few honest gotchas
This is not magic and I'm not going to pretend it is.
It does not scale to millions of documents. The "read the index, then targeted pages" trick works up to hundreds of pages, into the low thousands if your index is disciplined. If you're a 2,000-person company trying to index a decade of everything, you've outgrown this and you do want real retrieval infrastructure. Karpathy's own Farzapedia example tops out around 400 articles, and that's the right neighborhood.
You give up sub-second query speed. The AI reads files, which takes a few seconds, versus a vector DB's near-instant lookup. For a knowledge base your team reads a few dozen times a day, nobody notices. For a customer-facing search box serving thousands of queries a minute, it matters.
And someone has to own the CLAUDE.md and glance at the log.md once a week. The AI maintains the content, but the schema and the discipline are still a human job. The wiki rots slower than a Notion page, not never.
The honest version of the cost claim, while I'm here: the "70x cheaper" and "95% cheaper" numbers floating around are illustrative, from Karpathy's own framing, not rigorously benchmarked. The defensible number is the 50-to-200x fewer input tokens per query, which is sourced and holds.
Where to start this week
Pick one process that's currently trapped in someone's head. Onboarding is the usual best first target, because the pain is sharp and the material already exists in scattered form. Make the three folders. Export the relevant Slack threads and docs into raw/. Write a ten-line CLAUDE.md. Point Claude Code at it and tell it to build the index.md and the first few pages.
You'll have a working company brain for one process by Friday. Then you point it at the next one.
If you want the other end of this idea, the personal version for your own life and notes, I wrote that up too: Build a Second Brain for Your Life. Same pattern, different owner.
And if "a team of five AI employees that share a brain" made you sit up: that's not a metaphor, it's how I run the business. A company brain is just one piece of it.
The bigger thing is this: the people and companies pulling ahead this year aren't the ones with the most AI apps. They're the ones who actually understand how this works, and who keep up as it changes (which is constantly). That's what we do inside the community. There's a full curriculum that stays current with where AI is now, not where it was last year, and a room full of people building real things and comparing notes. If you want to get genuinely good at this instead of collecting tricks from blog posts, that's where to do it.