Context is two jobs, not one

I’ve been learning ICM, the Interpretable Context Methodology, and sharing a bit about it here as I go. A few weeks ago Google’s Open Knowledge Format started showing up in my feed, and it looked close enough to what I was learning that I had an uncomfortable little thought: am I studying the thing that’s about to be replaced? Like that never happens these days!!

So I went and researched it. The short version is no, it isn’t a replacement. The longer version turned out to be more interesting than the question I started with.

They look like the same idea

On the surface they look nearly identical, and there’s a good reason for that.

ICM comes from Jake Van Clief, who published “Interpretable Context Methodology: Folder Structure as Agent Architecture” on arXiv in March of this year, open source under MIT. Its whole premise is that you don’t need an orchestration framework to run a multi-step AI workflow. You need numbered folders, plain markdown files, and a review gate between the steps.

The Open Knowledge Format came out of Google Cloud in June. Google describes it as “a format, not another service… vendor-neutral, agent- and human-friendly.” What it actually is: a directory of markdown files, each one holding a single concept, with a bit of YAML at the top and normal markdown links between them.

Folders. Markdown. No database, no SDK, no proprietary runtime. Both of them.

They even share a common ancestor. Both trace back to Andrej Karpathy’s idea of an “LLM wiki,” and Google quoted him directly in the launch post: “LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass. The bookkeeping that causes humans to abandon personal wikis is exactly what LLMs are good at.”

So yes, the resemblance is real. It’s the difference underneath that’s worth the read.

One is procedure, the other is knowledge

Here’s the split, and it took me longer than I’d like to admit to see it clearly.

ICM structures how the agent works. Numbered stages, one job per stage, a contract that tells the agent what it’s doing at this step, and a human checkpoint before the next one runs. It’s a procedure. It answers “how does this work move.”

OKF structures what the agent knows. One concept per file, its path is its identity, links between concepts turning the folder into a graph. It’s a knowledge base. It answers “what is true around here.”

Procedure and knowledge. Two different jobs.

That distinction landed for me because of something I’d already run into with ICM. The reason scoped stages work is that the agent isn’t handed everything at once. Each step loads only what that step needs. It’s not dragging a 40-message conversation behind it, or every reference file for the whole project, so it doesn’t drift. That’s the procedure half doing its job.

What that doesn’t solve is the quality and the shape of the knowledge you’re loading. You can scope a stage perfectly and still be feeding it a mess. OKF is aimed squarely at that other half: give the knowledge a consistent form so anything reading it, today’s tool or next year’s, knows what it’s looking at.

Most of us have been using “context” as one word for both of these. I certainly was. And I think that’s a real part of why AI output comes back inconsistent in ways that are hard to diagnose. When the results are off, “fix the context” isn’t one action. It’s two. Either the work isn’t scoped (the workflow half), or what you’re feeding it has no shape (no definition, no boundaries, no relationships).

Stacked, they get more interesting

The way I finally pictured it was with a small business, so here’s a bike shop.

Everything the shop knows lives in one file called everything-about-the-shop.txt. Tune-ups take 3 days in spring. Never quote repairs over the phone. The Trek rep is Dana. Warranty steps are photo first, then form. We sponsor the Tuesday ride. Winter hours differ. The suspension checklist is in there somewhere. It’s all true, and it’s all one wall of text, and the AI reads it as one wall of text.

Give that knowledge a shape and it becomes 4 files instead of 1. A shop file for who we are. A policy file for repair quotes. A runbook for warranty claims. A playbook for the spring rush. Each one says what type it is at the top, and each one links to the others. That’s the OKF half.

Now put a workflow over top. The stage that answers a customer inquiry loads the shop file and the repair policy. The stage that handles a warranty claim loads the warranty runbook and nothing else. The stage that plans the week loads the spring rush playbook. That’s the ICM half.

Neither half gets you there alone. Shaped knowledge with no workflow is a tidy library that nobody walks into. A scoped workflow over an unshaped pile is a well-organized way to hand the AI the same wall of text it was always going to choke on.

OKF shapes the knowledge · ICM scopes the work · Two jobs, working together.

The part I keep thinking about

Jake published in March. Google announced in June. About 3 months apart, and as far as anyone can tell, entirely independently.

His own reaction to the launch is the part I liked most. He posted the question his community was obviously going to ask, “Did Google steal my research?”, and answered it himself: “Personally. No I don’t think they did, I think the researchers are discovering what I did already! And I’m happy they are.”

That’s a good look at how to react when a very large company walks into your lane. It’s also, I think, the correct read of what happened. When a solo researcher and a Google Cloud team arrive at the same answer within a season of each other, the answer probably isn’t a preference. It’s more likely something both of them ran into because it was there.

And the answer was a folder full of markdown files. While the rest of us are comparing models, the interface that keeps winning is the plainest one available.

What I’d actually do with this

If you’re building anything with AI beyond a single chat, the useful move is to ask which of the two halves you’re missing. Most setups I’ve seen, including my own thinking before I looked into this, have some version of the procedure and almost nothing deliberate on the knowledge.

A few honest notes to hold alongside that. OKF is about 2 months old, and at launch every tool producing and consuming it was built by Google, so it’s an invitation more than an established standard right now. ICM’s results, meanwhile, are self-reported from a small practitioner group, which the paper itself says plainly. Neither of these is a settled thing you should bet a business on this quarter.

What they cost you to look at is nothing. Both are open. The arXiv paper is free to read, and the OKF spec is short enough to get through in a sitting. That’s a rare combination in this space, and it’s the reason I’d say go read them rather than take my summary for it.

Where I’ve landed, and honestly I got there partway through writing this: the interesting thing isn’t picking one. It’s stacking them. ICM is the layer I keep learning, since the work I care about is multi-step and I want a human in the middle of it. OKF is the one I want to understand better, because the knowledge half is the part I’ve been treating as an afterthought. Put a shaped knowledge base under a scoped workflow and I think that’s a genuinely strong setup, stronger than either piece is on its own.

Is anyone out there working with either of these? I’d genuinely like to hear from you, especially if you’ve tried the knowledge side in a real setup and can tell me whether it holds up.