Meine Antwort darauf ist unspektakulär, und gerade deshalb trägt sie: Ich behandle den Kontext eines KI-Assistenten wie Architektur. Wissen, Regeln und Entscheidungen stehen als Textdateien in einem versionierten Verzeichnis. Der Assistent liest sie, arbeitet mit ihnen und schlägt Änderungen vor. Seine eigenen Regeln ändert er nur mit einem Anlass, und ich gebe frei. Der Chat ist die Werkbank, nicht das Archiv.
Ich beschreibe das an meinem eigenen Aufbau: eine Notizsammlung in Obsidian, in der Claude Code als Assistent direkt auf den Dateien mitarbeitet, und darunter Git. Die Werkzeuge sind austauschbar. Die Prinzipien dahinter nicht.
Kontext ist das Eigentliche
Ein Sprachmodell bringt viel Allgemeinwissen mit. Was es nicht mitbringt: Ihre Organisation, Ihre Begriffe, Ihre Entscheidungen von gestern. Das liefert der Kontext, also alles, was das Modell in einer Sitzung zu lesen bekommt. Ein Prompt ist ein Satz. Der Kontext ist alles, was dieser Satz voraussetzt.
Der Chat ist dafür ein schlechter Ort. Er wächst, er scrollt, er endet. Die nächste Sitzung beginnt bei null. Was vereinbart wurde, liegt in einem Verlauf, den niemand noch einmal liest. Und wenn ein Kollege denselben Assistenten benutzt, weiß der von alldem nichts.
Daraus folgt der erste Grundsatz: Das Gedächtnis gehört in Dateien. In meiner Sammlung gibt es einen Ordner je Lebensbereich, darin Projektordner, sobald ein Thema genug Material trägt. Neues landet ungeordnet in einem Eingangskorb. Ein Befehl arbeitet ihn auf Zuruf ab: Er liest jede Datei, vergibt Schlagworte, verknüpft sie mit verwandten Notizen und legt sie in den passenden Ordner. Jede Notiz trägt Quelle und Datum, damit sie in einem Jahr noch verständlich ist. Die Ordnerstruktur ist nicht vorab entworfen. Sie entsteht mit dem Material, und neue Ordner bespricht der Assistent mit mir, bevor er sie anlegt.
Ein zweiter Punkt wird gern übersehen: Die wertvollsten Gedanken entstehen oft im Gespräch selbst. Der Assistent erkennt etwa, dass zwei getrennt geschriebene Notizen eigentlich zwei Hebel für dasselbe Ziel beschreiben. Bleibt diese Erkenntnis im Chat, ist sie morgen weg. Deshalb gilt bei mir die Regel: Solche Verbindungen schreibt der Assistent von sich aus in die Notizen zurück, mit einer kurzen Begründung, warum sie zusammengehören.
Regeln als Text, eine Datei je Kontext
Die zweite Schicht ist nicht das, was der Assistent weiß, sondern wie er arbeitet. Claude Code liest Regeldateien mit festem Namen automatisch ein. Bei mir gibt es eine zentrale Datei für die Arbeitsweise im ganzen Verzeichnis. Dort steht zum Beispiel, dass der Assistent Annahmen offenlegt, statt mit Rückfragen zu bremsen. Dass er nach jedem Arbeitsschritt sichert. Und wann er Arbeit an Hilfsagenten abgibt.
Dazu kommt je Projekt eine eigene Regeldatei. Sie gilt nur, wenn im Projektordner gearbeitet wird, und beschreibt das Projekt aus zwei Blickwinkeln: als Product Owner (was und warum: Ziel, Umfang, Prioritäten) und als Scrum Master (wie: Rolle, Haltung, typische Fallstricke). In einem Ordner mit Kundendaten steht dort etwa die Grenze, dass diese Daten den Ordner nicht verlassen. Welche Inhalte ein Assistent überhaupt zu sehen bekommt, ist ohnehin die erste Frage. Sie gehört in eine solche Datei, nicht in die Gewohnheit des Einzelnen.
Wiederkehrende Abläufe bekommen eigene Dateien: das Sortieren des Eingangskorbs oder eine kritische Abschlussprüfung, bevor ein Ergebnis das Haus verlässt. Fachrollen werden als Agenten beschrieben, jede mit Zweck, Werkzeugen und Datengrenzen.
Eine Technik hilft dabei besonders: Fachbegriffe als Kurzschrift. Statt drei Sätzen über ein Testvorgehen genügt „TDD, London School“. Ein offener Katalog sammelt solche etablierten Begriffe unter dem Namen Semantic Anchors; jeder ruft beim Modell ein ganzes Wissensfeld auf. Mein Assistent ist angewiesen, vor jeder Arbeitsaufgabe eine Zeile „Verstanden als: …“ mit den gewählten Begriffen zu schreiben. So sehe ich, wie er mich verstanden hat, bevor er loslegt.
Der Gewinn all dessen ist schlicht: Eine Regel, die als Text dasteht, kann man lesen, vergleichen, diskutieren und zurücknehmen. Eine Regel, die nur in einem Chatverlauf oder im Kopf eines Mitarbeiters existiert, bietet nichts davon.
Übersicht · Die Schichten des Kontexts
| Schicht | Zweck | Beispiel | Kontrolle |
|---|---|---|---|
| Wissen | Was der Assistent wissen soll | Notiz mit Quelle und Datum, ein Ordner je Lebensbereich | Git-Historie, Querverweise |
| Betriebsregeln | Wie überall gearbeitet wird | „Nach jedem Arbeitsschritt sichern“ | Änderung nur nach Freigabe, Commit nennt den Vorfall |
| Projektregeln | Rolle, Ton und Grenzen in einem Projekt | „Kundendaten bleiben in diesem Ordner“ | Korrektur nur bei echter Reibung, Anlass im Commit |
| Abläufe und Rollen | Wiederkehrende Vorgehen, abgegrenzte Fachrollen | Eingangskorb sortieren, Vertragsprüfung | Vorschlag mit Vorfall, Freigabe, regelmäßiger Review |
| Entscheidungen | Warum etwas so ist, wie es ist | Entscheidung „Git statt Prüfordner“ | Nur anhängen, nie löschen |
| Arbeitsstand | Wo ein laufender Auftrag steht | Plan-Datei mit Checkboxen | Sicherung nach jedem Schritt |
Verbesserung braucht einen Anlass und eine Freigabe
Die Versuchung liegt nahe: Der Assistent sieht seine eigenen Fehler. Warum soll er seine Regeln nicht selbst verbessern? Weil ein System, das seine Regeln still umschreibt, nach einigen Wochen ein unbekanntes System ist.
Bei mir gilt deshalb: Selbstverbesserung ja, aber nur mit Anlass und Freigabe. Am Ende einer Arbeit prüft der Assistent, ob etwas schiefgelaufen ist, das eine Regel verhindert hätte. Eine Fehldeutung, ein falscher Ton, eine fehlende Grenze. Findet er so etwas, schlägt er eine konkrete Änderung vor: welche Datei, welcher Text vorher, welcher nachher, welcher Vorfall. Ich entscheide. Erst dann schreibt er, und zwar als eigenen Commit, der den Vorfall nennt. Nur in den Projektdateien darf er kleine Korrekturen selbst vornehmen, auch dann mit dem Vorfall im Commit.
Der Normalfall heißt dabei „so lassen“. Kein kosmetisches Umformulieren, kein Verbessern um des Verbesserns willen. Ein Prüflauf, der nichts findet, ist ein gutes Ergebnis.
Zwei echte Anlässe aus meinem Aufbau zeigen, wie das aussieht. Mehrere lange Läufe brachen an einem Nutzungslimit ab; was nur im Arbeitsgedächtnis des Agenten stand, war verloren. Daraus wurde eine Regel zum Zwischenspeichern. Und Agenten beendeten ihre Arbeit regelmäßig mit langen Listen offener Fragen, die meist kleinteilig oder recherchierbar waren. Daraus wurde die Regel, Kleinteiliges selbst zu entscheiden, die Entscheidung samt Grund und Umkehrbarkeit festzuhalten und nur noch nach Wissen zu fragen, das wirklich nur ich habe. Ein Commit dazu könnte so lauten (Beispiel, verallgemeinert): „Regel zum Zwischenspeichern ergänzt, weil zwei lange Läufe am Nutzungslimit abbrachen und ihr Stand nur im Kontext lag.“
Größere Entscheidungen halte ich als Architecture Decision Records fest, kurze Entscheidungsnotizen nach Michael Nygard: Kontext, Entscheidung, Konsequenzen. Sie werden nie gelöscht, höchstens durch eine neue Entscheidung ersetzt. So lässt sich auch in einem halben Jahr noch nachlesen, warum etwas so ist, wie es ist.
Ein Assistent, der seine Regeln still umschreibt, ist nach ein paar Wochen ein anderer Assistent. Nur weiß es niemand.
Wichtig ist dabei, wie die Freigabe aussieht. In der Debatte um KI-Aufsicht unterscheidet man zwischen formaler und substanzieller menschlicher Kontrolle; der Fachbegriff lautet Meaningful Human Control. Ein Mensch, der auf „OK“ klickt, ohne zu wissen, worüber er entscheidet, kontrolliert nichts. Deshalb fragt mein Assistent nicht „Soll ich die Regeln verbessern?“, sondern legt Text, Änderung und Vorfall vor. Erst das macht aus der Freigabe eine Entscheidung.
Git ist das Sicherheitsnetz, kein Prüfordner
Naheliegend wäre ein Prüfordner: Der Assistent legt Änderungen dort ab, ein Mensch sieht sie durch und übernimmt sie. Das klingt kontrolliert. Aber ein solcher Puffer wird schnell zur zweiten Wahrheit: Was gilt, die Datei im Verzeichnis oder ihr Gegenstück im Prüfordner?
Ich gehe den anderen Weg. Der Assistent schreibt direkt und sichert nach jedem Arbeitsschritt mit einem Commit. Die Commit-Nachricht erklärt, warum etwas geändert wurde, nicht nur was. Am Ende jedes Laufs ist der Arbeitsstand sauber, nichts bleibt halb liegen. Änderungen, die nicht vom Assistenten stammen, etwa eigene Handgriffe oder Zustandsdateien eines Plugins, kommen in einen eigenen Commit mit Herkunftsvermerk. So bleibt klar, was wer geändert hat.
Damit hat jede Änderung einen Zeitpunkt, einen Inhalt und eine Begründung. Jeder Schritt lässt sich einzeln zurücknehmen. Kleine Commits sind lesbar; ein großer Sammel-Commit am Ende eines Tages ist es nicht.
Ich muss nicht jeden Commit lesen. Aber ich kann jeden lesen und jeden zurücknehmen.
Über den einzelnen Schritt hinaus beobachtet sich die Umgebung selbst. Ein zeitgesteuerter Job beschreibt sie regelmäßig nach arc42 und führt dort einen eigenen Abschnitt, in dem steht, wo Dokumentation und Wirklichkeit auseinanderlaufen. Ein wöchentlicher Bericht enthält einen Abschnitt zur Arbeitsweise. Beides fließt in Prüfläufe, die ich auf Zuruf starte: Sie halten Regeln und Werkzeuge gegen die tatsächliche Arbeit, schlagen Änderungen vor und schreiben nichts ohne mein OK. Das Beobachten ist automatisiert. Das Entscheiden nicht.
Context-Ökonomie: Rohmaterial auslagern, Zwischenstände sichern
Kontext ist begrenzt. Alles, was der Assistent für eine Teilaufgabe liest, bleibt im Gespräch und wird bei jedem weiteren Schritt erneut mitgeschickt. Lange Sitzungen werden dadurch teurer und schwerer zu überblicken. Irgendwann muss das Werkzeug verdichten, und beim Verdichten geht Detail verloren.
Deshalb gilt die Regel: Große, klar umrissene Teilaufgaben, die absehbar viele Dateien lesen, gehen an einen Hilfsagenten. Er arbeitet isoliert und gibt nur ein kompaktes Ergebnis zurück. Im Hauptgespräch bleiben Entscheidungen und Ergebnis, nicht das Rohmaterial. Kleine Handgriffe bleiben beim Hauptassistenten, ebenso Aufgaben, die vom laufenden Gespräch leben, und die Prüfung der eigenen Arbeit. Hier kostet der Kaltstart eines Hilfsagenten mehr, als er spart.
Der Auftrag an den Hilfsagenten muss für sich allein stehen, denn er kennt das Gespräch nicht: Pfade, Ziel, Antwortformat und das, was er ausdrücklich nicht tun soll. Und er enthält eine Pflicht, die ich aus den Abbrüchen gelernt habe: zuerst eine Plan-Datei mit Checkboxen anlegen, nach jedem Schritt sichern und abhaken, Rechercheergebnisse sofort in eine Datei schreiben. Ein Agent kann jederzeit abbrechen. Was dann nur in seinem Kontext stand, ist weg; was in Dateien und Commits steht, nicht. Nach einem Abbruch genügt ein Blick auf den Arbeitsstand, die letzten Commits und die Plan-Datei, um wieder anzusetzen.
Die stärkste Gegenposition
Man kann das alles für übertrieben halten, und die Einwände sind ernst zu nehmen.
Aufwand. Regelwerke wachsen. Meins auch. Jede Regel hat einen guten Grund, zusammen werden sie lang, und lange Regelwerke widersprechen sich irgendwann. Viele kleine Commits liest kein Mensch vollständig.
Bindung an das Werkzeug. Dateinamen, Ladelogik und das Format der Agenten sind werkzeugspezifisch. Wer das Werkzeug wechselt, schreibt um.
Scheinkontrolle. Das ist der stärkste Einwand. Der Assistent formuliert Vorschlag, Änderung und Begründung selbst. Wenn der Mensch nur noch nickt, wird die Freigabe zum Ritual. Eine Historie voller plausibler Begründungen beweist nicht, dass sie stimmen. Und eine Regel im Text garantiert nicht, dass das Modell sie befolgt.
Meine Antwort: Die Einwände treffen zum Teil. Den Aufwand bremst der Grundsatz „so lassen“: Eine Regel entsteht aus einem Vorfall oder einer bewussten Entscheidung, nicht aus dem Wunsch, etwas zu verbessern. Der Prüflauf kann auch vorschlagen, Regeln zusammenzulegen oder zu streichen. Pflege bleibt der Preis. Die Alternative ist aber nicht „keine Regeln“, sondern unsichtbare Regeln in Chatverläufen. Die Bindung an das Werkzeug betrifft die Konventionen, nicht die Inhalte. Notizen in Markdown und eine Git-Historie lassen sich mitnehmen, samt den Entscheidungen und ihren Gründen. Das ist mehr, als ein Chatverlauf je bietet.
Die Scheinkontrolle lässt sich nicht ganz auflösen. Das Verhalten eines Modells bleibt eine Wahrscheinlichkeit, keine Zusage. Der Text macht eine Abweichung aber sichtbar und benennbar, und dann ist sie ein Vorfall. Bei einem Modellwechsel prüfe ich die Regeln gezielt gegen das neue Modell. Kontrolle verstehe ich deshalb so: nicht jede Änderung geprüft, aber jede Änderung prüfbar und umkehrbar. Dazu feste Punkte, an denen ich bewusst hinsehe, etwa die Prüfläufe und die Abschnitte der Selbstbeschreibung, die Absichten und Entscheidungen festhalten. Eine kritische Abschlussprüfung, in der der Assistent sein Ergebnis aus Sicht eines Gegners angreift, kann Fehler abfangen, bevor ich sie sehe. Den Menschen ersetzt sie nicht. Am Ende bleibt es Disziplin.
Wo liegt das Gedächtnis?
Das Prompten ist der sichtbare Teil der Arbeit mit KI-Assistenten. Der unsichtbare Teil entscheidet, ob der Assistent ein Spielzeug Einzelner bleibt oder zum Werkzeug einer Organisation wird: wo sein Gedächtnis liegt, wer seine Regeln ändert und wie man eine Änderung zurückverfolgt. Das sind keine Fragen der Prompt-Technik. Es sind Architekturfragen.
Deshalb zum Schluss eine Frage an Sie: Wo liegt heute das Gedächtnis Ihres KI-Assistenten? Und wer könnte Ihnen sagen, warum er sich letzte Woche anders verhalten hat als heute?