Open Knowledge Format: Googles Markdown-Spec für Agenten

Am 12. Juni 2026 veröffentlichte Google Cloud eine Spezifikation dafür, wie KI-Agenten kuratiertes Wissen lesen und austauschen sollen. Sie würden vielleicht eine Graphdatenbank erwarten, eine Schema-Registry, ein SDK und einen Dienst, der das Ganze betreibt.

Stattdessen ist das Open Knowledge Format genau das: ein Verzeichnis mit Markdown-Dateien und YAML-Frontmatter.

Das ist das ganze Format. Und genau diese Zurückhaltung ist der interessante Teil.

Die Spec ist kleiner, als man denkt

Die meisten Artikel über OKF fassen bloß die Ankündigung zusammen. Es lohnt sich, die Spec selbst zu lesen, weil ihr Umfang erstaunlich klein ist.

OKF v0.1 verlangt genau ein Feld in jedem Concept-Dokument:

---
type: BigQuery Table
---

Das war’s. type ist ein kurzer String, der angibt, welche Art von Concept das Dokument beschreibt, und dient dem Routing und Filtern. Werte werden nicht zentral registriert — es gibt kein Komitee, das die Liste gültiger Typen absegnet. Producer wählen selbsterklärende Bezeichnungen und machen weiter.

Fünf weitere Felder sind empfohlen, keines davon verpflichtend:

Field	Purpose
title	Anzeigename. Consumer können ihn bei Fehlen aus dem Dateinamen ableiten.
description	Ein-Satz-Zusammenfassung.
resource	Eine URI, die die zugrunde liegende Ressource eindeutig identifiziert.
tags	Eine YAML-Liste zur übergreifenden Kategorisierung.
timestamp	ISO-8601-Zeitstempel der letzten Änderung.

Producer dürfen beliebige eigene Keys hinzufügen. Consumer müssen unbekannte Felder erhalten, statt sie abzulehnen.

Ein vollständiges, konformes Concept-Dokument sieht so aus:

---
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, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique identifier |

Wenn Sie schon einmal eine Notiz in Obsidian mit Frontmatter geschrieben haben, haben Sie damit etwas geschrieben, das einem gültigen OKF-Concept sehr nahekommt.

Der Knowledge Graph ohne Graphdatenbank

Hier ist die Design-Entscheidung, die sich zu übernehmen lohnt — unabhängig davon, ob Sie OKF selbst einsetzen.

Beziehungen zwischen Concepts werden als normale Markdown-Links ausgedrückt. Keine Kanten in einer Datenbank. Kein relationships:-Block im Frontmatter. Einfach Links:

Each order references a [customer](/tables/customers.md).

Bundle-relative absolute Pfade (die mit / beginnen) werden für mehr Stabilität empfohlen; gewöhnliche relative Pfade wie ./other.md funktionieren ebenfalls.

Und dann kommt der Teil, der das Ganze zum Laufen bringt: die Art der Beziehung steckt im umgebenden Fließtext, nicht im Link selbst. „Each order references a customer” ist das Kanten-Label. Es gibt keine Ontologie zu pflegen, kein Prädikat-Vokabular, auf das man sich einigen müsste — denn die natürliche Sprache hat längst eines, und der Consumer ist ein Sprachmodell.

Ein Jahrzehnt an Knowledge-Graph-Tooling floss in die Formalisierung von Beziehungstypen, damit Maschinen sie interpretieren können. OKFs Wette: Das ist nicht mehr nötig — die Maschine liest heute einfach Englisch.

Zwei reservierte Dateinamen

Nur zwei Dateinamen haben innerhalb eines Bundles eine besondere Bedeutung:

• index.md — ein Verzeichnis-Listing, das Progressive Disclosure ermöglicht. Es trägt kein Frontmatter. Ein Agent liest zuerst den Index und folgt nur den Links, die er tatsächlich braucht, statt jedes Concept in den Kontext zu laden.
• log.md — eine chronologische Änderungshistorie mit ISO-8601-Datumsüberschriften, neueste zuerst.

Jede andere .md-Datei ist ein Concept-Dokument. Ein Bundle sieht am Ende wie ein ganz normaler, durchsuchbarer Ordner aus:

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

index.md ist die Datei, deren Bedeutung man leicht unterschätzt. Dahinter steckt derselbe Instinkt wie bei einer gut geschriebenen CLAUDE.md: die Library nicht komplett ins Context Window kippen, sondern dem Agenten ein Inhaltsverzeichnis geben und ihn selbst holen lassen, was er braucht.

Was OKF nicht ist

Es ist kein RAG. RAG leitet Wissen zur Query-Zeit neu her, indem es rohe Chunks abruft und hofft, dass die relevanten davon obenauf landen. Ein OKF-Bundle speichert kuratierte, quervernetzte Concepts, die ein Agent direkt liest und aktualisiert. Die Kuration passiert einmal, bewusst — statt bei jeder Anfrage neu approximiert zu werden.

Es ist nicht AGENTS.md oder CLAUDE.md. Das sind Instruktionsdateien — sie sagen einem Agent, wie er sich in einem Repository verhalten soll. OKF beschreibt fachliches Wissen: was diese Tabelle bedeutet, wie diese Metrik definiert ist, warum dieser Datensatz im März eine Lücke hat. Andere Aufgabe, komplementär.

Es ist nicht MCP. MCP ist ein Laufzeitprotokoll, um einen Agent mit Live-Systemen zu verbinden. OKF ist ein Dateiformat, das ruhend auf der Festplatte liegt. Realistischerweise nutzt man beides zusammen: MCP, um ans Warehouse zu kommen, OKF, um zu erklären, was drinsteckt.

Die Konformitätsregeln sind bewusst nachsichtig

Ein Bundle ist konform zu OKF v0.1, wenn jede nicht-reservierte .md-Datei parsebares YAML-Frontmatter hat, jeder Frontmatter-Block ein nicht-leeres type besitzt und die reservierten Dateien, sofern vorhanden, ihrer Struktur folgen.

Aufschlussreicher ist, was die Spec Consumern verbietet. Ein Consumer darf ein Bundle nicht ablehnen wegen fehlender optionaler Felder, unbekannter type-Werte, unbekannter Keys, defekter Querverweise oder eines fehlenden index.md.

Das ist ein Format, entworfen von Leuten, die davon ausgehen, dass Bundles halbfertig, teils maschinengeneriert und ständig im Fluss sind — genau so sehen echte Knowledge Bases nun mal aus. Strenge Formate sterben an ihrer eigenen Strenge. Dieses hier ist darauf ausgelegt, den Kontakt mit einem chaotischen Ordner zu überleben.

Google lieferte gleich Referenz-Tooling mit: einen BigQuery-Enrichment-Agent, einen statischen HTML-Visualizer und drei Beispiel-Bundles.

Ein Vorbehalt, den man klar benennen sollte: OKF ist v0.1 und explizit ein Draft. Die Spec ist versioniert und auf abwärtskompatibles Wachstum ausgelegt, aber Feldnamen und Konventionen können sich noch verschieben. Bauen Sie Ihre Knowledge Base heute noch nicht komplett darauf um. Behalten Sie aber im Auge, wohin der Standard zeigt.

Warum das über Google Cloud hinaus wichtig ist

Zieht man die BigQuery-Beispiele ab, ist OKF eine Wette mit deutlich größerem Wirkungsradius: dass das dauerhafte Format für maschinenlesbares Wissen einfache Markdown-Dateien in einem Ordner sind, den man selbst besitzt.

Kein proprietärer Katalog mit API. Keine Embeddings in einem Vector Store, den man nicht lesen kann. Kein Wiki mit einem Export-Button, der die eigenen Tabellen zerlegt. Dateien. Auf der Festplatte. Diffbar, greppbar, portabel zwischen Anbietern, lesbar von einem Menschen und von jedem Modell auf dem Markt.

Es ist dieselbe Schlussfolgerung, zu der Claude Code, Cursor, Copilot und Windsurf unabhängig voneinander kamen, als sie Markdown als ihr Instruktionsformat wählten. Dass Google Cloud das jetzt als Spec niederschreibt, ist eine Bestätigung, keine Erfindung.

Wo Minibase reinpasst

Wenn Sie einen Minibase Vault pflegen, unterhalten Sie bereits etwas, das strukturell nah an einem OKF-Bundle liegt: einen Ordner mit Markdown-Dateien und Frontmatter, auf Ihrer eigenen Festplatte, gelesen von Claude und ChatGPT.

Es formal konform zu machen ist eine kleine Änderung — fügen Sie Ihrem Frontmatter ein type hinzu, und lassen Sie Ihre Links den Rest erledigen:

---
type: Article
title: How the Open Knowledge Format can improve data sharing
resource: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
tags: [okf, agents, markdown]
timestamp: 2026-07-19T00:00:00Z
---

Das ist die praktische Form dieser Ankündigung. Der schwierige Teil einer Agent-Knowledge-Base war nie das Dateiformat — es war, gutes Ausgangsmaterial hineinzubekommen. Eine Spezifikation sagt einem, wie man den Ordner formt. Sie füllt ihn nicht.

Minibase ist der Teil, der ihn füllt: ein Klick verwandelt jede Webseite — Dokumentation, ein GitHub-README, eine Spec, einen Thread, ein Paper — in sauberes Markdown im eigenen Ordner, bereit für den nächsten Agent, den Sie laufen lassen.

Das Format ist jetzt Standard. Was Sie hineinpacken, ist immer noch Ihr Vorteil.

---

Minibase verwandelt jede Webseite in sauberes Markdown, das Ihre Agenten lesen können — die Erweiterung installieren und das Bundle aufbauen, das Ihre Agenten schlauer macht.