Ein Ordner voller Markdown-Dateien: Wann das Agenten-Wiki besser trägt als RAG

Wenn mich ein Mittelständler fragt, wie sein Firmenwissen in den Assistenten kommt, ist die erste Frage im Raum fast immer eine Werkzeugfrage: welche Vektordatenbank, welches Embedding-Modell, welcher Anbieter. Ich stelle inzwischen eine andere zurück, und sie klingt banal: Wie viele Dokumente sind es denn?

Die Antwort liegt öfter, als man denkt, im niedrigen dreistelligen Bereich. Ein paar Handbücher, ein paar Dutzend Prozessbeschreibungen, die Preislogik, die Ausnahmen bei drei großen Kunden. Für diese Menge braucht niemand eine Suchmaschine mit Vektorindex. Sie braucht jemanden, der das Material liest und aufschreibt, was tatsächlich drinsteht.

Das Muster hat seit diesem Jahr einen Namen

Andrej Karpathy hat das Muster Anfang April 2026 zuerst in einem Beitrag auf X skizziert und die ausformulierte Fassung kurz darauf als GitHub-Gist nachgereicht. Er beschreibt darin drei Ebenen. Die Quellen liegen unverändert in einem Ordner — das Modell liest sie, ändert sie nie. Daneben steht das Wiki: vom Modell geschriebene Markdown-Seiten, Zusammenfassungen, Begriffs- und Personenseiten, untereinander verlinkt. Und dazu eine Schema-Datei — bei Claude Code die CLAUDE.md, bei anderen Werkzeugen AGENTS.md —, die festhält, wie das Wiki aufgebaut ist, welche Konventionen gelten und welche Arbeitsabläufe darauf laufen. Einer dieser Abläufe ist eine Art Durchsicht: Der Agent sucht Widersprüche zwischen Seiten, überholte Aussagen und verwaiste Einträge. Das Modell liest also keine Fundstellen, sondern Artikel, die es selbst geschrieben hat und regelmäßig prüft.

Google Cloud hat dieses Muster am 12. Juni 2026 als Open Knowledge Format (OKF, sinngemäß „offenes Wissensformat") in Version 0.1 formalisiert. Technisch ist das unaufwendig, und das ist der Punkt: ein Verzeichnis aus Markdown-Dateien mit YAML-Kopfzeilen, pro Ordner eine index.md, optional eine fortgeschriebene log.md. Pflicht ist genau ein Feld, type. Reserviert sind daneben title, description, resource, tags und timestamp. Kein SDK, keine Laufzeitumgebung, keine Registry. Die Referenzwerkzeuge — ein Agent, der aus BigQuery-Datensätzen OKF-Konzepte entwirft, ein eigenständiger HTML-Betrachter für die Graphenansicht, drei Beispielbündel — liegen offen auf GitHub. Google schreibt selbst dazu, v0.1 sei ein Anfang und kein fertiger Standard, und formuliert die Diagnose in einem Satz: Was fehle, sei ein Format, kein weiterer Dienst.

Man sollte das Interesse dahinter mitlesen. Google verkauft Datenplattformen und hat gute Gründe, dass Agenten Metadaten aus BigQuery zuverlässig verstehen. Das entwertet die Spezifikation nicht — sie ist herstellerneutral genug, dass man sie ohne eine einzige Google-Komponente verwenden kann —, aber es erklärt, warum sie ausgerechnet jetzt kommt.

Warum der Ordner in der Praxis oft trägt

RAG (Retrieval-Augmented Generation, Antwortgenerierung mit Nachschlagen) zerlegt Dokumente in Abschnitte, rechnet sie in Zahlenvektoren um und sucht bei jeder Frage die ähnlichsten heraus. Das funktioniert, und ich habe es oft genug gebaut. Es hat aber vier Eigenschaften, die im Betrieb Geld kosten.

Die Trefferqualität ist eine Wahrscheinlichkeit. Ob der entscheidende Absatz auf Platz drei landet oder auf Platz zwölf, hängt an Chunk-Größe, Embedding-Modell und Formulierung der Frage. Ein Wiki mit Index und Querverweisen hat dieses Problem nicht: Der Agent liest das Verzeichnis und folgt den Verweisen. Er sucht nicht, er navigiert.

Das Schreiben ist die eigentliche Arbeit. Wenn drei Dokumente drei verschiedene Freigabegrenzen nennen, holt ein RAG-System im Zweifel alle drei und formuliert daraus eine geschmeidige Antwort. Beim Verdichten in einen Wiki-Artikel fällt der Widerspruch auf, und jemand muss ihn entscheiden. Das ist unbequem und genau der Wert.

Es ist überprüfbar. Ein Markdown-Ordner liegt in Git. Man sieht, wer was wann geändert hat, man kann eine Änderung gegenlesen und zurückrollen. Einen Vektorindex kann man nicht gegenlesen.

Der Agent kann zurückschreiben. Ein Wiki ist keine Einbahnstraße. Fällt bei der Arbeit etwas an, das fehlt, legt der Agent den Artikel an oder ergänzt ihn — mit demselben Werkzeug, mit dem er liest.

Aus der Werkstatt

Wir betreiben unseren Hub seit Monaten nach diesem Muster, ohne dass wir es damals so genannt hätten. Bevor ein Agent hier einen Artikel schreibt, holt er sich über eine Werkzeugschnittstelle den Styleguide für genau diese Inhaltsart: Tonfall, Aufbau, verbotene Wörter, Farbtokens, Sicherheitsregeln. Das ist ein gepflegtes Dokument, kein Suchergebnis. Es ist der Grund, warum die Beiträge über Monate hinweg gleich klingen, und es wäre über Ähnlichkeitssuche nicht zu erreichen — man kann eine Regel nicht ungefähr befolgen.

Dasselbe gilt in den Entwicklungsprojekten: hierarchische CLAUDE.md-Dateien, eine je Ebene, dazu Architekturentscheidungen als eigene Dokumente. Der Agent liest den Ordner, nicht einen Index. Der Aufwand liegt vollständig im Schreiben — und er fällt einmal an, nicht bei jeder Anfrage.

Aufschlussreicher war der lokale Durchgang. Ich habe agentische Aufgaben mit Qwen 3.6 auf einem Mac mini M4 Pro mit 24 Gigabyte gefahren — auf einem Gerät also, das auf einem gewöhnlichen Schreibtisch steht und nicht im Rechenzentrum. Drei Dinge sind mir dabei gegenüber den Architekturen aufgefallen, die ich vorher gebaut hatte: Das Modell antwortete präziser, weil es die maßgebliche Seite las statt einer plausibel gerankten Fundstelle. Es kam schneller zur richtigen Lösung, weil es weniger Schleifen brauchte, um sich das Bild zusammenzusetzen. Und es wurde über die Zeit besser, weil das, was in einer Sitzung anfiel, im Wiki blieb und beim nächsten Mal schon dastand.

Der dritte Punkt ist der, den ich unterschätzt hatte. Ein Abrufsystem wird durch Benutzung nicht besser — es findet beim hundertsten Mal genau das, was es beim ersten Mal gefunden hat. Ein gepflegtes Wiki wächst mit der Arbeit, die daran geleistet wird.

Das ist eine Beobachtung, keine Messung: Es gab keinen kontrollierten Gegenversuch, in dem derselbe Bestand einmal über Abruf und einmal über das Wiki läuft, und ich habe nichts gezählt. Wer eine Zahl braucht, muss sie selbst erheben. Bemerkenswert finde ich den Befund trotzdem, weil er ausgerechnet dort auftrat, wo man ihn nicht erwartet: bei einem lokalen Modell mittlerer Größe, dem man gemeinhin zutraut, an mehrschrittigen Aufgaben zu scheitern.

Wo RAG gewinnt

Es wäre unredlich, das Muster als Ersatz zu verkaufen. Karpathy nennt das interne Team-Wiki ausdrücklich als einen der Anwendungsfälle, aber die Grenzen sind nicht theoretisch.

Der Index muss ins Kontextfenster passen, und ab einer gewissen Menge tut er das nicht mehr. Wo genau die Schwelle liegt, hängt am Modell; belastbare Zahlen dazu kenne ich nicht, und die Werte, die in Blogs kursieren, sind Schätzungen ohne Messung. Nach unserer Erfahrung wird es ab einigen hundert Seiten unübersichtlich — dann braucht es Abruf, zumindest über dem Wiki. Ein Markdown-Ordner kennt außerdem keine Rollen und Rechte: Wenn die Personalabteilung Dokumente hat, die der Vertrieb nicht sehen darf, löst das kein Dateisystem. Und schreiben mehrere Agenten gleichzeitig, entstehen Schreibkonflikte, die eine Datenbank abfängt und ein Ordner nicht.

Dazu kommt die Aktualität. Bei einem Ticketsystem mit tausend neuen Vorgängen im Monat, bei Vertragsarchiven, bei allem, was in großer Menge unstrukturiert anfällt, ist Abruf der richtige Weg. Niemand pflegt tausend Tickets zu Wiki-Artikeln.

Die Frage, die ich stattdessen stelle

Sie lautet nicht „RAG oder Wiki", sondern: Welcher Teil unseres Wissens ist stabil genug, dass sich das Aufschreiben lohnt?

Diese Aufteilung ist in fast jedem Betrieb dieselbe. Regeln, Prozesse, Zuständigkeiten, Preislogik, Ausnahmen, Konventionen — das ändert sich in Quartalen, nicht in Stunden, und es ist der Teil, bei dem eine falsche Antwort teuer wird. Er gehört ins gepflegte Wiki. Der laufende Betrieb — Tickets, Mails, Projektakten, Messwerte — gehört in den Abruf. Wer beides in dieselbe Vektordatenbank kippt, behandelt die Betriebsanweisung wie eine Mail vom Dienstag.

Praktisch heißt das: Fangen Sie mit einem Verzeichnis an, nicht mit einer Ausschreibung. Ein Ordner, eine Übersichtsseite, zwanzig Artikel zu dem, was heute in Köpfen steht. Ein Agent kann den Rohbestand vorschlagen, gegenlesen muss ein Mensch. Wenn das trägt und über hundert Artikel hinauswächst, ist der Weg zu OKF ein Kopfzeilen-Feld, keine Migration — und der Weg zu RAG steht immer noch offen, dann aber mit einem Bestand, der bereits sortiert ist.

Die meisten Wissensprojekte scheitern nicht an der Suche, sondern daran, dass es nichts zu finden gibt.

Was ein agentisches Wiki gegen den Wissensabfluss leistet, habe ich im Juli 2026 beschrieben — damals mit RAG als Selbstverständlichkeit im Unterbau. Diesen Teil würde ich heute anders schreiben.

---

Weiterlesen

• Das Wissen, das in Rente geht: Warum Unternehmen jetzt ein agentisches Wiki brauchen — der demografische Anlass, aus dem das Thema überhaupt drängt
• Ein Agent, der bleibt: Der Hermes-Agent und lokale KI-Modelle — ein Agent, der sein Wissen auf der eigenen Maschine behält und fortschreibt
• Qwen 3.6 im Werkstatt-Test: 35B, die sich anfühlen wie 200B — das Modell, mit dem der lokale Durchgang lief
• Lokale Modelle sind kein Datenschutz-Kompromiss — warum die Modellgröße für gepflegtes Kontextwissen seltener das Nadelöhr ist als angenommen