Was ist das Open Knowledge Format (OKF)? Googles Markdown-Standard für KI-Agenten

Am 12. Juni 2026 veröffentlichte das Datenteam von Google Cloud das Open Knowledge Format (OKF), eine offene Spezifikation, um einen Wissensbestand als Verzeichnis von Markdown-Dateien darzustellen. Kein neues Produkt, kein SaaS, kein SDK: und genau das macht es interessant. In einer Zeit, in der jeder Anbieter versucht, dich in seine Plattform einzusperren, veröffentlicht Google ein Format, das niemandem gehört: Markdown, Dateien, Punkt.

Dieser Artikel erklärt, was OKF ist, wie es strukturiert ist, warum es genau zum richtigen Zeitpunkt für KI-Agenten kommt, und was es von einem Knowledge Graph oder einem Werkzeug wie NotebookLM unterscheidet.

Das Problem, das OKF lösen will

Wenn ein KI-Agent eine Geschäftsfrage beantworten soll («berechne die wöchentlich aktiven Nutzer»), setzt er seine Antwort aus fragmentierten Quellen zusammen: ein Metadatenkatalog hier, ein Wiki dort, Kommentare im Code, eine Metrikdefinition in einer Tabelle. Jeder Agent erfindet diese Sammelarbeit neu, und jede Organisation strukturiert sie anders.

OKF formalisiert ein bereits entstehendes Schema, das Google das «LLM-Wiki»-Muster nennt: eine kuratierte Wissensbibliothek, einmal geschrieben, die jeder Agent konsultieren kann. Die zentrale Idee ist, Produzent und Konsument sauber zu trennen: Wer das Wissen schreibt, muss nicht wissen, wer es lesen wird, und umgekehrt (Google Cloud Blog, How the Open Knowledge Format can improve data sharing).

Die Struktur: nur Dateien, nur Markdown

Ein OKF-Bundle ist ein Verzeichnis von Markdown-Dateien, nach Konzept organisiert. Ein Konzept ist alles, was du erfassen willst: eine Tabelle, ein Datensatz, eine Metrik, ein Runbook, eine API, eine Romanfigur. Die Grundregel: Der Dateipfad ist die Identität des Konzepts.

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

Daraus folgen drei Eigenschaften, und das ist alles, was OKF ausmacht:

Nur Markdown: lesbar in jedem Editor, gerendert auf GitHub, indexierbar von jedem Suchwerkzeug.
Nur Dateien: lieferbar als Tarball, hostbar in einem git-Repository, einhängbar in ein Dateisystem.
Nur YAML-Frontmatter: für die wenigen strukturierten Felder, die man abfragen können will.

Keine exotische Kompression, keine Runtime, keine Datenbank. Wenn du eine .md-Datei schreiben kannst, kannst du OKF produzieren.

Das Frontmatter: ein einziges Pflichtfeld

Jedes Konzeptdokument trägt ein YAML-Frontmatter am Kopf. Und hier trifft OKF eine radikale Entscheidung zur Einfachheit: ein einziges Feld ist erforderlich:

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

type: das einzige Pflichtfeld. Es beschreibt die Natur des Konzepts (Tabelle, Metrik, Charakter, Endpoint…). Es ist das, was einem Agenten ermöglicht, zu wissen, was er liest, ohne zu raten.
title, description, resource, tags, timestamp: optionale Standardfelder. resource zeigt auf die echte Ressource (URL), timestamp datiert die letzte Aktualisierung in ISO 8601.

Über diese Felder hinaus definieren die Produzenten ihre eigenen. Die Spezifikation diktiert weder die verfügbaren Typen noch das Inhaltsmodell noch die Abschnitte des Rumpfs. Sie ist, in Googles Worten, «minimal meinungsstark».

Die Querverweise: ein Graph mit gewöhnlichen Markdown-Links

Das ist das Element, das einen Ordner voller Dateien in eine Wissensbasis verwandelt. Die Konzepte verknüpfen sich untereinander mit einfachen Markdown-Links:

| `customer_id` | STRING | Fremdschlüssel auf [customers](/tables/customers.md). |

Verbunden mit [customers](/tables/customers.md) über `customer_id`.

Das Ergebnis ist ein Beziehungsgraph, reicher als die einfache Eltern/Kind-Hierarchie des Dateisystems. Ein Agent, der orders.md liest, entdeckt, indem er dem Link folgt, dass es eine customers-Tabelle gibt und wie sie sich verbinden, ohne dass es ihm im Prompt erklärt werden musste.

Die reservierten Dateien: `index.md` und `log.md`

Die Spezifikation reserviert zwei Dateinamen, beide optional:

index.md: ermöglicht eine progressive Offenlegung. Während ein Agent die Hierarchie hinabsteigt, gibt ihm die index.md jedes Ordners einen Überblick, bevor er in die einzelnen Konzepte eintaucht.
log.md: eine chronologische Historie der an den Konzepten vorgenommenen Änderungen.

Die vollständige Spezifikation, Konformitätskriterien, Querverweisregeln und reservierte Namen eingeschlossen, passt auf eine einzige Seite (offizielle Spezifikation, GoogleCloudPlatform/knowledge-catalog).

«Format, not platform»

Das ist das Leitprinzip, und es lohnt sich, dabei zu verweilen. Google betont: OKF ist vendor-neutral. Kein proprietäres Konto, keine aufgezwungene Cloud, kein erforderliches SDK. Ein OKF-Bundle:

übersteht den Umzug zwischen Systemen, Organisationen und Werkzeugen;
versioniert sich mit git, neben dem Code, den es beschreibt;
ist lesbar für Menschen und Maschinen in derselben Datei, ohne Übersetzungsschicht.

Google liefert außerdem Referenzimplementierungen, um das Ökosystem anzustoßen: einen Enrichment Agent, der BigQuery-Datenbanken durchläuft, um LLM-angereichertes OKF zu generieren, einen statischen HTML-Viewer (eine einzige eigenständige Datei, ohne Backend), der ein Bundle als navigierbare Website rendert, und Beispiel-Bundles (GA4 E-Commerce, Stack Overflow, Bitcoin).

OKF, Knowledge Graph, NotebookLM: drei verschiedene Dinge

Die Verwechslung ist häufig. Entwirren wir sie.

OKF vs Knowledge Graph

Ein Knowledge Graph ist ein abstraktes Datenmodell: Entitäten und Beziehungen, oft in einer Graphdatenbank gespeichert (RDF-Tripel, Eigenschaften usw.). OKF ist ein konkretes Dateiformat, das Beziehungen über Markdown-Links ausdrücken kann. Das eine ist eine Theorie der Daten, das andere eine Art, sie auf die Platte zu schreiben. Man kann einen Teil eines Knowledge Graph in OKF serialisieren, aber es sind nicht dieselben Objekte.

OKF vs NotebookLM (oder jede andere Anwendung)

NotebookLM ist eine Anwendung: Du lädst Dokumente hoch, stellst Fragen in seiner Oberfläche, und alles bleibt bei Google. OKF ist ein Format: Es definiert, wie man Dateien strukturiert, damit jedes Werkzeug sie lesen kann.

Diese beiden Dinge sind orthogonal. Du kannst ein OKF-Bundle problemlos in NotebookLM ablegen. Aber du kannst es auch Claude geben, GPT, einem selbstgebauten Agenten, einem Python-Skript, ohne in einer Plattform eingesperrt zu sein. Die eigentliche Frage ist: Willst du eine interaktive Frage-Antwort-Sitzung (eine Anwendung macht das gut), oder eine portable und programmatische Wissensbasis, die Agenten durchlaufen können, die du mit git versionierst, und die neben deinem Code oder deinen Texten lebt? OKF beantwortet die zweite.

Der richtige Moment, das richtige Maß an Ambition

OKF kommt genau dort an, wo der Bedarf spürbar ist: KI-Agenten überall, und nirgends eine einfache Möglichkeit, ihnen kuratierten Kontext zu geben. Google hat sich entschieden, früh und leicht zu veröffentlichen, eine einseitige Spezifikation statt eines dreijährigen Normungsausschusses, und das ist eine gute Nachricht. Das Format ist bereits heute nutzbar und darauf ausgelegt, sauber zu wachsen:

Der type-Katalog, standardmäßig frei, lässt jede Domäne ihr Vokabular erfinden, bevor sich die nützlichsten Konventionen von selbst durchsetzen.
Die Interoperabilität ist das zentrale Versprechen: ein Wiki, von einem geschrieben, von einem anderen ohne Übersetzer konsumiert. Genau das macht ein nacktes Dateiformat möglich.
Die Versionierung der Spezifikation ist von Anfang an darauf ausgelegt, abwärtskompatibel zu bleiben.

Kurz gesagt

OKF = ein Verzeichnis von Markdown-Dateien + YAML-Frontmatter, von Google Cloud am 12. Juni 2026 veröffentlicht, um KI-Agenten kuratierten Kontext zu geben.
Ein einziges Pflichtfeld: type. Der Rest (title, description, resource, tags, timestamp) ist optional; die Produzenten fügen ihre eigenen Felder hinzu.
Die Konzepte verknüpfen sich über einfache Markdown-Links und bilden einen Graphen. Optionale reservierte Dateien: index.md, log.md.
Format, keine Plattform: kein SDK, versionierbar in git, lesbar für Menschen und Maschinen.
Verschieden von einem Knowledge Graph (abstraktes Modell) und von einer Anwendung wie NotebookLM (Plattform): Es ist ein von einem Werkzeug zum anderen portables Format.

OKF verschiebt die Frage von «welches Werkzeug konsumiert mein Wissen?» hin zu «ist mein Wissen in einem Format geschrieben, das jedes Werkzeug lesen kann?». Und da dieses Format nichts anderes ist als aufgeräumtes Markdown, kann jeder Markdown-Editor, wie Draft_, bereits dazu dienen, es zu produzieren.