Every AI employee we build reads from a second brain — the captured knowledge of how a business actually runs. We call ours the Business Brain. Before we could fill it, we had to answer a smaller, more stubborn question: what format do we write it in?
Two serious ideas were in the air. This isn’t a cage match, and I’m not here to declare a loser. Both are good. But we had to pick the layer we build on, and I want to show the reasoning, because the format you choose is the thing that either compounds for years or quietly rots.
The shared ancestor: Karpathy’s LLM Wiki
Both ideas trace back to the same source. Andrej Karpathy sketched it in a short but influential gist: instead of making an AI rediscover your knowledge from scratch on every question, compile it once into a persistent, evolving wiki of plain markdown files.
The cross-references are already there. The contradictions have already been flagged. You keep the raw sources, you keep an LLM-maintained wiki on top of them, and you keep a small schema document that says how the wiki is organized. His framing is the part that stuck with me: your sources are the data, the LLM is the programmer, and the wiki is the codebase it maintains.
That idea splits into two very different bets about what to standardize.
Idea one — ICM: the folders are the agent
The first bet comes from Jake Van Clief’s Interpretable Context Methodology, laid out in his ICM Architect project and a 2026 paper with David McDermott. The insight is that most of what people build multi-agent frameworks for is really just structure — so put the structure in the filesystem and let it carry the logic.
Numbered folders carry sequencing. Hierarchy carries context scoping. Markdown files carry the state. Small local scripts do the mechanical steps that don’t need a model. A single agent reads the right files at the right moment and moves through the work, and the folder layout itself becomes the program it runs. It borrows honestly from Unix pipelines and literate programming.
It’s elegant, and it’s aimed at a real target: how work moves. If you have a repeatable process with a human checking each step, ICM is a clean way to encode that process without writing orchestration code.
Idea two — OKF: trust lives in every file
The second bet is Google’s Open Knowledge Format. Same substrate — markdown files with YAML frontmatter — but it standardizes something different. OKF is vendor-neutral, git-native, and readable in the software people already use, like Obsidian or Notion. No SDK sits between a reader and the content.
Its real move is making trust a first-class, queryable part of every file. The frontmatter carries sources, a verified signal, a status, and a stale_after date. So a fact isn’t just written down — it arrives with its provenance and its expiration attached. OKF optimizes what a piece of knowledge is, and whether you should still believe it.
They’re not rivals — they stack
Here’s the thing I didn’t see at first. These two aren’t competing for the same slot. One builds on the other.
OKF is the substrate: what each file is, and whether to trust it. ICM-style structure is a layer that sits on top: how an agent routes through those files to get work done. You can hold perfectly good OKF files inside an ICM-shaped workspace, and the format never fights the structure. Knowledge and process are different problems, and each idea is the better answer to one of them.
So the question was never “which one wins.” It was “which one is the foundation, and which one rides on top.” For a second brain, the foundation is the knowledge itself.
Why OKF is the foundation we built on
A second brain is a durable asset, not a workflow. It has to stay true over months while an AI employee reads from it every single day. And the way a knowledge base dies is rarely dramatic. It’s not bad structure. It’s silent rot: one fact goes stale, nothing flags it, and the AI keeps citing it with total confidence.
OKF fights that directly, because freshness and provenance live in the file. Trust is something you can query, not something you assume. Because it’s format-not-platform and git-native, the whole brain is reviewable like code — every change has a diff, an author, and a history. That fits how we already think. If it isn’t in the Business Brain, it didn’t happen to the AI, so the Business Brain has to be the most trustworthy thing we own. We wrote more about that scoped role in being born AI-native.
Packaging and distribution — the part that decided it
There’s one more reason, and for a boutique shop like ours it might be the biggest.
We don’t build second brains for ourselves. We build AI employees for clients, and the knowledge we capture belongs to them. An OKF brain is a self-contained, portable bundle — a git repository, a single archive, a folder you can mount anywhere. It’s vendor-neutral, with no SDK and no proprietary layer wrapped around it.
That means we can package a client’s operating knowledge and hand it over as an asset they actually own and can open in their own software. “You own everything we build” stops being a promise and becomes a file you can walk away with. A durable second brain that travels between our systems and theirs, with no platform holding it hostage. For a small shop, that portability is leverage: we deliver an asset, not a dependency on our stack. And when a client’s work needs process on top of that knowledge, ICM-style structure rides along just fine.
The layer that compounds
Pick the wrong format and you spend years fighting it. Pick the right one and everything you write settles into an asset that gets more valuable over time.
Both of these ideas earned their place. We built the foundation on the one that keeps knowledge trustworthy as it ages and travels as something a client owns. The structure can always go on top. The trust has to go all the way down.