Für das Context Engineering ist eine Rückkopplungsschleife erforderlich

Context Engineering ist die Disziplin, einem KI-Agenten die richtigen Informationen in der richtigen Form zum richtigen Zeitpunkt zur Verfügung zu stellen, damit er gute Arbeit leistet, anstatt zu raten. In der Praxis bedeutet dies für die meisten Teams: Dateien – eine Datei imCLAUDE.md Stammverzeichnis des Repositorys, eine DateiAGENTS.md, einen Ordner mit Regeln und Konventionen sowie eine Systemaufforderung, die einmal von jemandem angepasst wurde. Sie halten fest, wie Ihr Projekt funktioniert, damit der Agent dies nicht bei jeder Sitzung neu herausfinden muss.

Es ist wirklich die Maßnahme mit der größten Hebelwirkung, die Sie ergreifen können, um Agenten nützlich zu machen. Und fast jeder, der dies tut, hat dasselbe unausgesprochene Problem: Diese Dateien veralten, und niemand weiß, welche Teile davon betroffen sind. Sie haben den Kontext einmal verfasst, die Codebasis hat sich weiterentwickelt, und nun ist die Hälfte davon stillschweigend falsch. In diesem Bereich gibt es eine Eingabe, das Verfassen des Kontexts, aber keinen Wartungszyklus. Genau um diese Lücke geht es in diesem Beitrag.

Kontext ist Code, und Code verfällt

Wir wissen bereits, dass Dokumentation veraltet. Der von Ihnen dokumentierte Build-Schritt wird ersetzt, der von Ihnen beschriebene Ordner wird umbenannt, die von Ihnen festgehaltene Konvention wird abgelöst, und die Dokumentation beschreibt weiterhin selbstbewusst die alte Welt. Kontextdateien sind in dieser Hinsicht aus zwei Gründen noch problematischer als gewöhnliche Dokumentationen.

Erstens: Ein Agent liest sie wörtlich und handelt entsprechend. Ein Mensch überfliegt eine veraltete README-Datei, spürt, dass etwas nicht stimmt, und fragt jemanden. Ein Agent nimmt die Anweisungen wörtlichCLAUDE.md. Wenn dort „run make setup“ steht und dieses Ziel im letzten Quartal gelöscht wurde, zieht der Agent nicht einfach mit den Schultern. Er verschwendet Zeit damit, das Falsche zum Laufen zu bringen, oder er erfindet eine Umgehungslösung und macht weiter, wobei er die fehlerhafte Anweisung in seine Ausgabe übernimmt.

Zweitens: Ein falscher Kontext ist schlimmer als ein fehlender Kontext. Eine Lücke kann der Agent manchmal umgehen oder kennzeichnen. Einer selbstbewusst vorgetragenen falschen Aussage vertraut er jedoch. Die kostspieligsten Zeilen in Ihren Kontextdateien sind nicht die fehlenden. Es sind jene, die einst wahr waren.

]

Sie benötigen also einen Wartungskreislauf. Das Problem ist, dass die üblichen Ansätze nicht funktionieren. Sie werden nicht nach einem festen Zeitplan CLAUDE.mdZeile für Zeile prüfen. Das macht niemand. Von außen werden Sie nicht bemerken, dass der Code veraltet ist, da er sich einwandfrei lesen lässt. Die Veralterung offenbart sich erst im Moment der Nutzung – und zwar demjenigen, der den Code verwendet. Und zunehmend ist derjenige, der ihn verwendet, kein Mensch mehr.

Der einzige Zeuge, der Bescheid weiß

Hier liegt der entscheidende Unterschied: Der Agent, der gerade eine Sitzung für Ihr Projekt durchgeführt hat, ist der einzige Teilnehmer, der konkret weiß, welche Teile Ihres Kontexts hilfreich waren und welche ihn in die Irre geführt haben. Er hat lediglich die Dateien verwendet. Er hat den veralteten Build-Befehl aufgerufen. Er hat den Ordner gefunden, der nicht existiert. Er ist dem Muster gefolgt, das sich als drei Muster herausstellte. Dieses Wissen besteht etwa so lange wie die Sitzung selbst, und dann ist es verschwunden.

Niemand sagt Ihnen, welcher Kontext fehlt oder falsch ist – außer dem Element, das gerade darunter gelitten hat. Das ist die Rückkopplungsschleife, die genau dort vorliegt, nur darauf wartend, genutzt zu werden. Sie müssen lediglich den Agenten bitten, vor Beendigung der Sitzung aufzuschreiben, was er gelernt hat, und die Anfrage so zu formulieren, dass die Ausgabe direkt auf die Dateien verweist, die bearbeitet werden müssen.

Das Sitzungsprotokoll „Retro“ ist die Wartungsschleife

Genau das ist das Ergebnis einer KI-Retrospektive am Ende einer Sitzung. Am Ende einer Arbeitssitzung verfasst der Agent einen kurzen, ehrlichen Eintrag: Was ist gut gelaufen, wo gab es Reibungspunkte, und – was hier besonders wichtig ist – jeder Reibungspunkt wird mit einer von zehn festgelegten Ursachenbezeichnungen versehen und endet mit einem „→ Beheben:“ in Ticketgröße. Zwei dieser zehn Bezeichnungen beziehen sich direkt auf Ihre Kontextdateien:

• missing-documentation****: Der Sachbearbeiter benötigte etwas, das im Projekt hätte dokumentiert sein sollen, was jedoch nicht der Fall war. Dies ist die Zu-verfassen-Liste Ihrer Kontextdatei. Jeder dieser Punkte ist eine Zeile, dieCLAUDE.md Sie zu Ihrer Dokumentation hinzufügen sollten.
• incorrect-documentation****: Die Dokumentationen existierten zwar, waren jedoch fehlerhaft oder veraltet. Dies ist die Zu-korrigieren-Liste Ihrer Kontextdatei. Jeder dieser Einträge ist eine veraltete Zeile, die der Agent auf die einzige Weise entdeckt hat, wie dies möglich ist: indem er sie verwendet hat und dabei an ihre Grenzen gestoßen ist.

Fügen Sie einen dritten Punkt hinzu, und Sie haben den Großteil der Pflege abgedeckt, die Sie jemals benötigen werden: ambiguous-instruction****, nämlich wenn eine Anweisung oder eine Regel auf mehr als eine Weise ausgelegt werden könnte. Das ist der Kreislauf. Sie überprüfen Ihre Kontextdateien nicht nach einem festen Zeitplan; Sie lassen sich vielmehr von den Agenten, die sie verwenden, im Moment der Nutzung genau mitteilen, welche Zeilen zu ändern sind – einschließlich der beigefügten Belege –, da die Praxis ausschließlich auf Belegen basiert.

Und es gibt noch ein viertes Signal, das leicht zu übersehen ist: die Vermutungen. Ein guter Eintrag listet jeden Punkt auf, an dem der Agent eine Lücke mit einer Annahme gefüllt hat. Jede Vermutung ist eine Stelle, an der Ihr Kontext so lückenhaft war, dass der Agent eine Antwort erfinden musste. Lesen Sie die Vermutungen einer ganzen Woche durch, und Sie erhalten eine To-do-Liste für Ihre Kontextdateien, die Sie selbst niemals hätten erstellen können, da Sie die Antworten bereits kennen und daher nicht erkennen können, wo diese fehlen.

So sieht das Ergebnis aus. Ein anschauliches Beispiel, keine echten Daten:

## Friction
- CLAUDE.md says "run `make setup`" but that target was removed; the
  actual setup is `pnpm install && pnpm db:migrate`. Lost ~10 min.
  (incorrect-documentation)
  → Fix: Update the "Getting started" block in CLAUDE.md to the pnpm commands.
- Nothing documents that integration tests need the worker running.
  Found it by reading the CI config. (missing-documentation)
  → Fix: Add a "Running tests" note naming `pnpm worker` as a prerequisite.

## Guesses I made
- Assumed the `api/` package is the public surface and `internal/` is not,
  because nothing states it. Please confirm before I rely on it again.

Jede Zeile enthält eine spezifische Änderung an einer bestimmten Datei. Dies ist eine Wartungsschleife, die eine Person tatsächlich ausführen wird, da der aufwendige Teil der Arbeit – nämlich das Auffinden des Problems – bereits erledigt ist.

Warum dies einer manuellen Prüfung überlegen ist

Sie könnten versuchen, Kontextdateien auf die altbewährte Weise auf dem neuesten Stand zu halten: eine Überprüfung einplanen, sie von oben bis unten durchlesen und jede Aussage anhand der Realität überprüfen. Dies geschieht jedoch nicht, und selbst wenn, ist es das falsche Mittel. Wenn man ein Dokument abstrakt liest, lässt sich nicht erkennen, welche Zeilen veraltet sind. Sie klingen alle plausibel. Die Veralterung wird erst im Einsatz sichtbar. Das Retro-Protokoll ist eine durch den tatsächlichen Einsatz gesteuerte Kontextpflege: Nur die Zeilen, die tatsächlich einen Agenten ausgelöst haben, werden markiert, sodass Sie das beheben, was wirklich nicht funktioniert, anstatt erneut zu lesen, was bereits in Ordnung ist. Es ist der Unterschied zwischen einem Rauchmelder und dem Durchstreifen des Gebäudes auf der Suche nach Rauch.

Zudem verstärkt sich dieser Effekt. Wenn Sie die Problemeincorrect-documentation in dieser Woche beheben, stoßen die Sitzungen der nächsten Woche weniger häufig an diese Grenze, sodass das Protokoll kürzer wird und sich auf tieferliegende Probleme verlagert. Ihre Kontextdateien werden nicht deshalb immer genauer, weil jemand sie überprüft hat, sondern weil die Menschen und Agenten, die sie nutzen, über eine kostengünstige, strukturierte Möglichkeit verfügten, Abweichungen zu melden. Das ist eine gesunde Zusammenarbeit zwischen Mensch und KI: Der Agent deckt die Abweichung auf, der Mensch entscheidet über die Anpassung. Der gleiche Kreislauf funktioniert auch zwischen Menschen: Wir haben die privaten „Claude Code“-Erinnerungen von fünf Entwicklern gebündelt und die Regeln hervorgehoben, die mehrere von uns unabhängig voneinander niedergeschrieben hatten.

Starten Sie die Schleife

Falls Sie bereits in Context Engineering investieren, ist dies die fehlende Hälfte: der Wartungskreislauf, der verhindert, dass die Investition verpufft. Es handelt sich um Open Source unter der MIT-Lizenz:

• Holen Sie sich die Skills und das Prompt-Paket: „github.com/TeamRetroHQ/teamretro-skills“: ein Claude-Code-Skill, der den Eintrag zum Abschluss der Sitzung verfasst, ein weiterer, der Einträge zu einer Zusammenfassung zusammenfasst, sowie ein toolunabhängiges Prompt-Paket für Cursor, GitHub Copilot oder jeden anderen Agenten, dem Sie Prompts übermitteln können.
• Lesen Sie die vollständige Anleitung: „So sammeln Sie Feedback von Ihren KI-Agenten“ behandelt alle zehn Kategorien, die Überprüfung durch einen Menschen sowie die Art und Weise, wie die Einträge in eine Team-Retrospektive einfließen – und nicht nur in Ihre Kontextdateien.
• Tiefere Einblicke in den Regelkreis selbst: „Agent Feedback Loops“ bietet einen Überblick über das gesamte Spektrum: den Regelkreis „Erfassen und Beheben“, die dafür verwendeten Werkzeuge und die Rolle, die eine Sitzung dabei spielt.

Eine Nuance, die es zu beachten gilt: Wenn ein Bearbeiter meldet, dass die Unterlagen fehlerhaft sind, überprüfen Sie diese bitte, bevor Sie Änderungen vornehmen, denn manchmal sind die Unterlagen korrekt und der Bearbeiter hat sie falsch gelesen. Das ist zwar nach wie vor ein nützlicher Hinweis (eine Zeile, die leicht falsch gelesen werden kann, sollte umformuliert werden), aber es handelt sich um eine andere Art der Korrektur – und genau deshalb bleibt ein Mensch im Prozess involviert. Der Agent ist ein Beteiligter, der darauf hinweist, was ihn gestört hat, niemals jedoch die Instanz, die darüber entscheidet, was in Ihrem Projekt stehen soll.

Ihre Kontextdateien sind nur so gut wie ihre letzte ehrliche Korrektur. Die Agenten, die sie verwenden, übermitteln Ihnen diese Korrekturen am Ende jeder Sitzung. Sie müssen sie lediglich notieren. Und wenn Ihr Team möchte, dass diese Korrekturen an einer Stelle erscheinen, die bereits von allen beachtet wird, kann der Agent seine Empfehlungen vorbereiten und sie über den TeamRetro-MCP-Server selbst auf Ihrem Board veröffentlichen – von Ihnen bestätigt und mit einem Häkchen versehen[AI retro], direkt neben den übrigen Verbesserungsvorschlägen Ihres Teams.