OKF v0.1: Google formalizes the pattern teams were already using informally
On June 12, 2026, Google quietly published a new open specification called the Open Knowledge Format — a standardized way for AI agents to consume organizational knowledge as folders of markdown files instead of scraping wikis, calling proprietary APIs, or wrestling with fragile embedding pipelines (Google Cloud Blog, "How the Open Knowledge Format can improve data sharing", 2026).
Every team building internal AI agents knows the problem. Your knowledge lives in Confluence, Notion, SharePoint, or a dozen custom surfaces — and whatever format you chose last year doesn't talk to your agent framework this year. OKF is Google's answer: one vendor-neutral spec, no runtime required, readable by any model or agent without a dedicated SDK.
That part is real and worth your attention. But we reviewed the spec, the examples, and every published piece covering the launch — and there's a significant gap between what OKF promises and what it currently delivers. Here's what that gap costs.
TL;DR
- Google published OKF v0.1 on June 12, 2026 — a format that represents organizational knowledge as a directory of markdown files with YAML frontmatter, interlinked like a wiki.
- Only one field is required (
type); no SDK, no runtime, no API keys needed to read it. Genuinely elegant. - Zero published benchmarks exist showing OKF improves agent accuracy, reduces hallucinations, or cuts retrieval latency vs. raw docs.
- No major vendor (Anthropic, OpenAI, Groq, LiteLLM) has publicly committed to OKF support — it's vendor-neutral in spec, Google-only in practice right now.
- Migration from Confluence/Notion requires schema mapping, content parsing, and relationship re-linking. Worth piloting only if you're already rebuilding knowledge infrastructure.
What OKF Actually Is
OKF is a directory of markdown files. That's the whole thing.
Each "concept" — a table, a metric, a runbook, an API — gets its own .md file with a small block of YAML frontmatter at the top. Files link to each other using normal markdown syntax, so the directory forms a graph of relationships that both humans and agents can traverse (OpenKnowledgeFormat.com, "OKF Examples, Validator & Templates", 2026).
The only required YAML field is type. Everything else — title, description, resource, tags, timestamp, and custom extension keys — is optional (Flowtivity, "The Markdown Standard That Could Replace Your Wiki", 2026). A minimal OKF concept looks like:
---type: tabletitle: Ordersdescription: Transactional records for customer purchases. Join to customers on customer_id.resource: /tables/orders.mdtags: [finance, transactions]---The orders table contains one row per transaction...The unit of distribution is a bundle: a folder, repo, archive, or subdirectory. You can host it on GitHub, zip it, or include it as a subdirectory in your existing monorepo. Reading it requires no database, no runtime, no API keys — just a file system (Nohacks.co, "Google's Open Knowledge Format Could Work For…", 2026).
This matters because the alternative is ugly. Teams today build DIY pipelines: custom Confluence API scrapers, Notion export parsers, brittle text-chunking code that breaks every time the source wiki changes structure. OKF says: formalize this once, and any agent that understands the spec can read it.
As Amir Hormati, one of the spec authors, put it: "It's a format, not a platform: just markdown files, and YAML, with no dependency on any cloud, model, agent framework or catalog" (LinkedIn, Amir Hormati, 2026).
That's the pitch. And it's a good pitch.
Traditional wiki lock-in vs. OKF's portable bundle structure
Why Google Shipped It Now
The timing is strategic, not altruistic.
Google is rebuilding its entire product stack around AI agents. Vertex AI, BigQuery, and a range of internal tools are all moving toward agentic workflows. For that to work, agents need structured context — and right now every enterprise org assembles that context differently, in incompatible formats.
OKF solves that directly. Google published the spec alongside three example datasets and a tool that auto-generates OKF files from BigQuery schemas (Shashi.co, "Google Publishes a Plain-Text Format for Feeding AI Agents…", 2026). That's not a coincidence. If you're already on Google Cloud, OKF slots neatly into the stack you're already using.
The spec is also genuinely vendor-neutral at the format level. Anyone can write or read OKF bundles without paying Google a dime or running on Google infrastructure. OKF v0.1 describes itself as "representing knowledge as a directory of markdown files with YAML frontmatter" — a pattern that predates Google's announcement by years (Google Cloud Blog, "How the Open Knowledge Format can improve data sharing", 2026).
So the honest read: OKF formalizes an already-emerging pattern (the "LLM wiki"), puts a Google logo on it, and ships tooling that makes it easy to adopt if you're already in the Google ecosystem. None of that makes it bad. But it does mean "vendor-neutral" describes the format, not the momentum — and that distinction matters when you're deciding whether to migrate.
The Adoption Problem: What's Missing
This is where every other piece covering OKF stops short. Here's what nobody's measuring.
No empirical performance data. Across all 8+ sources covering the OKF launch — Google's own blog, Flowtivity, Nohacks.co, Shashi.co, DataChaz on X, Reddit discussions, and independent LinkedIn and blog coverage — not one measures agent accuracy, retrieval latency, or hallucination rates using OKF-structured knowledge vs. any baseline. Not one. The first question any engineering team should ask before migrating is "does this actually make my agent better?" Right now the answer is "we don't know."
No vendor ecosystem. Google describes OKF as vendor-neutral. But as of June 2026, no major vendor has publicly committed to OKF support — not Anthropic, not OpenAI, not Groq, not LiteLLM, not OpenRouter. The spec is open; the ecosystem isn't. Adopting a standard that only one vendor is actively pushing creates a different kind of lock-in than the one you're trying to escape.
No governance model. OKF v0.1 is explicitly "a starting point, not a finished standard" (Nohacks.co, "Google's Open Knowledge Format Could Work For…", 2026). Who decides what goes into v0.2? Who owns the extension key namespace? If your team adds custom fields that conflict with fields another tool expects, who arbitrates? There's no standards body, no RFC process, no public roadmap. The spec lives with Google's team.
No security or compliance guidance. OKF bundles are plain markdown files. That's elegant for readability, and a headache for regulated industries. How do you handle PII in a concept file? PHI in a healthcare runbook? The spec is silent. Orgs in healthcare, finance, and government will build incompatible solutions to a problem the spec doesn't address.
No migration tooling. Converting an existing knowledge base — say, 5,000 Confluence pages — to OKF requires three distinct phases: schema mapping (defining your type taxonomy), content parsing (extracting and converting existing docs), and relationship re-linking (expressing cross-doc dependencies in markdown link format). No vendor has published a tool to do this at scale.
The underlying question isn't "Is OKF a good idea?" It's "Can we afford to migrate, and will it actually matter?"
What This Means for Your Team
Here's a practical decision tree.
Pilot OKF now if: You're already rebuilding knowledge infrastructure — migrating off Confluence, designing an internal LLM chatbot from scratch, or rearchitecting how your data catalog feeds agents. OKF adds low incremental cost to work you're already doing. Start with 50–200 concepts in a single bundle, measure retrieval latency and agent answer accuracy before and after, and share what you find. You'll be among the first.
Wait if: Your current knowledge system is working. OKF doesn't exist in isolation; agent frameworks and ingestion tooling haven't caught up to the spec. v0.1 is early enough that a major field could still change in v0.2. Migrating now and discovering that a key metadata field changed in three months is a bad day.
Adopt when: Multiple vendors announce OKF support. Published case studies with latency and accuracy metrics appear. At least one open-source migration tool exists. That's the signal the ecosystem has caught up to the format.
Skip entirely if: You're in a regulated industry without clarity on PII/PHI handling, or your agents already perform well on existing knowledge sources. There's no advantage in migrating a working system to an unproven format.
The practical ask for teams that do pilot: run the same agent query against OKF-structured data and your current format. Count hallucinations. Measure latency. Get a number. That data doesn't exist publicly yet, and whoever publishes it first will have something genuinely useful to say.
The OKF adoption maturity curve: what to wait for before committing
The Contrarian Case: Why OKF Might Fail
The contrarian case is this: "open" formats led by a single vendor have a poor track record unless governance is independent — and OKF has no independent governance yet.
The phrase "Open Knowledge Format" isn't new. The Open Knowledge Foundation has used "open knowledge" as an umbrella concept since the early 2010s, defining it as knowledge anyone can freely access, use, modify, and share. Their work on open data standards, licensing, and governance ran into exactly the hard problems that OKF v0.1 sidesteps: semantic consistency across organizations, version control, access control, compliance, and governance of who decides what's in the spec (Open Knowledge Foundation materials, via research.md, 2010s–present).
OKF's technical underpinnings are equally non-novel. Markdown plus YAML frontmatter plus linked files is the stack behind static site generators, developer documentation tools, and personal knowledge management apps like Obsidian. OKF formalizes a pattern teams were already using ad hoc — it didn't invent it. As one independent technical blog put it: "Google just formalized the 'LLM Wiki'" (X.com, DataChaz, 2026).
None of that makes OKF bad. Standardization of existing patterns is valuable. But it raises a genuine question: if this pattern is so obvious that dozens of teams were doing it already, why will an open spec succeed where informal practice didn't achieve interoperability?
The historical answer from comparable standardization efforts: it succeeds when there's a governance structure that prevents fragmentation, and when the incentives align for vendors to support one version rather than extend it differently. OKF has neither yet.
Adopt cautiously. Design bundles to be portable and format-agnostic. Don't treat OKF as a long-term architectural bet until governance clarity arrives.
What to Watch (and When)
The next six months will tell you whether OKF has real legs.
Green flags — signals the ecosystem is catching up:
- At least one non-Google vendor (Anthropic, OpenAI, Groq, LiteLLM, or a data catalog) announces native OKF support
- Published case studies with measured latency, accuracy, or hallucination data appear
- Open-source migration tooling emerges (Confluence → OKF, Notion → OKF)
- OKF governance moves to a neutral standards body or a public RFC process
Red flags — signals to stay cautious:
- Silence from major vendors by end of Q3 2026
- Google stops publishing spec updates or example datasets
- First real adoption stories reveal migration complexity far higher than expected
- Independent teams extend
typeconventions in incompatible directions
Check back in Q4 2026. By then, the ecosystem signal will be clear. If vendors have committed, case studies exist, and tooling is available, that's the moment to migrate. If the flags are still red, you've saved your team months of premature migration work.
When you're ready to run the empirical comparisons — same agent, OKF knowledge vs. raw docs, measure accuracy and latency — Mesh API's compare endpoint gives you a single integration to run that test across every major model. We're tracking which teams adopt OKF and what they find. Let us know.
FAQ
Is OKF the same as schema.org or JSON-LD?
No. Schema.org and JSON-LD define semantic types for search engines and general web markup, working in the RDF ecosystem. OKF defines content structure for agents using plain markdown and YAML — simpler and more human-readable, but less flexible for complex knowledge graph use cases. They address different problems for different consumers.
How do I migrate from Confluence or Notion to OKF?
There's no official migration tool yet. The process has three steps: (1) Schema mapping — define your type taxonomy (tables, runbooks, APIs, metrics, etc.) before touching any content. (2) Content parsing — export pages and strip formatting, mapping each page's title/description/tags to OKF frontmatter fields. (3) Relationship re-linking — convert internal wiki links to relative markdown links so agents can traverse the graph. For a 5,000-artifact org, expect 2–4 weeks of engineering work. Pilot with one bounded scope (a single team's runbooks) before committing to a full migration.
Can I use OKF alongside my existing Notion or Confluence setup?
Yes, but not without effort. You'd need to either export and convert existing docs or maintain both systems in parallel — which creates update friction. The most realistic path: pilot OKF for a bounded scope (e.g., engineering runbooks for one team), keep existing wiki infrastructure for everything else, and use an API gateway or agent middleware to query both sources and assemble context per request.
Who should NOT adopt OKF yet?
Teams in regulated industries (healthcare, finance, legal) without clarity on PII and PHI handling. Teams whose agents already perform well on existing knowledge sources — don't fix what isn't broken. Small organizations without DevOps support for DIY tooling — the spec exists, but migration tooling doesn't, and manual conversion at scale is expensive. Any team where your primary agent framework hasn't announced OKF support.
Will OKF replace existing documentation formats?
Probably not entirely. OKF is optimized for agent consumption, and humans still prefer wiki-style editing environments (Notion, Confluence, GitHub Pages). The likely outcome: OKF becomes a backend representation — versioned, linked, agent-readable — with existing front-end tools consuming it as an output format rather than as the primary authoring surface. That layering adds abstraction overhead, which is a real cost.
What Google Got Right, and What Comes Next
OKF solves a real problem. Every team building AI agents has DIY parsing code they wish they didn't have to maintain. A vendor-neutral, dependency-free format that formalizes the "LLM wiki" pattern is genuinely useful — if the ecosystem adopts it.
The current state: elegant spec, no empirical validation, no vendor ecosystem, no governance model, no migration tooling. Google shipped a format-level answer to a problem that requires ecosystem-level buy-in to solve.
If you're piloting: measure agent performance before and after. Latency, accuracy, hallucination rate. The field needs that data. If you're waiting: watch the Q3 2026 signals. If you're already doing this informally with markdown knowledge bases: OKF legitimizes the approach. Standardizing your existing bundles on the spec now — before fragmentation sets in — is the pragmatic move.
The spec itself won't tell you whether to migrate. The case studies that don't exist yet will.