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 und 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 weitere DateiAGENTS.md, einen Ordner mit Regeln und Konventionen sowie eine Systemprompt, 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 Wirkung, 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 Schreiben des Kontexts, aber keinen Wartungszyklus. Um diese Lücke geht es in diesem Beitrag.

Kontext ist Code, und Code veraltet

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 Notlö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 selbstsicher 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 Wartungszyklus. Das Problem ist, dass die üblichen Methoden 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 liest. Die Veralterung offenbart sich erst im Moment der Nutzung – und zwar demjenigen, der den Code verwendet. Und immer häufiger ist derjenige, der ihn verwendet, kein Mensch.

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 herausgestellt hat. 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 liegt, ungenutzt. 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 im Retro-Modus 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 gekennzeichnet und endet mit einem „→ Beheben:“ in Ticketgröße. Zwei dieser zehn Bezeichnungen beziehen sich direkt auf Ihre Kontextdateien:

• missing-documentation****: Der Mitarbeiter benötigte etwas, das im Projekt hätte dokumentiert sein sollen, was jedoch nicht der Fall war. Dies ist die Zu-schreiben-Liste Ihrer Kontextdatei. Jeder dieser Punkte ist eine Zeile, dieCLAUDE.md Sie zu Ihrer Dokumentation hinzufügen sollten.
• incorrect-documentation****: Die Dokumentationen waren zwar vorhanden, aber fehlerhaft oder veraltet. Dies ist die Zu-beheben-Liste Ihrer Kontextdatei. Jeder dieser Einträge ist eine veraltete Zeile, die der Agent auf die einzige Weise entdeckt hat, wie sie entdeckt werden kann: 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 Wartungsmaßnahmen abgedeckt, die Sie jemals benötigen werden: ambiguous-instruction****, wenn eine Anweisung oder eine Regel auf mehr als eine Weise ausgelegt werden könnte. Das ist der Kreislauf. Sie prüfen Ihre Kontextdateien nicht nach einem festen Zeitplan; Sie lassen sich von den Agenten, die sie verwenden, im Moment der Nutzung genau mitteilen, welche Zeilen zu ändern sind – inklusive der beigefügten Belege –, da die Praxis ausschließlich auf Belegen basiert.

Und es gibt 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 die Rückgabe 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 dort entspricht einer bestimmten Änderung an einer bestimmten Datei. Das 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, die Kontextdateien auf die altbewährte Weise auf dem neuesten Stand zu halten: Planen Sie eine Überprüfung ein, lesen Sie sie von oben bis unten durch und gleichen Sie jede Aussage mit der Realität ab. Das geschieht jedoch selten, und selbst wenn, ist es das falsche Mittel. Wenn man ein Dokument abstrakt liest, lässt sich nicht erkennen, welche Zeilen veraltet sind. Sie wirken 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 tatsächlich fehlerhaft ist, anstatt erneut zu lesen, was bereits in Ordnung ist. Es ist der Unterschied zwischen einem Rauchmelder und einem Rundgang durch das Gebäude, bei dem man nach Rauch sucht.

Dies verstärkt sich zudem noch. Wenn Sie die Punkteincorrect-documentation in dieser Woche beheben, stoßen die Sitzungen der nächsten Woche weniger auf diese Hürde, sodass das Protokoll kürzer wird und sich auf tiefer liegende Probleme verlagert. Ihre Kontextdateien tendieren zur Genauigkeit – nicht, weil jemand sie geprü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 Korrektur.

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 MIT-Lizenz:

• Holen Sie sich die Fähigkeiten und das Prompt-Paket: github.com/TeamRetroHQ/teamretro-skills: eine Claude-Code-Funktion, die den Eintrag zum Abschluss der Sitzung verfasst, eine, die Einträge zu einer Zusammenfassung zusammenfasst, sowie ein toolunabhängiges Prompt-Paket für Cursor, GitHub Copilot oder jeden anderen Agenten, den Sie mit Prompts anweisen können.
• Lesen Sie den vollständigen Leitfaden: So sammeln Sie Feedback von Ihren KI-Agenten behandelt alle zehn Labels, die Überprüfung durch einen Menschen sowie die Art und Weise, wie die Einträge in eine Team-Retrospektive einfließen – nicht nur in Ihre Kontextdateien.
• Erfahren Sie mehr über den Regelkreis selbst: Agent-Feedback-Regelkreise geben einen Überblick über das gesamte Spektrum: den Regelkreis „Erfassen und Beheben“, die Werkzeuge, mit denen er betrieben wird, und wo eine Sitzung in dieses Konzept eingebettet ist.

Eine Nuance, die es zu beachten gilt: Wenn ein Bearbeiter meldet, dass die Unterlagen fehlerhaft sind, sollten Sie dies vor der Bearbeitung überprüfen, da die Unterlagen manchmal korrekt sind und der Bearbeiter sie falsch gelesen hat. Das ist zwar immer noch 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 festlegt, 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 selbst über den TeamRetro-MCP-Server auf Ihrem Board veröffentlichen – von Ihnen bestätigt, mit einem Häkchen versehen [AI retro]und neben den übrigen Verbesserungsvorschlägen Ihres Teams platziert.