Wenn du einem KI-Agenten einfach nur erlaubst, in deine Notizen zu schreiben, bekommst du keinen Wissensschatz, sondern einen Haufen Dateien. Obsidian ist im Kern nichts anderes als ein Ordner mit Markdown-Textdateien auf deiner Festplatte, die sich gegenseitig verlinken. Keine Cloud, keine Datenbank, kein Konto. Ein KI-Agent braucht dafür keine Schnittstelle und kein Plugin, er kann Dateien einfach lesen und schreiben.
Was fehlt, sind Regeln. Wie liest er, was legt er wo ab, wann ändert er eine bestehende Seite und wann legt er eine neue an. Diesen Rahmen liefert Andrej Karpathy mit seinem LLM-Wiki, Google hat das Muster mit dem Open Knowledge Format (OKF) standardisiert. In diesem Artikel zeige ich dir, wie die drei Schichten zusammenspielen und wo das Ganze seine Grenzen hat.
Warum klassisches RAG nicht reicht
Heute funktioniert das Meiste über Retrieval-Augmented Generation, kurz RAG. Vor dem Antworten sucht sich die KI passende Schnipsel aus einer Vektordatenbank und baut daraus die Antwort. Konkret läuft das so: Du stellst eine Frage, ein System prüft ähnliche Treffer in der Datenbank und gibt diese Schnipsel als Grundlage weiter.
Karpathy stört daran ein Punkt: Deine KI fängt bei jeder Frage wieder von null an. Sie holt die Schnipsel, erzeugt eine Antwort, und danach ist das Verständnis wieder weg. Das gesammelte Wissen verschwindet. Sie wiederholt die ganze Schleife bei jeder Frage, verbrennt dabei Tokens und arbeitet nicht nachhaltig. Was du eigentlich willst, ist, dass die KI die Denkarbeit einmal macht, das Wissen sich ansammelt und du schnell darauf zurückgreifen kannst, ohne diesen Abruf immer wieder zu durchlaufen.
Die drei Schichten: RAW, Wiki, CLAUDE.md
Karpathy beschreibt in seinem Konzept drei Schichten. In RAW landen alle Rohdokumente, zum Beispiel Transkripte, PDFs oder Originaldokumente. Die KI liest aus diesem Ordner, schreibt aber niemals hinein. Das ist die Wahrheit, an der alles andere gemessen wird.
Im Wiki liegen die Seiten, die die KI schreibt und pflegt. Es besteht aus einer Indexdatei und einer Logdatei. Die Indexdatei ist eine Art Katalog, in dem die Inhalte strukturiert sind. In der Logdatei kannst du nachvollziehen, wann welche Änderung vorgenommen wurde. Der Agent schreibt in dieses Wiki hinein und zieht auch wieder Informationen heraus.
Die wichtigste Datei ist die Steuerdatei, bei Karpathy CLAUDE.md. Da steht drin, wie dein Wiki aufgebaut ist und was die KI tun soll, wenn eine neue Quelle reinkommt. Ohne diese Datei hast du einen Chatbot. Mit ihr hast du jemanden, der dein Wiki wirklich diszipliniert pflegt.
Google macht daraus einen Standard
Karpathy bleibt in seiner Beschreibung bewusst abstrakt. Er schreibt selbst, dass er die Idee beschreibt, aber nicht die Umsetzung. Genau daraus entsteht ein Problem: Jeder baut seine eigene Struktur und benennt die Ordner, wie er möchte, und Teilen wird schwer.
Kurz nachdem Karpathy sein Konzept vorstellte, hat Google mit dem Open Knowledge Format nachgelegt. Google macht aus Karpathys Muster einen offenen Standard, damit die Wikis austauschbar und skalierbar sind. Mit OKF ist die Struktur immer gleich, egal wer Informationen in das Wiki schreibt. In Kombination mit der Steuerdatei arbeiten Agenten wie Claude Code, Codex oder ein Hermes-Agent immer gleich: Karpathys Ansatz beschreibt, was getan werden muss, OKF legt fest, in welchem Format.
Das Setup in Obsidian aufbauen
Die Umsetzung ist überraschend simpel. Du legst einen neuen Vault an, das ist nur ein Ordner auf deiner Festplatte. Dann installierst du das Terminal-Plugin, verlässt dazu den eingeschränkten Modus und suchst in den Community-Erweiterungen nach Terminal. Nach der Installation hast du direkt in Obsidian ein Terminal zur Verfügung und kannst Claude Code aktivieren.
Als Nächstes lädst du dir Karpathys LLM-Wiki als ZIP herunter, ziehst die Datei in deinen Vault und entpackst sie. Über das Terminal sagst du dem Agenten, er soll das Konzept aus dem aktuellen Ordner lesen. Die Struktur entsteht automatisch: ein RAW-Ordner, das Wiki mit Index und Logdatei sowie die Steuerdatei.
Dasselbe machst du mit dem OKF-Schema, indem du den Link als Quelle hinterlegst. Das Format wird in RAW abgelegt und die Steuerdatei angepasst. Nun legst du Informationen in RAW ab, zum Beispiel Transkripte und Projektdokumente, und weist den Agenten an, die Inhalte in das Wiki zu übernehmen. Er erstellt die Einträge, die Indexdatei zeigt die Struktur mit den einzelnen Ordnern und Dokumenten, die Logdatei protokolliert, was wann passiert ist. Im Graph-View siehst du am Ende, wie die Dokumente miteinander verknüpft sind.
Wo das Ganze an seine Grenzen stößt
Das Konzept hat ein paar ehrliche Nachteile. Halluzinationen verschwinden nicht komplett, sie verfestigen sich eher. Kleine Fehler, die beim Schreiben ins Wiki entstehen, werden zu einem Systemproblem, weil sie bei jedem weiteren Durchlauf als bereits geprüfte Grundlage behandelt werden.
Die Rohquellen müssen liegen bleiben, damit du bei jeder Aussage auf das Original zurückgehen kannst. Und der Ansatz funktioniert laut Karpathy gut bei etwa hundert Quellen oder ein paar hundert Seiten. Wird das Wiki größer, steigt der Tokenverbrauch, weil alle Inhalte durchgelesen werden. Dein Index mit dem Inhaltsverzeichnis kann allein schon ein volles Kontextfenster füllen.
Ein weiterer Punkt ist Datenschutz. Alles, was das Modell liest, geht über die Server des Anbieters. Jede Quelle, die du in RAW ablegst, wird übertragen. Wenn dir das wichtig ist, arbeitest du mit einem lokalen Modell, das keine Daten nach außen schickt.
Getrennte Vaults pro Lebensbereich
Um der Komplexität entgegenzuwirken, empfiehlt de Fanti, getrennte Vaults pro Lebensbereich aufzusetzen. Einen für Business, einen für Privat, einen für Finanzen, einen für Kunden. Sonst hast du vermischte Themen, und dein Hobby steht mit deinen Kundenprojekten im selben Index. Bei jeder Frage muss dann beides durchgelesen werden.
Gleichzeitig willst du nicht für jeden Kunden einen eigenen Vault, weil du damit den Vorteil verlierst, dass sich die Dinge miteinander verbinden und verknüpfen können.
Karpathy liefert die Logik, was passiert, wenn eine neue Quelle reinkommt. Google liefert das Format, damit auch ein anderer Agent mit den Dateien klarkommt. Alles andere kommt in die Steuerdatei, die jeder Agent lesen kann. Ohne diese Konzepte sammelst du keinen Wissensschatz, sondern Datenmüll.
Fazit
Für Einzelprojekte lohnt sich dieser Ansatz. Obsidian ist kostenlos, lokal und ohne Konto nutzbar, und mit RAW, Wiki und Steuerdatei bekommst du ein System, das der Agent selbst pflegt, statt ein chaotisches Sammelsurium. Die Nachteile solltest du im Kopf behalten: kleine Fehler verfestigen sich, die Rohquellen müssen bleiben, und ab ein paar hundert Seiten wird es tokenintensiv. Willst du den Ansatz für dein gesamtes Unternehmen ausrollen, stößt du irgendwann an diese Grenzen. Für dein eigenes Wissensmanagement ist er trotzdem einen Versuch wert.
