{"id":97823,"date":"2026-06-16T18:05:17","date_gmt":"2026-06-16T18:05:17","guid":{"rendered":"https:\/\/youzum.net\/google-cloud-introduces-open-knowledge-format-okf-a-vendor-neutral-markdown-spec-for-giving-ai-agents-curated-context\/"},"modified":"2026-06-16T18:05:17","modified_gmt":"2026-06-16T18:05:17","slug":"google-cloud-introduces-open-knowledge-format-okf-a-vendor-neutral-markdown-spec-for-giving-ai-agents-curated-context","status":"publish","type":"post","link":"https:\/\/youzum.net\/zh\/google-cloud-introduces-open-knowledge-format-okf-a-vendor-neutral-markdown-spec-for-giving-ai-agents-curated-context\/","title":{"rendered":"Google Cloud Introduces Open Knowledge Format (OKF): A Vendor-Neutral Markdown Spec for Giving AI Agents Curated Context"},"content":{"rendered":"

Foundation models keep getting stronger, yet they still stall on the same thing: context. A model can write code or analyze a dataset, but only with the right internal knowledge. That knowledge includes table schemas, metric definitions, runbooks, join paths and it lives scattered across catalogs, wikis, and a few senior engineers\u2019 heads.<\/p>\n

Google Cloud introduced the Open Knowledge Format (OKF)<\/strong>, an open specification that formalizes the LLM-wiki pattern into a portable, interoperable format. It is a vendor-neutral, agent- and human-friendly standard for the context modern AI systems need.<\/p>\n

Open Knowledge Format (OKF)<\/strong><\/h2>\n

OKF is a format, not a service or a platform. OKF v0.1<\/strong> represents knowledge as a directory of markdown files with YAML frontmatter. A small set of agreed-upon conventions lets wikis written by one producer be consumed by a different agent without translation.<\/p>\n

That is the whole idea. There is no compression scheme, no new runtime, and no required SDK. A bundle of OKF documents is just markdown, just files, and just YAML frontmatter. It renders on GitHub, ships as a tarball, and mounts on any filesystem.<\/p>\n

If you have used Obsidian, Notion, or Hugo, the shape will feel familiar. OKF only formalizes the conventions needed to make those patterns interoperable.<\/p>\n

<\/p>\n

\n

The Fragmented Context Problem<\/strong><\/h2>\n<\/p>

In most organizations, model context is overwhelmingly internal knowledge. Today it sits in incompatible silos: metadata catalogs with their own APIs, wikis, shared drives, code comments, and docstrings.<\/p>\n

Ask an agent \u2018How do I compute weekly active users from our event stream?\u2019 It must assemble that answer from scattered, mutually incompatible surfaces. Every vendor offers its own catalog, SDK, and knowledge-graph schema. None of the knowledge is portable across products or organizations.<\/p>\n

The result is duplicated effort. Every agent builder solves the same context-assembly problem from scratch. Every catalog vendor reinvents the same data models.<\/p>\n

Andrej Karpathy articulated the underlying idea in his April 2026 LLM Wiki gist<\/a>. His point: LLMs do not get bored, do not forget to update cross-references, and can edit many files in one pass. The bookkeeping that makes humans abandon personal wikis is exactly what LLMs handle well.<\/p>\n

The same pattern keeps reappearing under different names. Examples include Obsidian vaults wired to coding agents, the AGENTS.md and CLAUDE.md convention files, and \u2018metadata as code\u2019 repos. Each instance is bespoke, so none of them interoperate. OKF standardizes that interoperability layer so agents can do the heavy lifting.<\/p>\n

How OKF Works: The Design in One Screen<\/strong><\/h2>\n

An OKF bundle<\/strong> is a directory of markdown files representing concepts<\/strong> \u2014 tables, datasets, metrics, playbooks, runbooks, or APIs. Each concept is one file, and the file path is its identity.<\/p>\n

\n
\n
\n
\n
<\/div>\n
<\/div>\n
<\/div>\n<\/div>\n
Copy Code<\/span>Copied<\/span>Use a different Browser<\/span><\/a><\/div>\n<\/div>\n
sales\/\n\u251c\u2500\u2500 index.md\n\u251c\u2500\u2500 datasets\/\n\u2502   \u251c\u2500\u2500 index.md\n\u2502   \u2514\u2500\u2500 orders_db.md\n\u251c\u2500\u2500 tables\/\n\u2502   \u251c\u2500\u2500 index.md\n\u2502   \u251c\u2500\u2500 orders.md\n\u2502   \u2514\u2500\u2500 customers.md\n\u2514\u2500\u2500 metrics\/\n    \u251c\u2500\u2500 index.md\n    \u2514\u2500\u2500 weekly_active_users.md<\/code><\/pre>\n<\/div>\n<\/div>\n
Each concept carries a small YAML front-matter block, then a markdown body for everything else.<\/p>\n
\n
\n
\n
\n
<\/div>\n
<\/div>\n
<\/div>\n<\/div>\n
Copy Code<\/span>Copied<\/span>Use a different Browser<\/span><\/a><\/div>\n<\/div>\n
---\ntype: BigQuery Table\ntitle: Orders\ndescription: One row per completed customer order.\nresource: https:\/\/console.cloud.google.com\/bigquery?p=acme&d=sales&t=orders\ntags: [sales, revenue]\ntimestamp: 2026-05-28T14:30:00Z\n---\n\n# Schema\n\n| Column        | Type   | Description                              |\n|---------------|--------|------------------------------------------|\n| `order_id`    | STRING | Globally unique order identifier.        |\n| `customer_id` | STRING | FK to [customers](\/tables\/customers.md). |<\/code><\/pre>\n<\/div>\n<\/div>\n
The reserved structured fields are type<\/code>, title<\/code>, description<\/code>, resource<\/code>, tags<\/code>, and timestamp<\/code>. Concepts link to each other with normal markdown links. Those links turn the directory into a graph that is richer than file-system parent\/child relationships. Bundles can optionally include index.md<\/code> files for progressive disclosure and log.md<\/code> files for change history.<\/p>\n
Three Principles Behind the Design<\/strong><\/h2>\n