2026

18. Juni 2026

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 der okf-Skill samt Bundle-Sammlung, die ich darauf aufgesetzt habe.

S
Sascha Becker
Author

7 Min. Lesezeit

Open Knowledge Format: einfach Markdown, das dein Agent lesen kann

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
any day in the window [D-6, D].
# Citations
[1] [Engagement metric definitions](https://wiki.example.com/metrics)

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.

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.


S
Geschrieben von
Sascha Becker
Weitere Artikel