Wissensbasis im Vault

Vier der fünf Orte aus Kapitel 05 liegen im Projekt oder im Werkzeug. Der fünfte liegt daneben, und er ist der einzige, der etwas kann, was die anderen nicht können: Wissen halten, das über ein einzelnes Projekt hinausreicht.

Wofür sich das eignet

Was hier zählt, sind die Markdown-Dateien in einem gewöhnlichen Ordner. Obsidian ist eine Ansicht darauf, austauschbar gegen jeden anderen Editor, weit verbreitet und mit einer brauchbaren Suche. Das nützt in einem Vibe-Coding-Projekt an mehreren Stellen:

• Eigene Notizen. Was Sie selbst festhalten, in derselben Form wie das, was ein Agent schreibt.
• Übergabedateien. Ein Stand, den eine Sitzung für die nächste hinterlässt, oder für jemand anderen.
• Lesbarer Text. Eine Markdown-Datei öffnet sich in jedem Editor und bleibt lesbar, wenn Obsidian längst durch ein anderes Programm ersetzt ist.
• Langfristiger Austausch mit einem Agenten, über ein einzelnes Gespräch hinaus.
• Die Wissensbasis, um die es in diesem Kapitel geht.

Warum überhaupt daneben

Drei Sorten Wissen passen in keine Projektdatei.

Wissen über mehrere Projekte. Wie Sie arbeiten, welche Entscheidungen Sie in ähnlichen Fällen schon getroffen haben, was sich woanders bewährt hat.

Wissen, das kein Code ist. Fachliches, Rechtliches, Marktbeobachtungen, gelesene Arbeiten. Es gehört zur Sache und in kein Repository.

Wissen, das zu groß ist. Eine Projektanweisung soll unter zweihundert Zeilen bleiben. Eine Sammlung, die über Monate wächst, hat vierhundert Seiten.

Das Muster

Andrej Karpathy hat dafür im April 2026 eine Beschreibung veröffentlicht, die inzwischen als Vorlage dient. Der Kern ist der Unterschied zu dem, was die meisten mit Dokumenten und Modellen machen.

Der übliche Weg lädt Dokumente hoch, sucht bei jeder Frage die passenden Stücke heraus und formuliert daraus eine Antwort. Das funktioniert, und es fängt bei jeder Frage wieder von vorn an. Nichts baut sich auf.

Das Muster dreht die Reihenfolge um: Der Agent liest eine neue Quelle einmal und arbeitet sie in eine bestehende Sammlung von Notizen ein. Er ergänzt Einträge, aktualisiert Zusammenfassungen und vermerkt, wo neue Angaben alten widersprechen. Karpathy fasst den Unterschied in einem Satz:

This is the key difference: the wiki is a persistent, compounding artifact. (externe Seite, gist.github.com)

Was einmal verstanden wurde, steht danach da. Die Querverweise sind gezogen, die Widersprüche markiert. Die nächste Frage setzt darauf auf.

Drei Schichten

Der Aufbau ist einfach genug, um ihn an einem Nachmittag anzulegen.

Die Rohquellen. Artikel, Arbeiten, Notizen, Mitschriften, alles in einem eigenen Verzeichnis. Diese Dateien sind unveränderlich: Der Agent liest daraus und schreibt niemals hinein. Das ist die Grundlage, auf die sich alles Weitere berufen muss.

Das Wiki. Ein Verzeichnis mit Notizen, die der Agent schreibt und pflegt. Zusammenfassungen, Begriffsseiten, Vergleiche, eine Übersicht. Diese Schicht gehört ihm allein: Sie lesen sie, er schreibt sie.

Das Schema. Eine Datei, die dem Agenten sagt, wie die Sammlung aufgebaut ist und wie er damit umzugehen hat. Das ist dieselbe Sorte Datei wie in Kapitel 03, hier für einen anderen Zweck.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Wo das liegt

Die Sammlung braucht kein besonderes Programm. Es sind Markdown-Dateien in einem Verzeichnis, und genau das macht sie für einen Agenten zugänglich: Er liest und schreibt sie mit denselben Werkzeugen wie Quelltext.

Verbreitet ist Obsidian als Ansicht darauf, weil es dasselbe Verzeichnis darstellt, ohne es umzuformen:

Obsidian stores notes privately on your device (externe Seite, obsidian.md)

Karpathy beschreibt die Arbeitsteilung anschaulich:

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. (externe Seite, gist.github.com)

Sie sehen also links den Agenten arbeiten und rechts das Ergebnis wachsen, mit Verweisen, Graphenansicht und Suche.

Warum das vorher nicht ging

Der Grund ist bemerkenswert unspektakulär, und Karpathy benennt ihn:

Humans abandon wikis because the maintenance burden grows faster than the value. (externe Seite, gist.github.com)

Das Lesen und das Denken waren nie das Problem. Das Problem war die Buchhaltung: Querverweise nachziehen, Zusammenfassungen aktuell halten, bemerken, dass eine neue Quelle einer alten Aussage widerspricht. Diese Arbeit wächst mit jeder Seite, und Menschen hören irgendwann auf.

Eine Maschine hört nicht auf. Damit verschiebt sich, was sich lohnt.

Der Aufbau aus Ebene 1 ist in einer halben Stunde angelegt. Was darüber entscheidet, ob die Sammlung nach drei Monaten noch etwas taugt, sind die Abläufe, die auf ihr laufen.

Es sind drei, und sie greifen ineinander.

Aufnehmen

Sie legen eine neue Quelle in das Rohverzeichnis und bitten den Agenten, sie einzuarbeiten. Was dann passiert, ist mehr als Ablegen: Er liest die Quelle, bespricht die Kernpunkte mit Ihnen, schreibt eine Zusammenfassungsseite, aktualisiert die betroffenen Begriffs- und Themenseiten und schreibt einen Eintrag ins Protokoll. Eine einzelne Quelle fasst dabei leicht zehn bis fünfzehn Seiten an.

Der Teil, der im Alltag den Unterschied macht, ist das Gespräch dazwischen. Wer sich die Kernpunkte vorlegen lässt und korrigiert, bevor geschrieben wird, bekommt eine brauchbare Sammlung. Wer stapelweise einliest, bekommt eine Sammlung, deren Fehler er nie zu Gesicht bekommt.

Fragen

Sie stellen eine Frage gegen die Sammlung. Der Agent sucht die passenden Seiten, liest sie und antwortet mit Belegen darauf.

Der Punkt, den man beim ersten Mal übersieht: Gute Antworten gehören zurück in die Sammlung. Ein Vergleich, den Sie einmal angefordert haben, eine Verbindung, die dabei aufgefallen ist, eine Einordnung, die stimmt: Das ist Arbeit, die sonst im Gesprächsverlauf verschwindet. Als eigene Seite abgelegt, zählt sie beim nächsten Mal mit.

Damit wächst die Sammlung aus zwei Richtungen: aus den Quellen, die Sie hineingeben, und aus den Fragen, die Sie stellen.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Durchsehen

Der Vorgang, den alle weglassen, und der über die Haltbarkeit entscheidet. In Abständen bitten Sie den Agenten, die Sammlung selbst zu prüfen: Widersprüche zwischen Seiten, Behauptungen, die eine neuere Quelle überholt hat, Seiten ohne eingehenden Verweis, Begriffe, die überall auftauchen und keine eigene Seite haben, Lücken, die eine Recherche schließen könnte.

Das ist derselbe Gedanke wie ein Prüflauf über einem Projekt, und er ist aus demselben Grund nötig: Eine Sammlung, die niemand misst, sieht gepflegt aus.

Zwei Dateien, die den Unterschied machen

Damit ein Agent in einer wachsenden Sammlung etwas findet, ohne sie ganz zu lesen, braucht es zwei Hilfsdateien mit verschiedenen Aufgaben.

Ein Inhaltsverzeichnis. Jede Seite mit einem Verweis und einer Zeile dazu, was darauf steht, geordnet nach Art. Bei einer Frage liest der Agent zuerst diese Datei und steigt dann gezielt ein. Das reicht erstaunlich weit, nach Karpathys Erfahrung bis in den Bereich von hundert Quellen und einigen hundert Seiten, und es kommt ohne jede Suchtechnik aus.

Ein Protokoll. Chronologisch, nur angehängt, nie umgeschrieben: was wann aufgenommen, gefragt und durchgesehen wurde. Wenn jede Zeile mit demselben Muster beginnt, lässt sich das Protokoll mit gewöhnlichen Kommandozeilen- Werkzeugen auswerten, und die letzten fünf Einträge sind ein Einzeiler.

Der Nutzen des Protokolls ist derselbe wie der einer Commit-Historie in Kapitel 04: Es beantwortet die Frage, was zuletzt passiert ist, ohne dass jemand sie beantworten musste.

Die Schemadatei

Das Bindeglied, und die Stelle, an der die meiste Arbeit steckt. Sie sagt dem Agenten, wie die Sammlung aufgebaut ist, welche Seitenarten es gibt, wie eine neue Quelle einzuarbeiten ist und wie eine Antwort auszusehen hat.

Karpathy nennt sie den Schlüssel des Ganzen, und die Begründung ist genau die aus Kapitel 03: Ohne diese Datei ist der Agent ein Gesprächspartner, mit ihr ein Bibliothekar mit Vorschrift. Sie entsteht auch genauso, nämlich unterwegs, aus jedem Fall, in dem etwas anders lief als gewollt.

Wann eine Suche dazukommt

Solange das Inhaltsverzeichnis reicht, brauchen Sie nichts weiter. Ab einer gewissen Größe reicht es nicht mehr, und dann gibt es zwei Wege.

Ein Suchprogramm auf der Kommandozeile. Der Agent ruft es auf wie jedes andere Tool. Für Markdown-Sammlungen gibt es fertige, die Stichwort- und Bedeutungssuche verbinden und dabei auf dem eigenen Rechner bleiben.

Eine Anbindung über eine Schnittstelle. Dasselbe Programm kann sich beim Agenten als Tool anmelden, über ein eigenes Protokoll für genau diesen Zweck (externe Seite, modelcontextprotocol.io). Der Unterschied ist im Betrieb gering und in der Ordnung groß: Ein angemeldetes Tool steht in der Liste dessen, was der Agent kann, und braucht keine Erklärung im Schema.

Beide Wege haben denselben Vorbehalt: Sie lösen ein Problem, das Sie am Anfang nicht haben. Wer mit der Suche beginnt, baut Technik um eine Sammlung, die noch aus zwölf Seiten besteht.

Eine Sammlung nach dem Muster aus Ebene 1 hat eine Eigenschaft, die in keiner Anleitung steht und die man teuer lernt: Sie liest sich hervorragend.

Die Seiten sind gegliedert, die Sätze sind flüssig, die Querverweise stimmen. Nichts daran sieht nach Entwurf aus. Und genau deshalb wird sie für etwas gehalten, das sie nicht ist.

Ein Fall aus der eigenen Sammlung

An dieser Website hing eine Aussage über Agentensysteme daran, wer eine bestimmte Formel geprägt hat. In der Wissensbasis stand dazu eine Seite, die sie Mitchell Hashimoto (externe Seite, mitchellh.com) zuschrieb. Die Seite war klar geschrieben, thematisch richtig einsortiert und mit anderen Seiten verknüpft.

Der Text, auf den sie sich berief, enthält diese Formel überhaupt nicht. Sie stammt aus einem anderen Beitrag (externe Seite, blog.langchain.com), fünf Wochen später erschienen und von jemand anderem geschrieben.

Aufgefallen ist das erst, weil vor der Übernahme in einen veröffentlichten Text beide Originale gelesen wurden. Ohne diesen Schritt wäre die falsche Zuschreibung auf einer Seite gelandet, die von Belegen handelt.

Warum das kein Einzelfall ist

Der Fehler hat eine Ursache, die im Aufbau liegt.

Eine Seite in dieser Sammlung entsteht, indem ein Modell mehrere Quellen liest und daraus einen zusammenhängenden Text schreibt. Dabei verschwindet die Zuordnung: Welcher Satz aus welcher Quelle stammt, steht danach nicht mehr da, wenn niemand es erzwingt. Zwei Aussagen aus zwei Texten stehen nebeneinander und werden beim Lesen zu einer.

Dazu kommt die Wirkung der Form. Ein flüssiger Absatz ohne Einschränkungen sieht aus wie ein Ergebnis. Ein Zitat mit Datum und Adresse sieht aus wie Arbeit. Die Sammlung produziert das Erste.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Die Gegenmaßnahme, die wirkt

Zwei Dinge helfen, und das zweite ist das eigentliche.

Jede Seite nennt ihre Quellen, und zwar je Aussage statt am Ende. Das kostet Platz und macht den Text weniger schön. Es ist der Unterschied zwischen einer Sammlung, in der man nachschlagen kann, und einer, in der man glauben muss.

Die Prüfung liegt außerhalb des Modells. Ein Agent, der seine eigenen Belege prüft, prüft nichts: Die Antwort „habe ich geprüft“ kostet ihn dasselbe wie die Prüfung, und er kann nicht unterscheiden, ob er eine Adresse gelesen oder erzeugt hat.

Praktisch heißt das ein Programm daneben, das jedes hinterlegte Zitat im Rohtext der Quelle sucht. Findet es das Zitat nicht, wird die Aussage markiert. An dieser Website läuft eine solche Prüfung täglich über alle Quellen, und der lehrreiche Teil ist ein Sonderfall: Wenn eine Sammlung Befunde meldet und dazu keinen einzigen prüfbaren Beleg, ist das selbst der Alarm.

Der Unterschied zu einer Suche über Dokumente

Ebene 1 hat die Abgrenzung angerissen. Hier die technische Fassung, weil sie erklärt, wofür welches Verfahren taugt.

Das ältere Verfahren verbindet ein Sprachmodell mit einem Abrufschritt (externe Seite, arxiv.org): Zu jeder Frage werden die passenden Textstücke gesucht und dem Modell vorgelegt. Der Abruf ist frisch, die Antwort kann sich auf große Bestände stützen, und es braucht keine Vorarbeit.

Der Preis ist, dass jede Frage bei null anfängt. Eine Verbindung zwischen zwei Dokumenten, die beim letzten Mal aufgefallen ist, muss beim nächsten Mal wieder auffallen. Für Fragen, deren Antwort in einem Absatz steht, ist das gleichgültig. Für Fragen, deren Antwort aus fünf Quellen zusammenzusetzen ist, entscheidet es über das Ergebnis.

Beide Verfahren schließen sich nicht aus. Eine gewachsene Sammlung bekommt irgendwann eine Suche, und dann läuft der Abruf über die kompilierten Seiten statt über die Rohquellen. Was dabei gefunden wird, ist bereits verarbeitet.

Es ist ein Git-Verzeichnis

Ein Satz aus Karpathys Beschreibung, der leicht überlesen wird und praktisch viel bedeutet:

The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free. (externe Seite, gist.github.com)

Damit gilt alles aus Kapitel 04 auch hier. Ein Agent, der fünfzehn Seiten in einem Durchgang ändert, ist genau der Fall, für den es die Versionsverwaltung gibt. Und die Historie beantwortet eine Frage, die sonst niemand beantworten kann: Seit wann steht dieser Satz da, und was hat ihn ausgelöst.

Wer eine Aufnahme rückgängig machen will, nimmt einen Commit zurück. Ohne das müsste er fünfzehn Seiten von Hand zurückdrehen.

Was hineingehört und was nicht

Zum Schluss die Grenze, die man vorher ziehen sollte.

Eine solche Sammlung ist reizvoll, weil alles hineinpasst. Genau deshalb landet darin schnell Material, das dort nicht liegen darf: Vertrauliches aus dem Beruf, personenbezogene Angaben, Dinge unter Verschwiegenheit. Die Sammlung wird von einem Agenten gelesen, sie wird verarbeitet, und Teile davon landen womöglich in Texten, die nach außen gehen.

Die Regel, die sich bewährt hat: Was aus einem vertraulichen Zusammenhang stammt, kommt gar nicht erst in die Rohquellen. Bereinigen beim Aufnehmen ist sicher, Bereinigen danach ist eine Suche über eine Sammlung, die inzwischen fünfzehn Seiten weiterverarbeitet hat.