Die Gewohnheit, die KI-Agenten wirklich besser macht

Du korrigierst deinen KI-Agenten. Er repariert die Sache. Nächste Woche machst du exakt dieselbe Korrektur nochmal.

Das ist der Standard-Fehlermodus bei KI-gestützter Arbeit, und fast niemand redet darüber, weil er sich im Moment nicht wie ein Fehler anfühlt. Der Agent hat gemacht, was du wolltest. Die Aufgabe ist erledigt. Aber wenn die Korrektur nur in dieser einen Konversation existiert, verdampft sie in der Sekunde, in der die Session endet. Und beim nächsten Mal zahlst du dieselbe Steuer nochmal. In sechs Wochen, in denen wir Claude Code als Betriebsschicht unserer Agentur gefahren haben, sind bei uns 972 Markdown-Dateien gegen 220 TypeScript-Dateien entstanden. Dieses Verhältnis ist kein Zufall. Es ist das Ergebnis einer einzigen Gewohnheit: fast jede Session damit zu beenden, das gerade Gelernte zurück in die Dateien zu schreiben, die der Agent beim nächsten Mal liest.

Das ist die Praxis mit dem größten Hebel, die wir gefunden haben, um KI-Agenten tatsächlich nützlicher werden zu lassen statt auf demselben Stand zu bleiben. Wenn du gerade deine eigene AI-native Operation aufbaust, gehört das direkt neben die KI-Tools, mit denen wir unsere Agentur wirklich betreiben.

Inhaltsverzeichnis

Warum Korrekturen von selbst verschwinden
Das Ritual am Ende jeder Session
Was eine Kontextdatei enthalten sollte
Korrekturen vs. Bestätigungen
Warum das besser funktioniert als ein besserer Prompt
Was sich nach sechs Wochen in der Praxis zeigt
Die drei Fehler, die wir selbst gemacht haben
Häufige Fragen zu KI-Agenten und Kontextdateien
Das Wichtigste in Kürze

Warum Korrekturen von selbst verschwinden

Das Kontextfenster eines KI-Agenten ist per Design auf die aktuelle Konversation begrenzt. Du korrigierst ihn am Montag, startest am Dienstag eine frische Session, und keine einzige Korrektur von Montag existiert noch. Es sei denn, du hast sie irgendwo hingeschrieben, wo der Agent auch am Dienstag liest.

Das ist kein Bug. So ist das Werkzeug gebaut. Aber es bedeutet: Die Verantwortung dafür, dass Wissen sich aufsummiert, liegt komplett bei der Person, die korrigiert. Und die meisten merken das erst, wenn sie denselben Fehler zum vierten Mal korrigiert haben.

Die Fehler, die sich wiederholen, sind selten dramatisch. Es sind kleine, strukturelle Dinge. Eine Formatierungsvorliebe. Eine Namenskonvention. Ein Stück Kontext dazu, wie das Werbekonto eines bestimmten Kunden aufgesetzt ist. Eine Plattform-Eigenheit, die man dem Interface nicht ansieht.

Keines davon ist ein Schulungsdokument wert. Jedes davon ist eine Zeile wert in einer Datei, die der Agent automatisch liest.

Und genau das ist der Punkt, an dem die meisten Teams die Rechnung falsch aufmachen. Sie denken in Dokumentation, also in großen Artefakten, die jemand pflegen muss. Die tatsächliche Einheit ist viel kleiner: ein Satz, eine Regel, ein Grund. Zwei Minuten Arbeit für einen Effekt, der ab sofort in jeder Session gilt.

Das Ritual am Ende jeder Session

Das Muster, das funktioniert: Am Ende einer Session, in der du etwas Nicht-Offensichtliches korrigiert hast (oder in der sich der Ansatz des Agenten als richtig herausgestellt hat, obwohl er nicht die naheliegende Wahl war), investierst du zwei Minuten und schreibst die Lektion in die passende Kontextdatei, bevor du zumachst.

Keine Zusammenfassung dessen, was passiert ist. Eine konkrete, wiederverwendbare Regel.

Die Mechanik ist absichtlich simpel:

Identifiziere, was korrigiert wurde. Nicht "die Copy war falsch", sondern das konkrete, verallgemeinerbare Ding: "Ad Copy ist standardmäßig Englisch für jeden Markt, außer es steht explizit etwas anderes da" ist wiederverwendbar. "Fix diese eine Headline" ist es nicht.
Schreib es in die Datei, die der Agent beim nächsten Mal auch wirklich liest. Eine projektbezogene Instruktionsdatei für alles, was zu einer Codebase oder einem Kunden gehört. Eine übergreifende Datei für alles, was überall gilt.
Nimm das Warum mit, kurz. Eine Regel ohne Kontext wird an den Rändern falsch angewendet. "Nur englische Copy" ohne den Grund (ein konkreter Fall, in dem Copy versehentlich ins Deutsche lokalisiert wurde) liest sich wie eine willkürliche Einschränkung statt wie eine Lektion mit klarer Grenze.
Commit es. Wenn die Kontextdatei in einem Repo liegt, ist das ein echter Commit, keine Notiz nebenbei. Notizen nebenbei gehen verloren. Commits bleiben.

Nichts daran ist kompliziert. Die ganze Hürde besteht darin, dass es ein zusätzlicher Schritt ist, nachdem die "echte" Arbeit schon fertig ist. Und wenn eine Aufgabe sich erledigt anfühlt, überspringt man diesen Schritt sehr leicht.

Dazu kommt ein psychologischer Effekt, den man einkalkulieren sollte: Genau in dem Moment, in dem die Lektion am frischesten ist, ist die Motivation am niedrigsten. Deshalb funktioniert es als Ritual besser als als Vorsatz. Nicht "ich schreibe das auf, wenn es wichtig ist", sondern "ich schließe keine Session, ohne kurz zu prüfen, ob hier etwas Bleibendes drin war".

Was eine Kontextdatei enthalten sollte

Nicht alles gehört ins permanente Gedächtnis. Überfüllung erzeugt ihr eigenes Problem: eine aufgeblähte Instruktionsdatei, durch die der Agent sich bei jeder einzelnen Aufgabe wühlen muss.

Zwei Dinge sind jedes Mal die Zeilen wert. Ein drittes nur selektiv.

Immer festhalten: Korrekturen. Jedes Mal, wenn du den Ansatz des Agenten umlenken musstest, eine Formatierungsregel, eine Scope-Grenze, eine plattformspezifische Eigenheit: genau das ist die Sorte Ding, die sich wiederholt, wenn sie nicht aufgeschrieben wird.

Immer festhalten: bestätigte, nicht-offensichtliche Entscheidungen. Das ist der Teil, den fast alle überspringen. Wenn du einen ungewöhnlichen Ansatz freigegeben hast, ohne zu widersprechen, ist das genauso wertvoll wie eine Korrektur. Ohne diesen Eintrag hat eine spätere Session keine Möglichkeit zu wissen, dass die ungewöhnliche Entscheidung bewusst war und nichts, was man "reparieren" sollte. Der Bestätigungsfehler läuft in beide Richtungen: Wer nur Korrekturen protokolliert, driftet langsam weg von Ansätzen, die er selbst schon validiert hat, zurück zu generischen Defaults.

Nur selektiv festhalten: Live-Systemzustand. Aktuelle Budgets, laufende Kampagnenlisten, die Zahlen von heute, alles was dir eine API oder ein Dashboard live sagen kann, gehört nicht in eine statische Datei. Es wird schal. Und ein veralteter Stand, dem vertraut wird, ist schlimmer als gar kein Stand. Was in eine dauerhafte Datei gehört, ist die Entscheidung und ihre Begründung, nicht die Zahl, auf der die Entscheidung damals basierte.

Diese dritte Regel klingt pedantisch, bis sie dich zum ersten Mal trifft. Ein Agent, der aus einer Kontextdatei liest, "das Tagesbudget für Kampagne X liegt bei 80 €", und darauf eine Empfehlung baut, während das Budget seit drei Wochen bei 200 € liegt, produziert eine Analyse, die auf den ersten Blick völlig plausibel aussieht und komplett falsch ist. Der Live-Wert gewinnt immer. Die Datei hält fest, warum das Budget damals bewegt wurde.

Korrekturen vs. Bestätigungen

	Korrekturen	Bestätigungen
Auslöser	Du hast den Ansatz des Agenten umgelenkt	Du hast etwas Nicht-Standardmäßiges ohne Widerspruch freigegeben
Warum leicht zu übersehen	Fühlt sich erledigt an, sobald der Fix sitzt	Fühlt sich nicht wie ein Ereignis an, das man protokolliert
Was passiert, wenn du es auslässt	Derselbe Fehler wiederholt sich in der nächsten Session	Der Agent driftet über Zeit zurück zum generischen Default
Was du schreibst	Die konkrete, verallgemeinerbare Regel plus den Grund	Die ungewöhnliche Entscheidung plus warum sie hier richtig war

Die meisten protokollieren nur die linke Spalte. Die rechte ist leiser und deutlich einfacher komplett zu übersehen, aber sie trägt genauso viel Gewicht.

Eine validierte Ermessensentscheidung, die nie aufgeschrieben wird, ist eine Ermessensentscheidung, die du irgendwann nochmal ausdiskutierst. Meistens mit dir selbst, meistens an einem Tag, an dem du dafür keine Zeit hast.

Warum das besser funktioniert als ein besserer Prompt

Der Reflex, wenn ein Agent einen wiederholbaren Fehler macht: beim nächsten Mal einen detaillierteren Prompt schreiben. Das funktioniert für genau eine Session.

Eine Kontextdatei, die der Agent automatisch zu Beginn jeder relevanten Aufgabe liest, funktioniert für jede Session nach der, in der du sie geschrieben hast. Mit null zusätzlichem Aufwand ab diesem Punkt.

Der Zinseszins-Effekt ist der ganze Punkt. Ein Team, das jede Korrektur als Einzelfall behandelt, zahlt dieselbe "die KI lernt unsere Konventionen noch"-Steuer unbegrenzt weiter. Ein Team, das Korrekturen zurück ins Gedächtnis schreibt, zahlt diese Steuer einmal pro Fehler, für immer. Und jede Session danach startet auf einem minimal höheren Niveau als die davor.

Über eine ausreichend große Zahl an Sessions ist genau das der Unterschied zwischen einem KI-Tool, das sich nach sechs Monaten exakt gleich anfühlt, und einem, das sich anfühlt, als würde es tatsächlich wissen, wie du arbeitest.

Das ist übrigens auch der Grund, warum "wir nutzen KI" und "wir haben KI in unsere Prozesse gebaut" zwei völlig verschiedene Aussagen sind. Der Unterschied ist nicht das Modell. Der Unterschied ist, ob irgendwo etwas liegt, das mit der Zeit dicker wird.

Was sich nach sechs Wochen in der Praxis zeigt

Konkret, aus unserem eigenen Betrieb.

Das Verhältnis 972 zu 220 ist die interessanteste Zahl in diesem Text, und zwar nicht wegen der absoluten Höhe. Es zeigt, wo der eigentliche Output einer AI-native Agentur landet. Deutlich mehr geschriebener Kontext als geschriebener Code. Die Markdown-Dateien sind Instruktionen, Entscheidungsprotokolle, Kundenkontext, Kampagnen-Logs und Regeln, die aus Fehlern entstanden sind. Der Code ist das kleinere Nebenprodukt.

Drei Dinge verändern sich spürbar, sobald das Ritual sitzt:

Onboarding neuer Kunden wird kürzer, nicht länger. Jeder neue Account startet mit dem gesammelten Regelwerk aus allen Accounts davor. Die Eigenheiten der Plattform, die Fallstricke in der Attribution, die Formate, die intern akzeptiert sind: alles schon da. Was bleibt, ist der kundenspezifische Teil.

Die Fehler werden interessanter. Wenn dieselben fünf strukturellen Fehler nicht mehr passieren, bleiben die Fälle übrig, die wirklich Urteilsvermögen brauchen. Das ist ein besseres Problem als das, mit dem man gestartet ist.

Übergaben werden möglich. Ein Kollege, der eine Session in einem Projekt übernimmt, das er nicht selbst aufgesetzt hat, liest dieselben Dateien wie der Agent. Der Kontext ist nicht mehr in einem Kopf. Er ist im Repo.

Der Punkt, den wir dabei unterschätzt haben: Diese Dateien sind nicht nur für die KI wertvoll. Sie sind das einzige Dokument, das tatsächlich beschreibt, wie wir Entscheidungen treffen, weil es der einzige Ort ist, an dem wir uns gezwungen haben, das Warum mitzuschreiben.

Die drei Fehler, die wir selbst gemacht haben

Ehrlichkeitshalber, denn das lief nicht von Anfang an sauber.

1. Zu viel geschrieben

Die erste Version unserer projektbezogenen Instruktionsdateien war ein Protokoll von allem. Jede Session hinterließ Spuren, auch die, in denen nichts Neues gelernt wurde. Das Ergebnis: Dateien, die zu lang waren, um noch nützlich zu sein, und in denen die drei wirklich wichtigen Regeln zwischen dreißig belanglosen untergingen.

Der Fix war eine höhere Hürde. Eine Regel kommt rein, wenn sie sich mindestens einmal als Fehler manifestiert hat oder wenn sie eine bewusste, nicht-offensichtliche Entscheidung dokumentiert. Alles andere bleibt draußen.

2. Regeln ohne Grund geschrieben

Frühe Einträge waren reine Anweisungen. "Immer X machen." Das funktioniert, solange die Situation exakt der entspricht, in der die Regel entstanden ist. Sobald ein Sonderfall auftaucht, hat der Agent keine Basis zu entscheiden, ob die Regel hier überhaupt gemeint war.

Seitdem steht bei jeder nicht-trivialen Regel ein knapper Grund dabei. Ein Satz reicht. Der Unterschied im Verhalten an den Rändern ist größer, als man erwarten würde.

3. Live-Zahlen in permanente Dateien geschrieben

Der teuerste der drei. Budgets, aktive Kampagnenlisten, Zwischenstände. Alles fühlte sich beim Schreiben nützlich an und war zwei Wochen später falsch. Schlimmer noch: Es sah weiterhin autoritativ aus, weil es in derselben Datei stand wie die Regeln, die tatsächlich stimmten.

Die Regel, die daraus wurde: Wenn eine API, ein Dashboard oder ein Kommandozeilen-Tool dir den Wert live sagen kann, gehört er nicht in die Datei. Die Datei hält die Entscheidung und die Begründung. Der Live-Stand wird zur Laufzeit geholt. Widersprechen sich beide, gewinnt der Live-Stand, und die Zeile in der Datei wird korrigiert.

Häufige Fragen zu KI-Agenten und Kontextdateien

Wo sollte ich Korrekturen für KI-Agenten speichern?

In der Kontextdatei, die der Agent automatisch zu Beginn einer Session liest. In der Praxis heißt das: eine projektbezogene Instruktionsdatei für alles, was zu genau einer Codebase oder einem Kunden gehört, und eine übergeordnete, geteilte Datei für Konventionen, die über alle Projekte hinweg gelten. Der konkrete Mechanismus ist weniger wichtig als die Tatsache, dass die Datei automatisch gelesen wird und nicht etwas ist, das du dich erinnern musst, hineinzukopieren.

Wie oft sollte ich diese Dateien aktualisieren?

Am Ende jeder Session, in der etwas Nicht-Offensichtliches korrigiert oder bestätigt wurde. Das muss nicht jede Session sein, die meisten Aufgaben bringen keine neue Lektion hervor. Aber "mach ich später" ist genau der Weg, auf dem diese Gewohnheit leise verschwindet.

Ist das nicht einfach Dokumentation?

Es ist eine spezifische, engere Form davon. Nicht was das System tut (das lässt sich aus dem Code oder der Plattform selbst ableiten), sondern was der KI-Agent wissen muss und sich nicht selbst herleiten kann: Entscheidungen, Korrekturen und die Begründung dahinter. Klassische Dokumentation beschreibt den Ist-Zustand. Eine Kontextdatei beschreibt Urteile.

Was ist das Risiko, zu viel in diese Dateien zu schreiben?

Eine aufgeblähte Kontextdatei wird zu Rauschen, durch das der Agent bei jeder Aufgabe muss. Und veraltete Live-Daten (aktuelle Zahlen, laufende Listen), die niemand pflegt, werden aktiv irreführend. Halte die Datei auf dauerhaften Entscheidungen und deren Begründung, nicht auf einem laufenden Protokoll von allem, was passiert ist.

Funktioniert das auch mit anderen Tools als Claude Code?

Ja. Das Prinzip ist unabhängig vom Werkzeug: Es braucht nur einen Ort, den der Agent zuverlässig und automatisch liest, bevor er anfängt zu arbeiten. Wie dieser Ort heißt und in welchem Format er vorliegt, ist zweitrangig. Entscheidend ist, dass niemand ihn manuell in den Kontext schieben muss, denn genau dieser Schritt wird unter Zeitdruck übersprungen.

Lohnt sich das auch, wenn ich alleine arbeite?

Gerade dann. Bei einem Team gibt es wenigstens die Chance, dass eine Konvention mündlich weitergegeben wird. Wenn du allein arbeitest, ist die Kontextdatei der einzige Ort, an dem eine Entscheidung von vor drei Monaten überhaupt noch existiert. Und dein zukünftiges Ich erinnert sich schlechter, als du gerade glaubst.

Das Wichtigste in Kürze

Korrekturen an KI-Agenten verschwinden standardmäßig, sobald eine Session endet, außer sie stehen in einer Datei, die der Agent beim nächsten Mal automatisch liest.
Die Gewohnheit, die sich aufsummiert: zwei Minuten am Ende einer Session, in denen du die konkrete, verallgemeinerbare Lektion (keine Zusammenfassung) in die passende Kontextdatei schreibst.
Protokolliere Bestätigungen, nicht nur Korrekturen. Ein ungewöhnlicher Ansatz, den du ohne Widerspruch freigegeben hast, ist genauso erhaltenswert wie ein Fehler, den du behoben hast.
Niemals Live-Systemzustand in eine permanente Datei (aktuelle Budgets, laufende Listen, Zahlen von heute). Er wird schal, und schal plus vertraut ist schlechter als gar nicht vorhanden.
Das schlägt bessere Prompts, weil du die "die KI lernt unsere Konventionen noch"-Steuer einmal pro Fehler zahlst statt unbegrenzt weiter.
Bei uns sind in sechs Wochen 972 Markdown-Dateien gegen 220 TypeScript-Dateien entstanden. Der Output einer AI-native Operation ist überwiegend Kontext, nicht Code.

Wenn du KI-Agenten quer durch deine eigene Operation fährst und die Gedächtnis- und Kontextarchitektur von Tag eins eingebaut haben willst, statt sie nach Monaten wiederholter Korrekturen nachzurüsten: Genau diese Art von AI-native Setup-Arbeit machen wir. Buch dir ein kostenloses Erstgespräch, und wir zeigen dir die Struktur dahinter.