The Open Knowledge Format, Explained — And What It Quietly Does to Your Moat

Google published a tiny spec that lets AI agents read your company’s knowledge without any special software. It’s clever, it’s boringly simple — and if you’re not careful, it quietly erases a moat you didn’t know you had.

In June 2026, Google Cloud published something that fits on a single page and asks for almost nothing in return. No SDK. No account. No new database. It’s called the Open Knowledge Format, or OKF, and the whole idea is that a folder of plain text files can become the shared language every AI agent uses to understand a company.

That sounds unremarkable until you sit with what it removes. So let me start with a kitchen.

The problem OKF is actually solving

Every organisation’s real knowledge is scattered. The definition of “active customer” lives in one analyst’s head. The rule that you must join the orders table on customer_id and never email is buried in a Slack thread from 2023. The runbook for a failed payment sits in a Confluence page nobody has opened in months.

For years this was a human problem. Now it’s an agent problem. When you ask an AI agent “how do we compute weekly active users from our event stream?”, it has to reassemble that answer from a dozen incompatible places — a metadata catalog with its own API here, a wiki there, a code comment somewhere else. Google’s own framing is blunt about this: as the models themselves get better, the thing holding agents back is no longer intelligence — it’s missing context.

Every vendor’s answer so far has been “use our catalog, with our SDK.” Which means none of that knowledge is portable. You can’t hand your knowledge base to a partner. You can’t merge two teams’ knowledge. You can’t switch tools without re-doing everything.

OKF’s bet is that the fix isn’t a smarter platform. It’s a shared format — a lingua franca — that everyone can speak.

What OKF actually is (in plain terms)

Strip away the announcement language and OKF is three sentences:

A concept

One idea = one plain text (markdown) file. A table, a metric, an API, a playbook — each gets its own recipe card.

A bundle

A folder of those cards. This is the unit you share — as a zip file, a Git repo, or a mounted folder.

Frontmatter

A tiny label at the top of each card (a few tagged fields like type, title, tags) so both a human and a machine can sort it at a glance.

Here’s one card. Notice you can read it with zero training — that’s the entire point:

Only one field is ever required: type. Everything else is optional. Cards link to each other with ordinary text links, which quietly turns your folder into a graph — a map of how everything connects. That relationship layer is the part a plain document scrape throws away, and it’s where a lot of the real value hides.

Why “boringly simple” is the feature, not a bug

The instinct is to look at OKF and think this is too basic to matter. That reaction is the giveaway. As practitioners keep pointing out, the complexity in knowledge systems was never in representing the knowledge — it was in the integration. Every proprietary catalog was a custom integration you had to build and maintain.

A plain format deletes that tax. Anyone can produce OKF without an SDK. Anyone can consume it without an integration. It renders on GitHub, ships as a zip, and opens in any text editor. If you can cat a file, you can read it. If you can clone a repo, you can ship it.

Three things people confuse OKF with

And a naming trap worth flagging: this “OKF” is not the Open Knowledge Foundation, the older open-data non-profit. Same initials, unrelated.

One honest limitation: v0.1 standardises the container, not the vocabulary. It makes every team’s knowledge easy to find and read. It does not yet guarantee two teams mean the same thing by “active user.” That semantic layer is what later versions are for. Today, OKF is a shared way to store context — not yet a shared way to make sense of it.

How it works end-to-end: an HR department, worked through

Google’s own examples are all database tables, which is fine for data teams but abstract for everyone else. So let me use a case every organisation recognises: an HR department with a pile of policy documents — a leave policy, a work-from-home policy, a code of conduct, benefits docs — some of which keep changing. Here’s the whole lifecycle: how the bundle gets built, how it stays current, and how an answer comes back out.

What the bundle looks like

The entire HR knowledge base becomes one folder. Each policy is one card. Related policies are grouped into sub-folders. Two special filenames do quiet but important work: index.md is a table of contents at each level, and log.md is a timestamped change history.

And here’s a single card — the WFH policy. The frontmatter is the queryable label; the body is the actual policy. The two [links] at the bottom are what turn a lone file into a node in a graph:

Building it, keeping it current, and getting answers out

The lifecycle has three phases. The first is a one-time setup; the other two repeat forever.

1. Create (once). Something reads the existing policy PDFs and drafts a card for each. That “something” can be an LLM agent, a simple script, or a person — OKF doesn’t require an LLM; the format is just files. An agent is simply the fastest way to draft dozens of cards at once. Then — and this is the non-negotiable step — HR reviews the drafts and fixes the tribal knowledge the documents never captured (“the probation carve-out doesn’t apply to rehires”). The review is what makes the bundle authoritative.
2. Update (on every change). When the WFH policy goes from 2 days to 3, you don’t rebuild anything. You re-draft the one card whose source changed. Because it’s a plain file in Git, the change shows up as a clean before/after diff HR can approve in seconds, and log.md records when it happened. You get an audit trail for free — no separate compliance tooling.
3. Retrieve (on every question). An employee asks the assistant “how many WFH days do I get?” The assistant matches the question to a card by its tags, opens policies/wfh.md — the approved, current card — and answers. If the question is compound (“can I combine WFH with parental leave?”), it follows the link to the leave card and assembles both. No stale PDF, no fuzzy guess.

Notice how the update loop and the retrieval loop reinforce each other: fresh card in, correct answer out. That’s the difference between this and pointing a plain document-search tool at a folder of PDFs, which might confidently surface last year’s policy because it scored high on similarity.

One clarification worth making, because it’s the most common misconception: matching a question to a card can be fully deterministic. Once you know the intent is “remote policy,” a plain filter — type == HR Policy AND tags contains wfh — finds the card with no AI at all. An LLM earns its place only in interpreting the messy human question (“what’s our deal on working from home?”) into the right tag. The strongest designs use the LLM to pick the tag, then a deterministic lookup to fetch the card — which also makes the answer auditable (“we returned wfh.md because the query tagged as wfh“), not a black box. In an HR compliance context, that auditability is a feature, not a nicety.

What does one query actually cost?

Trace “how many WFH days do I get?” through the machine and you get one or two model calls, not more. An optional interpret step turns the messy question into the tag wfh — its prompt is small because it only sees the tag list or the index, never the card bodies. Then the card is fetched by path, which costs zero tokens and no model call — it’s just opening a file. Finally a generate step loads that one card (a few hundred tokens for a policy) into the prompt and writes the answer. Skip the interpret step with deterministic matching and you’re down to a single model call: fetch, then generate.

The headline, and the reason this scales, is what doesn’t change:

What does move the numbers is worth knowing, because most of it is a curation choice rather than a platform limit:

Against RAG, the natural benchmark, this usually comes out ahead per query. RAG pays an embedding cost on every question and then loads several fuzzy chunks into the prompt; OKF, matched deterministically, skips the query-time embedding and loads one clean card. Fewer tokens, one fewer moving part. The trade is honest: OKF asks for the upfront authoring investment that RAG doesn’t. (Treat all of this as order-of-magnitude, not a benchmark — the exact numbers depend on your cards, your model, and how chatty your prompts are. The durable point is the shape: one-to-two calls, dominated by the generate step, flat with bundle size.)

And notice where the efficiency actually comes from — the same place everything in this piece comes from. Tight cards and a graph that doesn’t force needless hops keep every answer cheap; bloated, over-linked bundles make every answer expensive. The format hands you a cheap-lookup mechanism. Disciplined authoring is what keeps it cheap in practice.

What if one policy has several documents?

Common in HR: a leave policy might be a policy PDF, an FAQ, a manager’s approval guide, and a regional addendum. The key reframe is that OKF cards are one per concept, not one per document — a single card’s body can absorb several source files. So the question isn’t “how many documents?” but “how many distinct concepts?”

There’s a quieter fourth option: a card doesn’t have to contain the document. The resource frontmatter field can point to an external file — so a card can hold the agent-readable summary while resource: links to the legally binding PDF that stays the system of record. Useful when you don’t want to fork copyrighted or regulated text.

And here’s the part that matters for how you run this: a creation agent can propose the structure, but a human should ratify it. The agent is genuinely good at reading everything and suggesting “merge these three, split that one” — and for a large migration you want it doing that first pass. But where one concept ends and another begins is a judgment about governance and real usage that lives outside the documents: the agent can’t know the EU addendum needs its own separately-audited card, or that your managers always read entitlement and approval together. The agent proposes; the human disposes. Fully automating that boundary decision means automating away the single highest-leverage judgment in the whole bundle.

My POV: can an OKF bundle become intellectual property? Yes — and that’s exactly the trap.

This is the question I keep getting from leadership, so let me be direct about where I land.

The format is deliberately worthless as IP — by design. Google made OKF open, vendor-neutral, and Apache-licensed precisely so that ownership wouldn’t matter. Their own line is that the value comes from how many parties speak it, not from who owns it. So nobody is going to build a moat out of the binder. The binder is free forever, on purpose.

Which pushes the entire question onto the cards. And here’s the uncomfortable part for a lot of businesses:

So yes, an OKF bundle can absolutely be IP — the way a company’s actual recipes are IP. Your curated metric definitions, your hard-won join paths, your incident playbooks written from real 3 a.m. outages: that’s genuine, defensible, valuable knowledge. A rival can copy the binder in an afternoon. They cannot copy fifteen years of “here’s the one weird rule about how refunds hit the revenue table.”

But — and this is the cautionary edge — a portable format makes that IP dramatically easier to walk out the door. When your crown-jewel knowledge is a folder of plain text files that any agent can read and any person can zip up, your protection is no longer technical friction. It has to become the things that were always the real moat:

1. Contracts and governance, not file formats. Access control, licensing terms, and clear ownership matter more the instant your knowledge is trivially copyable. The format won’t protect you; your legal and access boundaries will.
2. The freshness, not the file. A bundle is a snapshot. The moat is the living process that keeps it accurate — the pipeline and the people constantly correcting it. A stolen snapshot is stale within weeks; the update engine is what’s hard to steal.
3. Depth of curation. Anyone can produce a bundle. Few can produce one where every metric is battle-tested, every caveat is earned, and every join path reflects real production scars. That editorial depth — the thing you can’t generate on day one — is the durable asset.

The strategic move, then, isn’t to resist OKF because it commoditizes the plumbing. The plumbing was never your advantage; you just told yourself it was. The move is to separate cleanly: adopt the open format everywhere to kill integration cost, and pour your protection into the layers a format can’t touch — the quality of the knowledge, the speed of its upkeep, and the legal walls around it.

Google gave away the recipe binder. That’s a gift. Just don’t confuse owning the binder with owning the recipes — and don’t assume the recipes are safe just because the drawer used to be hard to open.