Open Knowledge Format: einfach Markdown, das dein Agent lesen kann
Googles Open Knowledge Format ist eine winzige, herstellerneutrale Spezifikation für den Kontext, den ein KI-Agent braucht: ein Bündel aus Markdown-Dateien mit YAML-Frontmatter, ein Pflichtfeld pro Konzept, kein SDK und kein Lock-in. Hier ist, was es ist, warum der nachsichtige Consumer-Vertrag der clevere Teil ist, und was ich darauf aufgesetzt habe: den okf-Skill, eine Bundle-Sammlung und OKF Viewer, eine Desktop-App, die jedes Bundle als Graph liest.
Ein KI-Agent ist nur so gut wie der Kontext, den du ihm gibst. Das Modell ist inzwischen der einfache Teil. Schwierig ist alles, was es über deine Systeme nicht weiß: welche Tabelle wirklich den Umsatz hält, warum diese Kennzahl Bot-Traffic ausschließt, was das Runbook sagt, wenn die Pipeline um 3 Uhr nachts ausfällt. Dieses Wissen existiert. Es liegt nur in einem Wiki, das niemand pflegt, in einem Slack-Thread vom letzten Quartal oder im Kopf einer einzigen erfahrenen Person. Also beginnt jede Agenten-Sitzung damit, es neu herzuleiten oder zu raten.
Googles Open Knowledge Format ist eine kleine, scharfe Antwort auf die Frage, wo dieses Wissen liegen sollte.1
Was OKF tatsächlich ist
OKF (Open Knowledge Format) ist eine herstellerneutrale Spezifikation, derzeit v0.1, für den Kontext, den ein Agent braucht. Die Einheit ist ein Bundle: ein Verzeichnis aus Markdown-Dateien unter Versionskontrolle, idealerweise direkt neben dem Code, den es beschreibt. Jede Datei ist ein Konzept: eine Tabelle, ein Datensatz, eine Kennzahl, ein Runbook, eine API, ein Join-Pfad oder jede Idee, die es wert ist, einmal aufgeschrieben zu werden, damit ein Agent sie lesen kann, statt sie neu herzuleiten.2
Das ist das Ganze. Nur Markdown, nur Dateien, nur YAML-Frontmatter. Kein SDK, keine Datenbank, kein proprietärer Account. Wer eine Datei lesen kann, kann OKF lesen. Wer ein Repo klonen kann, kann es ausliefern.
Eine Regel
OKF verlangt genau eine Sache: Jede Konzept-Datei trägt YAML-Frontmatter mit einem nicht-leeren type. Das ist die gesamte Konformitätshürde. Alles andere, ein Titel, eine Beschreibung, eine resource-URL, Tags, ein Zeitstempel, ist empfohlen, nicht erforderlich.
Ein Konzept sieht so aus:
markdown
---
type: Metric
title: Weekly active users
description: Distinct users with a qualifying event in a trailing 7-day window.
tags:[engagement, growth]
timestamp:2026-06-18T09:00:00Z
---
# Definition
A user is active on a day if they emit a qualifying event in
[events](/tables/events.md). WAU on date D counts distinct user_id active on
Der type ist beschreibend, nicht aus einer Registry gezogen. "Metric", "BigQuery Table", "Runbook", "Reference": alle gültig, weil sie selbsterklärend sind, nicht weil eine Instanz sie abgesegnet hat.2
Der clevere Teil: Produzenten sind präzise, Konsumenten sind nachsichtig
Hier ist die Designentscheidung, die OKF zu mehr macht als einer Konvention für Ordnernamen. Der Consumer-Vertrag ist bewusst nachsichtig. Ein Werkzeug, das ein Bundle liest, darf es nicht ablehnen wegen eines fehlenden optionalen Feldes, eines unbekannten type, eines zusätzlichen Frontmatter-Schlüssels, eines kaputten Querverweises oder eines fehlenden Index. Ein Konsument, der nicht einmal die deklarierte Version versteht, sollte trotzdem nach bestem Vermögen lesen, statt abzulehnen.2
Produzenten zielen auf Präzision. Konsumenten zielen auf Nachsicht. Diese Asymmetrie ist es, die ein von Hand geschriebenes Bundle, ein aus einem Metadaten-Export gekipptes Bundle und ein von einem Modell synthetisiertes Bundle alle später von irgendeinem anderen Agenten lesbar macht, ohne dass sich vorher jemand auf ein Schema einigt.
Die Form, kurz gefasst
Ein paar Konventionen tragen das Format, ohne es zu beschweren:
Konzepte verlinken einander mit gewöhnlichen Markdown-Links. Der Link ist die Kante; der umgebende Text ist die Beschriftung ("verknüpft mit customers über customer_id"). Der Beziehungsgraph quert die Ordnerhierarchie frei.
index.md ist eine kuratierte Auflistung eines Verzeichnisses, damit ein Agent entscheiden kann, wo er hinabsteigt, ohne alles zu lesen. Ein Produzent erzeugt sie; ein Konsument kann sie synthetisieren, wenn sie fehlt.
log.md ist eine datierte Änderungshistorie, neueste zuerst.
# Citations listet die Quellen hinter einer Aussage. Eine externe Seite kann sogar als eigenes Konzept unter references/ aufgenommen werden, mit ihrer URL und dem Datum des Abrufs, sodass die Herkunft explizit bleibt.
Wenn das nach einem Obsidian-Vault oder einem aufgeräumten Docs-Ordner klingt, ist genau das der Punkt. Bundles vertragen sich mit Werkzeugen, die Markdown plus Frontmatter ohnehin sprechen (Obsidian, Notion, MkDocs, Hugo), sodass du sie ohne eigene Oberfläche durchsehen oder bearbeiten kannst.
Wozu überhaupt eine Spezifikation
Das Muster, Markdown plus Frontmatter als agentenlesbare Wissensbasis, ist nicht neu. Was OKF hinzufügt, ist, spezifiziert zu sein: Es legt die kleine Menge an Regeln fest, die für Interoperabilität nötig ist, und hört dann auf. Drei Prinzipien erklären, warum es so klein bleibt:
Minimal meinungsstark. Ein Pflichtfeld. Welche Typen es gibt und wie ein Body aufgebaut ist, entscheidet der Produzent.
Unabhängigkeit von Produzent und Konsument. Wer das Wissen schreibt, ist sauber getrennt von dem, der es liest, und das Werkzeug an jedem Ende ist austauschbar.
Format, keine Plattform. Nie an eine Cloud, eine Datenbank, einen Modellanbieter oder ein Agenten-Framework gebunden. Sein Wert kommt aus Verbreitung, nicht aus Besitz.
Google liefert Belege statt nur ein Dokument: einen Produzenten (einen Anreicherungs-Agenten, der einen BigQuery-Datensatz durchläuft und Seed-URLs zu Reference-Konzepten crawlen kann), einen einzigen, in sich geschlossenen HTML-Konsumenten, der jedes Bundle als Force-Directed-Graph rendert, und drei Beispiel-Bundles zum Klonen.3
Ich habe einen Skill dafür gebaut
Die Spezifikation zu lesen ist das eine. Einen Agenten dazu zu bringen, tatsächlich ein konformes Bundle zu erzeugen und es konform zu halten, während es wächst, ist das andere. Also habe ich den ganzen Ablauf als Agenten-Skill verpackt.
Der okf-Skill bringt einem Agenten bei, OKF-Bundles zu erstellen, zu validieren und zu pflegen. Er stellt die Befehle bereit, die das Format nahelegt (init, add, enrich, link, index, log, validate, export, consume), und läuft genauso nützlich implizit: Bitte den Agenten, eine Tabelle zu dokumentieren, ein Runbook zu schreiben oder einen Katalog für einen Agenten zu exportieren, und er liefert das Ergebnis als konformes Bundle mit einem type pro Konzept aus, statt als formlosen Fließtext. Er trägt die v0.1-Spezifikation, Copy-paste-Vorlagen und einen Validator ohne Abhängigkeiten, der an der einen harten Regel scheitert und bei der weichen Anleitung nur warnt.
Er funktioniert in jedem Agenten, der das skills.sh-Format spricht (Claude Code, Cursor, Codex, Cline, Windsurf, OpenCode). Einzeln installieren:
bash
npx skills@latest add saschb2b/skills --skill okf
Die vollständige Aufschlüsselung dessen, was er tut, steht auf der okf-Skill-Seite.
Und ein Ort, um Bundles zu veröffentlichen
Ein Format nützt nur, wenn Wissen darin tatsächlich ausgeliefert wird. Also habe ich einen Bereich dieser Seite genau dafür geöffnet: OKF-Bundles, wo ich Bundles veröffentliche, die du lesen, klonen oder deinem eigenen Agenten vorlegen kannst. Sie liegen in einem eigenen Repository als schlichte Verzeichnisse, sodass hier nichts sie einsperrt.
Das erste ist ticket-writing: das Argument aus einem kürzlichen Beitrag über Ticket Smells, übersetzt in agentenlesbare Konzepte (die Smells, die Techniken, die sie heilen, die Forschung hinter jedem), sodass ein Agent, der dein Backlog verfeinert, die Begründung direkt lesen kann, statt nur "schreib bessere Tickets" zu hören. Weitere folgen.
Und eine Desktop-App, um sie zu lesen
Der Skill deckt das Schreiben von Bundles ab, die Seite das Veröffentlichen. Blieb der menschlichste Teil offen: das Lesen. Ein Bundle ist trivial zu erzeugen und mühsam zu erleben. Der Beziehungsgraph, also genau das, was ein Bundle von einem Docs-Ordner unterscheidet, steckt implizit in den Links, und ein Dateibaum versteckt ihn vollständig. Agenten durchlaufen diese Struktur problemlos. Menschen blieben beim Greppen hängen.
Also habe ich OKF Viewer gebaut, eine kleine, schnelle, offline laufende Desktop-App genau dafür. Zeige sie auf einen Ordner und sie erkennt jedes Bundle darin automatisch, dann rendert sie jedes als interaktiven Konzeptgraphen neben einer richtigen Lesespalte: jedes Konzept ein Knoten, jeder Markdown-Link eine Kante, mit Suche, Backlinks, Gliederung und Live-Reload, wenn sich die Dateien darunter ändern. Sie liest auch ODSF-Bundles und rendert Design-Tokens als Farbfelder und Komponenten als Live-HTML-Vorschauen.
OKF Viewer liest seine eigene Produktspezifikation: die Linkstruktur des Bundles als Graph, das ausgewählte Konzept daneben.
Zwei Details schließen den Kreis zur Spezifikation. Die App ist ein Consumer genau in dem Sinn, den das Format vorschreibt, tolerant bis zum Buchstaben: Ein unsauberes Bundle wird nie abgewiesen, seine Probleme landen stattdessen in einem Validierungs-Panel. Und sie dogfoodet das Format vollständig, denn die Produktspezifikation der App ist selbst ein OKF-Bundle, das als eingebautes Beispiel mitgeliefert wird. Der Viewer rendert die Dokumente, die ihn spezifizieren.
Frei und Open Source, gebaut mit Tauri (Rust-Kern, React-Frontend), mit Installern für Windows und Linux auf der Download-Seite.
Die Wette
Werkzeuge ändern sich schnell. Das Agenten-Framework, in das du dieses Jahr dein Wissen verdrahtet hast, ist vielleicht nicht das, zu dem du nächstes Jahr greifst. OKFs leise Wette ist, dass Wissen, geschrieben als schlichte, verlinkte, versionierte Dateien, das Werkzeug überlebt, für das du es geschrieben hast. Markdown hat schon ein Dutzend Editoren überlebt. Der schwer erarbeitete Kontext deines Teams verdient dieselbe Haltbarkeit.
Wenn du Wissen hast, das ein Agent immer wieder neu herleitet, schreib es einmal auf, gib jedem Teil einen type und committe es. Das ist das ganze Format.
