Open Knowledge Format: Google macht Agenten-Wissen zu Markdown — und wir haben es ins Moselwal-Handbuch übernommen
14. Juni 2026. Google Cloud hat am 12. Juni das Open Knowledge Format (OKF) vorgestellt — eine offene Spezifikation, die das Wissen, das KI-Agenten brauchen, als simples Verzeichnis von Markdown-Dateien mit YAML-Frontmatter beschreibt. Kein SDK, keine Laufzeit, kein proprietäres Catalog-Schema. Wir halten das für die bislang nüchternste und damit interessanteste Antwort auf die Fragmentierung von Agenten-Wissen — und haben OKF bereits in unser eigenes Handbuch übernommen.
Was ist passiert
Am 12. Juni hat das Data-Cloud-Team von Google Cloud das Open Knowledge Format in Version 0.1 veröffentlicht. OKF formalisiert ein Muster, das im vergangenen Jahr unter vielen Namen aufgetaucht ist — das „LLM-Wiki“ von Andrej Karpathy, die AGENTS.md/CLAUDE.md-Konventionsdateien, mit Coding-Agenten verdrahtete Obsidian-Vaults, „Metadata as Code“-Repositories in Datenteams. Die Spezifikation ist bewusst klein: Sie passt nach Google-Angaben auf eine Seite und schreibt im Kern genau eine Sache vor — dass jedes Wissensdokument ein type-Feld im Frontmatter trägt. Alles andere ist Empfehlung. Mitgeliefert werden Referenz-Implementierungen (ein Enrichment-Agent, der ein BigQuery-Dataset abläuft und je Tabelle ein OKF-Dokument schreibt, plus ein eigenständiger HTML-Visualizer) und drei fertige Beispiel-Bundles. Spezifikation, Code und Beispiele liegen offen auf GitHub; der Google-eigene Knowledge Catalog kann OKF bereits einlesen.
Das Problem: Wissen liegt überall und nirgends
Das Wissen, das ein Modell für brauchbare Antworten braucht, ist überwiegend internes Wissen: das Schema einer Tabelle, die hausspezifische Bedeutung einer Kennzahl, das Runbook für einen Vorfall, die Join-Pfade zwischen zwei Systemen, der Deprecation-Hinweis für eine alte API. In den meisten Häusern liegt dieses Wissen in gegenseitig inkompatiblen Silos: Metadaten-Kataloge mit eigener API, Wikis und Shared Drives, Code-Kommentare und Notebook-Zellen — und in den Köpfen weniger erfahrener Leute.
Fragt ein Agent „Wie berechne ich wöchentlich aktive Nutzer aus unserem Event-Stream?“, muss er die Antwort aus diesen verstreuten Flächen zusammensetzen. Jeder Anbieter bringt seinen eigenen Katalog, sein eigenes SDK, sein eigenes Knowledge-Graph-Schema mit, und nichts davon ist portabel. Das Ergebnis ist dreifache Verschwendung: Jeder Agenten-Bauer löst dasselbe Kontext-Problem neu, jeder Katalog-Anbieter erfindet dieselben Datenmodelle, und das Wissen bleibt hinter der Fläche eingesperrt, die es erzeugt hat.
Wie OKF funktioniert
Ein OKF-Bundle ist ein Verzeichnisbaum aus Markdown-Dateien. Jede Datei ist ein „Concept“ — eine Wissenseinheit, die alles sein kann: eine Tabelle, ein Dataset, eine Kennzahl, ein Playbook, eine API. Der Dateipfad ist die Identität des Concepts; aus tables/orders.md wird die Concept-ID tables/orders. Jedes Dokument besteht aus zwei Teilen.
Frontmatter und Body
Oben steht ein YAML-Block für die wenigen Felder, die man abfragen, filtern oder indexieren will — type (Pflicht), dazu empfohlen title, description, resource, tags, timestamp. Darunter folgt ein Markdown-Body für alles, was Mensch und Agent tatsächlich lesen: Schema-Tabellen, Beispiel-Queries, Join-Beschreibungen. Konventionelle Überschriften wie # Schema, # Examples und # Citations haben empfohlene Bedeutung, sind aber nicht erzwungen.
Graph statt Baum
Concepts verlinken sich über gewöhnliche Markdown-Links, bevorzugt bundle-relativ mit führendem Slash (/tables/customers.md). Aus dem Verzeichnis wird so ein Graph von Beziehungen, der reicher ist als die reine Eltern-Kind-Hierarchie des Dateisystems. Optionale index.md-Dateien erlauben „progressive disclosure“ — ein Agent navigiert die Hierarchie Ebene für Ebene, statt das ganze Bundle in den Kontext zu laden. Optionale log.md-Dateien führen eine chronologische Änderungshistorie.
Konformität
Die Konformitätshürde ist absichtlich niedrig: Ein Bundle ist OKF-0.1-konform, wenn jede Nicht-Reserved-Datei parsebares YAML-Frontmatter mit nicht-leerem type-Feld hat und die reservierten Dateien (index.md, log.md) ihrer Struktur folgen. Konsumenten müssen tolerant sein: unbekannte type-Werte, fehlende optionale Felder, zusätzliche Frontmatter-Keys und sogar kaputte Cross-Links dürfen kein Grund sein, ein Bundle abzulehnen. Dieses permissive Konsum-Modell ist der eigentliche Trick — es hält das Format nutzbar, während Bundles wachsen, umgebaut und teils von Agenten generiert werden.
Einordnung: ein Format, keine Plattform
Der Kern von OKF ist eine bewusste Verschiebung: Die Antwort auf fragmentiertes Wissen ist nicht noch ein Knowledge-Service, sondern ein Format. Das ist dieselbe architektonische Trennung, die wir aus dem Protokoll-Lager kennen. Das Model Context Protocol (MCP) standardisiert, wie ein Agent Werkzeuge und Datenquellen anspricht; A2A standardisiert, wie Agenten untereinander reden. OKF setzt eine Schicht daneben: Es standardisiert, in welcher Form das kuratierte Wissen selbst vorliegt, das diese Agenten konsumieren. Protokolle bewegen Kontext; OKF beschreibt, wie der Kontext am Ruhepunkt aussieht.
Entscheidend ist die Producer-Consumer-Unabhängigkeit. Ein von Hand geschriebenes Bundle kann von einem Agenten gelesen werden; ein von einer Export-Pipeline erzeugtes Bundle kann in einem Visualizer gebrowst werden; ein von einem LLM synthetisiertes Bundle kann von einem anderen abgefragt werden. Das Format ist der Vertrag, die Tooling-Enden sind unabhängig austauschbar. Genau diese Eigenschaft fehlt den bespoke Wiki-Mustern, die OKF ablöst: Karpathys Wiki, das Team-Wiki und der Katalog-Export eines Anbieters sehen alle ähnlich aus, waren aber nie dafür entworfen, zu kooperieren.
Bedeutung für den Mittelstand
Für mittelständische Häuser ist der praktische Hebel größer, als die nüchterne Spezifikation vermuten lässt. Die teuerste Form von Wissen im Mittelstand ist das Wissen in den Köpfen weniger Schlüsselpersonen — der eine Entwickler, der weiß, warum diese Tabelle so heißt, und die eine Kollegin, die den wahren Sinn einer Kennzahl kennt. OKF macht aus diesem impliziten Wissen ein versionierbares Artefakt, das neben dem Code lebt und das ein Agent lesen kann, ohne dass jemand ein Catalog-Produkt einkauft. Knowledge-Kuratierung wird zu einer normalen Software-Engineering-Tätigkeit: Pull Request, Diff, Review.
Die Souveränitäts-Achse ist der zweite Punkt, und er ist für den DACH-Raum kein Nebensatz. Ein OKF-Bundle ist ein Ordner. Es lässt sich als Tarball verschicken, in jedem Git-Repo hosten, auf jedem Dateisystem mounten — und es liegt damit standardmäßig dort, wo Sie die Datenhoheit ohnehin haben. Kein proprietäres API steht zwischen Ihnen und Ihren Metadaten, und der Wechsel des konsumierenden Modells oder Agenten ändert an den Wissensdateien nichts. Wer heute KI-Wissensbasen aufbaut, sollte die Frage stellen, ob das Wissen im Format eines einzelnen Anbieters gefangen ist oder in einem, das er selbst besitzt.
Der Datenschutz-Reflex gehört genau hierher, nicht in eine Fußnote. OKF beschreibt eine Form, keinen Hosting-Ort. Wo das Bundle liegt und wer es konsumiert, bleibt Ihre Entscheidung — und damit auch Ihre Verantwortung. Wenn ein OKF-Bundle Schemata, Kennzahlen-Definitionen oder Runbooks enthält, die personenbezogene oder geschäftskritische Informationen offenlegen, dann ist die Frage, welcher Agent welches Bundle in welcher Region in den Kontext lädt, eine Frage an Ihre oder Ihren Datenschutzbeauftragten. Das Format senkt die technische Hürde; es hebt nicht die Pflicht auf, den Datenfluss zu kennen. Der Vorteil gegenüber einem Cloud-Katalog ist gerade, dass Sie diesen Datenfluss bei einem reinen Datei-Bundle vollständig selbst kontrollieren.
Bedeutung für die technische Entwicklung
Architektonisch ist OKF ein Beleg für eine Bewegung, die sich über den ganzen Agenten-Stack zieht: weg von schwergewichtigen, anbietergebundenen Diensten, hin zu schmalen, offenen Verträgen, gegen die jeder bauen kann. MCP, A2A und nun OKF teilen dieselbe Haltung — den Interoperabilitäts-Punkt festlegen, das Content-Modell und die Tooling offen lassen. Für die eigene Architektur folgt daraus, die Wissensschicht genauso austauschbar zu halten wie die Modellschicht: Wissen als Dateien, versioniert neben dem Code, statt als Eintrag in einem Dienst, den man nur über dessen SDK erreicht.
Die ehrliche Grenze gehört dazu. OKF v0.1 ist ausdrücklich ein Startpunkt, kein fertiger Standard, und es ist eine Google-Initiative — die Adoption über Google-Produkte hinaus ist erwünscht, aber noch nicht erwiesen. Das Format löst die Repräsentation, nicht die schwierigen Folgefragen: Wie hält man ein Bundle aktuell, ohne dass es driftet? Wie verhindert man, dass ein Agent veraltetes oder vergiftetes Wissen als Wahrheit übernimmt? Die Spezifikation macht zu diesen Fragen bewusst keine Aussage. Was sie nicht zeigt, gehört auch nicht in unsere Erwartung — wohl aber auf die Beobachtungsliste.
Was wir konkret getan haben
Wir reden über OKF nicht aus der Distanz. Wir haben das Format bereits in unser Moselwal-Handbuch übernommen — die wachsende, versionierte Wissensbasis, mit der wir Moselwal als KI-Company mit agentischem Engineering aufbauen. Die Idee einer „queryable organization“ aus dieser Reflexion bekommt mit OKF ein konkretes Dateiformat: Concepts mit type-Frontmatter, bundle-relative Cross-Links, index.md für progressive Navigation. Unser Handbuch ist öffentlich einsehbar unter gitlab-profile-85e749.pages.moselwal.io.
Was uns an dem Schritt überzeugt hat, ist genau die Anschlusslosigkeit an ein Produkt. Wir mussten nichts einkaufen und nichts integrieren. Das Handbuch lag bereits als Markdown im Git; OKF gab den wenigen Konventionen einen Namen, sodass dieselben Dateien künftig von verschiedenen Agenten ohne Übersetzungsschicht konsumiert werden können. Das ist der Unterschied zwischen „wir haben ein Wiki“ und „unser Wissen ist maschinenlesbar abrufbar“ — und er kostete uns einen Nachmittag, kein Migrationsprojekt.
Häufige Fragen zu OKF
Wie stabil ist v0.1 — kann ich darauf bauen?+
Es ist ein Startpunkt. Die Versionierung folgt major.minor: Minor-Sprünge sind rückwärtskompatible Ergänzungen, Major-Sprünge dürfen brechen. Für einen ersten produktiven Einsatz im eigenen Repo ist das tragfähig; für eine organisationsweite Strategie würden wir die Adoption über Google hinaus beobachten.
Eignet sich OKF für mittelständisches Wissensmanagement, nicht nur für Daten-Kataloge?+
Ja. Ein Concept kann jede Wissenseinheit sein, auch ein Playbook oder ein Geschäftsprozess ohne technische Ressource. Genau so nutzen wir es im Moselwal-Handbuch. Der Charme ist, dass dasselbe Bundle von Menschen gelesen und von Agenten abgefragt wird, ohne Doppelpflege.
Was bedeutet das Pflichtfeld type konkret?+
Jedes Concept-Dokument muss im Frontmatter ein type tragen, etwa BigQuery Table, Metric oder Playbook. Diese Werte sind nicht zentral registriert; Konsumenten müssen unbekannte Typen tolerant als generische Concepts behandeln. Es ist die einzige harte Anforderung der Spezifikation.
Ist OKF dasselbe wie AGENTS.md oder CLAUDE.md?+
Es ist die Verallgemeinerung davon. AGENTS.md/CLAUDE.md und Obsidian-Vaults sind genau die Muster, die OKF formalisiert. Der Unterschied ist, dass OKF die kleine Menge an Konventionen festschreibt (Pflichtfeld type, Cross-Link-Regeln, reservierte Dateinamen), die diese Muster untereinander interoperabel macht.
Wie verhält sich OKF zu MCP und A2A?+
Komplementär. MCP regelt den Werkzeug- und Datenzugriff eines Agenten, A2A die Kommunikation zwischen Agenten. OKF beschreibt die Form des kuratierten Wissens, das Agenten konsumieren. Die Protokolle bewegen Kontext, OKF beschreibt den ruhenden Kontext.
Brauche ich Google Cloud oder BigQuery, um OKF zu nutzen?+
Nein. OKF ist anbieterneutral und an keine Cloud, Datenbank, kein Modell und kein Agenten-Framework gebunden. Der mitgelieferte Enrichment-Agent nutzt BigQuery und Gemini als Referenz-Implementierung, aber das Format selbst ist „nur Markdown plus YAML“. Ein Bundle entsteht in jedem Texteditor und liegt in jedem Git-Repo.
Konkrete Handlungsempfehlung
In dieser Reihenfolge. Erstens, lesen Sie die Spezifikation — sie ist kurz und in einer Sitzung erfasst. Zweitens, nehmen Sie eine bestehende, ohnehin in Markdown vorliegende Wissensquelle (ein Team-Wiki, eine README-Sammlung, ein Runbook-Ordner) und versehen Sie die Dokumente mit dem type-Frontmatter — das ist der gesamte Einstieg, kein Migrationsprojekt. Drittens, prüfen Sie mit der oder dem Datenschutzbeauftragten, welche Inhalte überhaupt in ein agenten-lesbares Bundle dürfen und welcher Agent es in welcher Region konsumiert, bevor sensibles Wissen ins Bundle wandert. Viertens, halten Sie die Wissensschicht bewusst anbieterneutral: Bundle im eigenen Git, Konsum über austauschbare Agenten, keine Bindung an ein einzelnes Katalog-Produkt. Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.
Quellen
- Google Cloud Blog: „Introducing the Open Knowledge Format“ / „How the Open Knowledge Format can improve data sharing“ (12.06.2026)
- Open Knowledge Format v0.1 — Spezifikation (SPEC.md) und Referenz-Implementierung (GitHub, GoogleCloudPlatform/knowledge-catalog) (abgerufen 14.06.2026)
- Andrej Karpathy: „LLM Wiki“ (Gist) — das Muster, das OKF formalisiert (abgerufen 14.06.2026)
- Kai Ole Hartwig: „Moselwal als AI-Company umbauen“ — Spur-2-Hintergrund zur queryable organization (06.05.2026)
Wir überführen Ihr Wissen in ein portables, anbieterneutrales Format — OKF-Bundle im eigenen Git, Konsum über austauschbare Agenten, Datenfluss unter eigener Kontrolle.
