Win Agent-Readiness by Making Your Knowledge a Format, Not a Platform
In June 2026, Google Cloud published a specification for feeding AI trustworthy internal knowledge, and the surprising part is how small it is. The Open Knowledge Format is markdown plus YAML frontmatter. One mandatory field: type. Two reserved filenames: index.md and log.md. The full v0.1 spec fits on one page.
That smallness is the whole argument. A knowledge contract a single engineer can read in five minutes is a contract a company can actually carry between tools. The instinct is the same one that produced CLAUDE.md and every other agent-context file teams have been hand-rolling for two years. Google Cloud took the pattern and standardized it. The governance question that follows is not “should we document our knowledge for agents.” It is “do we own that knowledge as a format we can move, or as a platform we are stuck inside.”
What the format actually specifies
OKF v0.1 is deliberately thin. A document is a markdown file. The frontmatter carries metadata, and the body carries prose, tables, and links the way any human-readable document would. The single required field, type, declares what the document describes: a dataset, a metric, a process, an entity. Everything else is optional and extensible.
The reserved files do the structural work. index.md is the entry point for a knowledge collection, the file an agent reads first to understand what exists. log.md is the change record, the running history of how the knowledge evolved. That is the entire skeleton. No proprietary schema server, no database, no SDK you have to adopt before you can write your first document.
Google Cloud shipped tooling around it, and the tooling is worth reading as a statement of intent. An Enrichment Agent drafts OKF documents directly over BigQuery, so the format can be bootstrapped from data you already have instead of authored from scratch. A no-backend HTML visualizer renders the knowledge collection as a graph you open in a browser with no server running. Sample bundles ship in the repo at GoogleCloudPlatform/knowledge-catalog. The visualizer needing no backend is the tell: the knowledge is files, and files render anywhere.
Why a format beats a platform for agent-readiness
Andrej Karpathy, quoted in the post, made the case for why this matters now: “LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass.” That is the property that makes a markdown knowledge layer suddenly practical. The historical objection to documentation-as-files was maintenance. Cross-references rot, definitions drift, nobody updates the index. An agent removes that objection. It can rewrite the whole collection in one pass and keep log.md honest while it does.
So the constraint that used to push companies toward heavyweight knowledge platforms, the cost of keeping documentation current, is dissolving. What remains is the architecture decision. You can encode your institutional knowledge as a format you control, or as state inside a vendor’s catalog product. A format travels. The same OKF bundle feeds a Google agent today, a different vendor’s agent next quarter, and your own internal tooling without a migration project. A platform makes that same move a data-export ticket, a schema-mapping exercise, and a renegotiation.
This is the same structural logic we traced in Enterprise MCP Just Crossed the Engineering Line: the durable value sits in the layer that is portable across vendors, not the layer that is locked to one. MCP made the connection layer portable. OKF aims the same instinct at the knowledge layer underneath it. An agent is only as trustworthy as the knowledge it reads, and the knowledge is only as durable as the format it lives in.
The lock-in decision OKF forces
A standard published by a hyperscaler invites a fair suspicion: open format, proprietary gravity. The honest reading is that the format itself is genuinely portable, markdown is markdown, and the lock-in risk migrates to the tooling. The Enrichment Agent runs over BigQuery. The convenient path enriches your knowledge from Google’s warehouse using Google’s agent, and convenience is how platforms acquire gravity even when the file format is open.
The governance posture that wins is to treat the format as the asset and the tooling as replaceable. Own the OKF bundle in your own repository. Version it with your code. Let any vendor’s agent read it, and refuse to let any single agent become the only thing that can write it. The format gives you that option for free because the spec fits on a page. Throwing the option away is a choice, usually made by default, when a team lets the most convenient enrichment pipeline become the only one that touches the knowledge.
There is a related cost worth naming, the one we called the agent integration tax. Every agent a company adopts needs to understand the same internal reality: what a customer is, how a deal is structured, which metric means what. Without a shared knowledge layer, each agent relearns that reality through bespoke integration, and you pay the tax per agent. A portable format pays it once. The knowledge is written down in a form every agent can read, and onboarding a new agent becomes pointing it at the bundle rather than rebuilding the context.
The maintenance claim deserves a caveat
The case for files rests on the premise that agents keep them current. That premise is strong and unproven at scale. An agent that can touch 15 files in one pass can also propagate an error across 15 files in one pass. log.md records what changed; it does not validate that the change was correct. A knowledge layer maintained by agents needs the same review discipline as code maintained by agents: a human or a second agent checking that the rewrite preserved truth, and a way to roll back when it did not.
That is not an argument against the format. It is an argument for treating the knowledge bundle as a governed artifact with the same controls you put on a code repository: version history, review on change, and an owner who is accountable for what the agents read. The format makes those controls cheap to apply, because it is already plain files in a repo. A platform often hides the change history behind a UI you cannot diff.
Do this now
Pick one domain where your agents already need internal context, a metric definition, a customer schema, a core process. Write it as a small OKF bundle: an index.md, a handful of typed documents, a log.md. Put it in a git repository you own, not in a vendor catalog. Point one existing agent at it and confirm the agent answers better with the bundle than without it. Then make the rule explicit before the convenient pipeline makes it for you: the knowledge layer is a format the company carries between tools, and no single vendor’s agent is the only thing allowed to write it.
The company that wins agent-readiness this year is not the one with the most agents. It is the one whose agents read from a knowledge layer it can pick up and move.
This analysis synthesizes How the Open Knowledge Format can improve data sharing (Google Cloud, June 2026).
Victorino Group helps teams build a portable knowledge layer their agents can read and their vendors cannot trap. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation