Knowledge Bundles: Was das Open Knowledge Format (OKF) ist und wie Sie es nutzen
Google Cloud hat mit dem Open Knowledge Format (OKF) einen offenen Standard veröffentlicht, der Firmenwissen als Markdown-Dateien organisiert, lesbar für Menschen und AI-Agenten. Was dahintersteckt, wie ein Knowledge Bundle konkret aussieht und wo sich der Einsatz lohnt.

Inhalt
- Das Problem: Wissen liegt überall, nur nicht dort, wo es gebraucht wird
- Was ist das Open Knowledge Format?
- So sieht ein Knowledge Bundle konkret aus
- Wer schreibt, wer liest: das Produzenten-Konsumenten-Prinzip
- Konkrete Anwendungsfälle
- Erste Schritte mit OKF
- Referenzen
Das Problem: Wissen liegt überall, nur nicht dort, wo es gebraucht wird
Wo steht bei Ihnen dokumentiert, wie ein neues Teammitglied Zugriff auf das CRM bekommt? Oder wer sich kümmert, wenn das Kontaktformular auf der Website nicht mehr funktioniert? Und eine Stufe technischer: Was bedeutet die Tabelle orders in Ihrer Datenbank, wie wird die Kennzahl "aktive Nutzer" berechnet, was ist bei einem Serverausfall zu tun? Vermutlich verteilt auf ein Wiki, ein Datenkatalog-Tool, Code-Kommentare und die Köpfe einzelner Mitarbeitender. Jedes System hat sein eigenes Format, keines spricht mit dem anderen.
Für Menschen ist das mühsam. Für AI-Agenten ist es ein Blocker: Ein Agent, der Ihre Daten abfragen oder Ihre Prozesse ausführen soll, braucht genau dieses Kontextwissen, und zwar in einer Form, die er zuverlässig lesen kann.
Google Cloud hat dafür im Juni 2026 das Open Knowledge Format (OKF) veröffentlicht: eine offene, herstellerneutrale Spezifikation, die Wissen als sogenannte Knowledge Bundles organisiert.
Was ist das Open Knowledge Format?
Die Idee ist bewusst einfach gehalten:
- Ein Konzept = eine Markdown-Datei. Eine Tabelle, eine Kennzahl, ein Runbook, eine API: jedes Wissenselement ist ein eigenes Markdown-Dokument mit YAML-Frontmatter.
- Ein Bundle = ein Verzeichnis. Ein Verzeichnisbaum solcher Dateien bildet ein Knowledge Bundle, die Einheit, in der Wissen verteilt wird.
- Links machen daraus einen Graphen. Konzepte verweisen mit normalen Markdown-Links aufeinander. So entstehen Beziehungen, die reicher sind als die reine Ordnerhierarchie.
Die Spezifikation verlangt genau ein Pflichtfeld im Frontmatter: type. Empfohlen sind zusätzlich title, description, resource, tags und timestamp. Alles Weitere dürfen Produzenten frei ergänzen. Die komplette Spezifikation v0.1 passt auf eine Seite.
Das klingt unspektakulär, und genau das ist der Punkt: kein SDK, keine Datenbank, kein proprietäres Konto. Nur Markdown-Dateien, die jeder Editor öffnen, jedes Git-Repository versionieren und jede Suchmaschine indexieren kann. Menschen lesen sie im Browser, AI-Agenten lesen sie ohne Spezialwerkzeug.
So sieht ein Knowledge Bundle konkret aus
Ein Bundle für ein Verkaufs-Datenset könnte so aussehen:
sales/
├── index.md
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md
│ └── customers.md
└── metrics/
├── index.md
└── weekly_active_users.md
Der Dateipfad ist die Identität des Konzepts. Die optionalen index.md-Dateien dienen als Einstiegspunkte, über die sich ein Leser (oder Agent) schrittweise in die Details vorarbeitet.
Eine einzelne Konzept-Datei, hier die Tabelle orders:
---
type: BigQuery Table
title: Orders
description: Eine Zeile pro abgeschlossener Kundenbestellung.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
| Spalte | Typ | Beschreibung |
|--------|-----|--------------|
| `order_id` | STRING | Eindeutige Bestell-ID. |
| `customer_id` | STRING | Fremdschlüssel zu [customers](/tables/customers.md). |
# Joins
Wird über `customer_id` mit [customers](/tables/customers.md) verknüpft.
Das Frontmatter enthält die wenigen Felder, nach denen man filtern und suchen will. In den Markdown-Body kommt der Rest: Prosa, Schemata, Beispielabfragen. Alles, was ein Mensch oder ein Sprachmodell im Zusammenhang lesen soll.
Wer schreibt, wer liest: das Produzenten-Konsumenten-Prinzip
OKF trennt sauber, wer Wissen erzeugt und wer es nutzt. Das Format ist der Vertrag dazwischen, die Werkzeuge auf beiden Seiten sind austauschbar:
- Ein von Hand geschriebenes Bundle kann ein AI-Agent konsumieren.
- Ein aus einer Metadaten-Pipeline generiertes Bundle kann ein Mensch im Visualizer durchstöbern.
- Ein Bundle, das ein Sprachmodell erzeugt hat, kann ein anderes Sprachmodell abfragen.
Google liefert dazu drei Referenzimplementierungen mit: einen Enrichment Agent, der BigQuery-Datensets durchläuft und OKF-Dokumente für Tabellen entwirft, einen statischen HTML-Visualizer, der jedes Bundle ohne Backend als interaktiven Graphen darstellt, und drei Beispiel-Bundles (GA4 E-Commerce, Stack Overflow, Bitcoin-Blockchain).
Interessant ist der Gedanke dahinter, den Andrej Karpathy in seinem LLM-Wiki-Gist so formuliert hat: Agenten langweilen sich nicht, vergessen keine Querverweise und können 15 Dateien in einem Durchgang aktualisieren. Ein Agent kann also sein eigenes Wiki pflegen. Die Dokumentation, die früher an fehlender Disziplin gescheitert ist, schreibt sich zunehmend selbst.
Konkrete Anwendungsfälle
Datendokumentation, die aktuell bleibt. Ein Agent generiert aus Ihren Datenbank-Schemata OKF-Dokumente, reichert sie mit Beschreibungen und Join-Pfaden an und legt sie ins Git-Repository. Ändert sich das Schema, aktualisiert der Agent die Dateien. Analysten und AI-Assistenten arbeiten mit demselben, stets aktuellen Stand.
Runbooks für den Betrieb. Incident-Playbooks als versionierte Konzept-Dateien: Ein Agent liest bei einer Störung das passende Runbook, führt die Schritte aus und ergänzt danach, was er gelernt hat. Mit log.md-Dateien lässt sich die Änderungshistorie direkt im Bundle festhalten.
Kennzahlen-Definitionen. "Umsatz" bedeutet im Marketing oft etwas anderes als im Finanzteam. Eine Konzept-Datei pro Kennzahl, mit Formel, Quelltabellen und Verantwortlichen, schafft eine verbindliche Referenz, auf die sich auch ein Chatbot stützen kann, der Geschäftsfragen beantwortet.
API-Dokumentation und Deprecation. Welche Schnittstellen gibt es, welche sind veraltet, was ist der Migrationspfad? Als OKF-Bundle liegt diese Information dort, wo Entwickler und Code-Agenten sie finden.
Projektwissen in Agenturen und Teams. Auch ausserhalb der Datenwelt funktioniert das Muster. Ein Bundle pro Kundenprojekt: Hosting-Setup, Deployment-Prozess, Ansprechpartner, Besonderheiten der Website. Neue Teammitglieder lesen sich ein, AI-Agenten übernehmen Wartungsaufgaben mit vollem Kontext. Bei NETNODE arbeiten unsere internen Agenten schon heute mit Projektwissen in Markdown-Form. Der Ansatz funktioniert bei uns bereits in Produktion.
Erste Schritte mit OKF
- Spezifikation lesen. Die v0.1-Spec auf GitHub ist in wenigen Minuten gelesen.
- Klein anfangen. Wählen Sie einen Bereich mit spürbarem Dokumentationsschmerz, etwa die zehn wichtigsten Tabellen Ihres Data Warehouse oder die Runbooks Ihres Betriebsteams.
- Ein Bundle anlegen. Ein Verzeichnis, eine Handvoll Markdown-Dateien mit
typeim Frontmatter, ins Git-Repository. Mehr braucht es für den Start nicht. - Konsumenten anschliessen. Den Visualizer aus der Referenzimplementierung ausprobieren, das Bundle einem AI-Agenten als Kontext geben, oder beides.
OKF v0.1 ist ausdrücklich ein Startpunkt, kein fertiger Standard. Wer jetzt einsteigt, kann die Entwicklung über Issues und Pull Requests mitprägen.
Referenzen
- Google Cloud Blog: How the Open Knowledge Format can improve data sharing
- OKF-Spezifikation v0.1 (SPEC.md)
- Referenzimplementierungen: Enrichment Agent, Visualizer und Beispiel-Bundles
- Andrej Karpathy: LLM Wiki (Original-Gist)
- Search Engine Journal: Google Cloud Announces The Open Knowledge Format
Lassen Sie uns darüber sprechen
Sie möchten wissen, wie Knowledge Bundles und AI-Agenten das Wissensmanagement in Ihrem Unternehmen konkret voranbringen? Wir beraten Sie gerne. Das erste Gespräch ist immer kostenlos.
Blog ·
