How I Built a Compounding Knowledge Base in a Morning

Andrej Karpathy (Ex Tesla & OpenAI) recently posted a deceptively simple idea: stop saving articles into folders. Start compiling them into a plain text wiki that any AI agent can read and write to. Lex Fridman replied saying he does something similar, building mini knowledge bases he loads into voice mode on runs.

I read the tweet, closed the tab, and built the whole thing before lunch. Nine sources processed. Eight synthesised concept articles. Four of my own frameworks cross-referenced. Here's what I learned, and why I think this pattern matters more than most people realise.

The Problem with How We Store Knowledge

Most of us have the same setup. A Notion database, an internet browser tool or maybe a Google Drive folder. You save an article. It sits in a list alongside hundreds of others. Your collection grows, but it never compounds. Ten articles about AI adoption sit in ten separate rows. They never talk to each other.

This is the difference between a library and a wiki. A library stores entries. A wiki synthesises them.

What I Actually Built

The system lives in a single folder on my Mac (~/llm-wiki/), operated entirely through Claude Code.

Here's the structure:

• CLAUDE.md at the root acts as the operating manual. It tells the agent the schema, the compilation rules, the conventions.

• index.md is the agent's map of everything in the wiki. Tables of contents, maturity ratings, a compilation log.

• raw/ holds one file per processed source. These are immutable after creation. Full 9-section analyses: key arguments, evidence, tensions, connections.

• wiki/concepts/ is where the magic happens. These are evolving encyclopaedia-style articles that get richer every time I process a new source.

• wiki/frameworks/ holds my own IP. The agent can flag connections to these but never edits them directly.

The processing loop is simple. I say "process this article" and paste the content. The agent analyses it, creates the raw summary, then scans the existing wiki and weaves new evidence into every relevant concept article. It creates new articles if warranted, flags framework connections for me to review, and updates the index.

That last part is what makes it compound. Source #1 creates a concept article on AI Productivity. Source #2 adds a counterpoint about cognitive load. Source #3 provides data that validates #1 but challenges #2. By Source #8, the concept article is a nuanced synthesis that no single source could have produced.

The Query That Sold It

I'd been testing the system for a few minutes when I asked: "What's the strongest counterargument to the claim that AI makes everyone more productive?"

Instead of getting one article's take, I got a multi-source answer. BCG's cognitive load research on the oversight burden. Anthropic's fluency data showing the critical evaluation gap. An article referencing consulting lessons about the implementation gap between pilot and production. An article where an argument about taste as the bottleneck was debated. All woven together, with citations, contradictions flagged, and connections to two of my own frameworks.

That's when I knew this wasn't a filing system. It was a thinking tool.

"Why Not Just Use NotebookLM?"

Fair question. Google's NotebookLM is excellent for quick research. Upload ten PDFs, ask questions, get answers with source grounding. The audio overview feature is genuinely useful. For a one-off project you won't maintain, it's faster to get started with.

But NotebookLM synthesises on the fly, every time. Your tenth query gets the same quality answer as your first. A compiled wiki did the synthesis once during processing, and each new source makes it richer. Your tenth query is better than your first. That's the compounding difference.

There are other gaps. NotebookLM treats all sources equally. My wiki has a frameworks layer that connects my original thinking to external research. When I ask about AI productivity, the answer naturally references my own frameworks alongside BCG data. NotebookLM can't privilege your IP that way. And it's a closed Google product. You can't pipe its outputs into your newsletter workflow, your Notion databases, or another AI agent.

They're complementary. Use NotebookLM for quick, disposable research. Use the wiki for persistent knowledge that compounds and feeds your actual work.

One reason the wiki works as a persistent system: it's flat markdown. No proprietary formats. No API calls to retrieve your own data. Just text files any agent can read and write to directly. Claude Code today, but portable to anything that can read a directory.

How to Build Your Own

You don't need this exact setup. The pattern is what matters.

Start with one folder and two files. A CLAUDE.md (or equivalent instructions file) that defines your schema and rules. An index.md that maps the contents. That's your foundation.

Process your first five sources. Pick articles you've already read and found valuable. Paste them in, let the agent create raw summaries and initial concept articles. You'll see connections emerge by source three.

Set the compilation rule. This is the key design decision: new sources enrich existing articles rather than creating new entries. Tell your agent to weave evidence into existing narrative, not append changelog-style updates. The difference between a growing wiki and a growing filing cabinet is this single rule.

Add your own frameworks. If you have original thinking, mental models, or frameworks you use in your work, give them their own section. Mark them as author-edited only. The agent should connect sources to your thinking, not rewrite it.

Query before you write. Before drafting a newsletter, a client email, or a presentation, query the wiki first. The synthesised articles are pre-research.

One tip: Start with fewer, better sources rather than your entire reading backlog. Five or six on a topic you actively think about. Let the concept articles develop depth before going wide.

What Are the Limitations?

Someone in the replies to Karpathy's post raised a fair point. When an LLM synthesises sources into concept articles, it introduces interpretation. Stats get rounded. Nuances get flattened. A causal claim gets presented stronger than the original intended. Over many compilations, small mischaracterisations can compound alongside the knowledge.

For an engineering team maintaining API docs, this is a dealbreaker. Different wiki, different rules.

For strategic knowledge, consulting frameworks, newsletter prep, the risk is manageable. My system keeps raw source files immutable, concept articles cite back to specific sources, and every processing run reports exactly what changed. If a claim feels off, I can trace it in thirty seconds.

I'd still recommend building in a health check. Karpathy mentions "linting", running periodic integrity passes. A monthly prompt like "cross-reference claims against their cited raw sources, flag mismatches" takes ten minutes and keeps the system honest.

Don't skip this. The compounding effect works both ways. Good synthesis compounds into richer understanding. Unchecked errors compound into confident misinformation.

The Compounding Effect

The real value is day thirty, when you've processed forty sources and your concept articles are richer than anything you could have written from memory. It's the moment you query your wiki and it connects two ideas you'd never have linked on your own.

Knowledge management has always been a graveyard of good intentions. Bookmarks you never revisit. Highlights that gather dust. The compiled wiki pattern works because the AI does the synthesis work you were never going to do manually. You keep feeding it. It keeps compounding.

The Atomic Builder is written by Faisal Shariff, Human Productivity Lead at Tomoro AI. Views are my own.