Beyond the Format: The Operational Layer OKF Leaves Out
The hard part of an AI knowledge base isn't writing it down: it's keeping it true.
A format is a snapshot. Knowledge is a process.
In June 2026, Google Cloud published the Open Knowledge Format (OKF): a small, open, vendor-neutral spec (Apache-2.0, no runtime, no SDK) for writing organizational knowledge as plain Markdown with light YAML frontmatter, readable directly by AI agents. It formalizes a pattern already taking shape: Andrej Karpathy's "LLM wiki" idea, built out by a small community through spring 2026, now with a name and a contract.
Every "just put your knowledge in OKF" walkthrough quietly assumes writing it down is the hard part. It isn't: the hard part is everything after the first commit.
The day you finish authoring your OKF bundle, it starts to rot. A price changes, a runbook goes stale, a decision contradicts an old one, and nobody updates the file. Weeks later, your knowledge base is confidently feeding your agents things that are no longer true.
OKF gives your knowledge a body. This piece is about what it leaves out: the metabolism.
What OKF is and isn't
The gap is by design, so it's worth being precise.
OKF specifies a format: a directory of Markdown concept files, one required frontmatter field (type), a few optional ones (title, description, resource, tags, timestamp), two reserved files (index.md, log.md), and plain Markdown links wiring it into a graph. That's it: minimal by design, easy to adopt, impossible to get locked into.
But a format can't tell you:
- How new knowledge gets in.
- How it's classified and where it belongs.
- How it gets linked to everything related.
- How scattered notes become a synthesized page.
- How you know a claim is still true, or where it came from.
- What happens when two files contradict each other.
- Who does all of this, forever, without getting bored.
A format describes knowledge at rest, not the lifecycle that produces and maintains it. Call that lifecycle the operational layer: where every real knowledge base lives or dies.
The operational layer, primitive by primitive
You don't need to see our code to grasp the shape of the problem: here are the primitives a living OKF base needs, the map, not the recipe.
1. Capture. If adding knowledge takes effort, it won't happen. You need a zero-friction drop point (a URL, a voice memo, a pasted thread) that the system, not you, turns into a concept file, or the base goes stale at the source.
2. Classification. A captured fragment has to become a typed concept in the right place. OKF's type field is mandatory; the spec doesn't say how to assign it. That judgment, "this is a decision, tag it, file it under Operations," is what LLMs are for.
3. Cross-linking. OKF's graph is built from links; no edges, just a pile. A knowledge base beats plain search because the connections already exist before you ask, and maintaining them at scale is relentless: perfect for a machine, miserable for a person.
4. Synthesis. Raw notes aren't answers. Karpathy's key move is persistent compilation: an LLM reads many sources, writes one coherent page, and rewrites it as sources change, the step most "just use OKF" advice skips.
5. Provenance. A claim you can't trace, you can't trust; an agent that can't cite sources isn't one you'll deploy anywhere that matters. Every statement should link back to its source: not decoration, the load-bearing wall, because…
6. Semantic maintenance. …it's what lets the base catch its own decay. Structural checks (broken links, missing fields) are table stakes; the real work is semantic: two files that contradict each other, a claim a newer source has superseded, a concept mentioned everywhere but documented nowhere, a topic with thin coverage. The immune system, and a format has no opinion about it.
7. Scheduling. This separates a demo from a system. Every primitive above can be run by a human "when they get to it." They won't: Karpathy's insight is that LLMs don't get bored. Capture, linking, synthesis, and maintenance must run unattended, on schedule, with nobody in the loop, or the base is already dead and just doesn't know it yet.
8. Reversibility. Anything that changes files automatically has to be safe: every change committed to version control, every run reversible, every mutation reviewable. Automation without an undo button is how you wake up to a base that rewrote itself wrong.
Eight primitives. OKF specifies the artifacts that one of them produces. The other seven are wide open, which is exactly why they're worth owning.
Why "just export to OKF" isn't enough
The tempting shortcut is to treat OKF as a finish line: run a script, dump your docs into compliant files, declare victory. That gets you a snapshot, and snapshots rot.
It's also a different bet than retrieval-augmented generation (RAG), which rediscovers everything on every query, from scratch, with no memory of reasoning about it before. Different, not opposed: retrieval still earns its keep on corpora too big or too fresh to compile, and the two pair well in practice. But for the knowledge a business leans on every day, the LLM-wiki bet OKF encodes is the opposite trade: compile once, compound forever. Cross-references already there, contradictions already flagged, synthesis already done while you slept.
That only pays off if something is doing the compiling, continuously. A static OKF bundle has the body of a compounding knowledge base and none of the metabolism: identical on day one, drifting from reality every day after.
The format is necessary. It's nowhere near sufficient.
Standing on shoulders (and saying so)
None of these primitives are mine. Karpathy articulated the LLM-wiki concept; a community worked out the conventions (index files, append-only logs, source/concept separation, citation discipline, review gates) months before any of it carried a Google logo. OKF turned those conventions into a portable, vendor-neutral contract.
Our claim is narrower: we've been running the full operational layer, scheduled and unattended, since before the standard existed. Building the format is a weekend's work; building the metabolism, trusting it to rewrite your knowledge while you sleep, takes real engineering. That's the part most OKF adoption stories skip, and the part that decides whether your agents work from the truth.
The takeaway
If you're adopting OKF, go in with eyes open:
- The format is the easy 20%. The operational layer is the 80% that decides whether it works.
- A knowledge base isn't a document you write; it's a system you run.
- Automate the boring, relentless maintenance, or accept that your base will quietly drift out of date and take your agents' credibility with it.
- Keep humans where humans are good (curating, asking, deciding), and machines where machines are good (the bookkeeping nobody sustains).
OKF gave organizational knowledge a standard, portable body. The work worth doing, the work worth hiring for, is giving it a metabolism.