Context Engineering erfordert eine Rückkopplungsschleife

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 – eineCLAUDE.mdDatei im Stammverzeichnis des Repositorys, eine AGENTS.mdweitere Datei, 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.

Das 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. Dieser Ansatz hat einen Input – das Verfassen des Kontexts – aber keinen Wartungszyklus. Genau 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 nimmtCLAUDE.md die Anweisungen wörtlich. Wenn dort „run make setup“ steht und dieses Ziel im letzten Quartal gelöscht wurde, zuckt der Agent nicht 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 vorgebrachten 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 Ansätze nicht funktionieren. Sie werden den Code nicht nach einem festen Zeitplan Zeile für Zeile überprüfenCLAUDE.md – das macht niemand. Von außen wird man nicht bemerken, dass er veraltet ist, da er sich einwandfrei liest. Die Veralterung offenbart sich erst im Moment der Nutzung – und zwar demjenigen, der sie nutzt. Und immer häufiger ist derjenige, der sie nutzt, kein Mensch.

Der einzige Zeuge, der Bescheid weiß

Hier liegt der entscheidende Unterschied. Der Agent, der soeben 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. Es hat lediglich die Dateien verwendet. Es hat den veralteten Build-Befehl aufgerufen. Es hat den Ordner gefunden, der nicht existiert. Es ist dem Muster gefolgt, das sich als drei Muster herausstellte. Dieses Wissen existiert – etwa so lange, wie die Sitzung andauert, 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 den Agenten lediglich 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 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 entscheidend ist – jeder Reibungspunkt wird mit einer von zehn festgelegten Ursachenbezeichnungen versehen und endet mit einem „→ Beheben:“ in Ticketgröße. Zwei dieser zehn Bezeichnungen verweisen direkt auf Ihre Kontextdateien:

• missing-documentation**** – Der Mitarbeiter benötigte etwas, das im Projekt hätte dokumentiert werden sollen, was jedoch nicht geschehen ist. Dies ist die Zu-verfassen-Liste Ihrer Kontextdatei. Jeder dieser Punkte ist eine Zeile, die Sie zuCLAUDE.md Ihrer Dokumentation hinzufügen sollten.
• incorrect-documentation**** – Die Dokumentationen existierten zwar, waren jedoch 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 Art und 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 Wartungsarbeiten 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 ü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 – mit den entsprechenden Belegen, da diese Vorgehensweise 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 – denn Sie kennen die Antworten bereits und können daher nicht erkennen, 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 dort entspricht einer bestimmten Änderung an einer bestimmten Datei. Das ist eine Wartungsschleife, die eine Person tatsächlich ausführen wird, da die Arbeit, das Problem zu finden – der aufwendige Teil –, 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. Das 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 das 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.

Dies verstärkt sich zudem. Wenn Sie dieincorrect-documentationPunkte 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 tieferliegende Probleme verlagert. Ihre Kontextdateien tendieren zur Genauigkeit, nicht weil jemand sie geprüft hat, sondern weil die Menschen – und die 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:

• Laden Sie die Skills und das Prompt-Paket herunter: github.com/TeamRetroHQ/teamretro-skills – ein Claude-Code-Skill, der den Eintrag zum Abschluss der Sitzung verfasst, einen, der 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 ansprechen können.
• Lesen Sie die vollständige Anleitung: 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.

Eine Nuance, die es zu beachten gilt: Wenn ein Mitarbeiter meldet, dass die Unterlagen falsch sind, überprüfen Sie diese bitte, bevor Sie Änderungen vornehmen – manchmal sind die Unterlagen korrekt und der Mitarbeiter hat sie falsch gelesen. Das ist zwar immer noch ein nützlicher Hinweis (eine Zeile, die leicht falsch gelesen werden kann, ist eine Zeile, die es wert ist, umgeschrieben zu werden), aber es handelt sich um eine andere Art der Korrektur, und genau deshalb bleibt ein Mensch im Bilde. 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.

[AI retro]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 landen, 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 Markierung versehen, direkt neben den übrigen Verbesserungsvorschlägen Ihres Teams.