So sammeln Sie Feedback von Ihren KI-Agenten

Ein KI-Agent hat diese Woche Code für Sie bereitgestellt. Er hat Ihr Briefing gelesen, die Codebasis durchforstet, stieß auf eine Hürde, bei der die Dokumentation fehlerhaft war, hat sich mit Vermutungen darüber hinweggearbeitet und ist weitergegangen. Dann endete die Sitzung – und alles, was er darüber gelernt hatte, wo Ihr Projekt Schwierigkeiten bereitet, ging damit verloren. Niemand fragte den einzigen Teilnehmer, der gerade eine Stunde in Ihrem Repo verbracht hatte, was das System verlangsamt habe.

Retrospektiven dienen genau dazu, diese Lücke für die Mitarbeiter zu schließen: Das Team trifft sich, benennt, was geholfen hat und was im Weg stand, und setzt daraus Veränderungen um. KI-Agenten leisten mittlerweile echte Arbeit in Ihrem Team – und sie stoßen auf dieselben Reibungspunkte wie Ihre Mitarbeiter, manchmal sogar noch mehr. Die Frage ist also ganz einfach. Wenn ein Agent die Arbeit des Teams erledigt, warum wird er dann nicht in der Retrospektive berücksichtigt?

In diesem Leitfaden geht es darum, diese Stimme einzubringen. Es geht nicht um ein neues Format für Retrospektiven und auch nicht darum, die Beiträge Ihrer Mitarbeiter zu automatisieren – es geht um einen neuen Teilnehmer. Die KI liefert Feedback; Ihr Team entscheidet weiterhin, was dieses Feedback bedeutet. Hier erfahren Sie, wie Sie dieses Feedback sammeln und in die Retrospektive einbinden können, die Sie bereits durchführen.

Warum es sich lohnt, die Erfahrungen Ihres KI-Agenten zu erfassen

Das Argument für ein menschliches „Retro“ lautet, dass Erinnerungen verblassen und gewonnene Erkenntnisse nicht weitergegeben werden. Bei einem KI-Agenten stellt sich das Problem noch akuter dar: Sein Arbeitsgedächtnis verblasst nicht, es löst sich in Luft auf. Sobald eine Sitzung beendet wird, ist der Kontext verloren. Die fehlende README-Datei, von der er sich wünschte, sie wäre vorhanden, die nicht dokumentierte Umgebungsvariable, die Aufgabenstellung, die auf drei verschiedene Arten interpretiert werden konnte – nichts davon wird in die nächste Sitzung übertragen, es sei denn, jemand hält es schriftlich fest.

Und Agenten sammeln eine bestimmte, nützliche Art von Signalen. Im Laufe einer Arbeitsstunde fallen einem Agenten Dinge auf, an denen ein Mensch nur flüchtig vorbeigleitet, da dieser den Kontext bereits im Kopf hat:

• Das Onboarding-Dokument, in dem ein Build-Schritt beschrieben wird, der nicht mehr existiert.
• Da die Funktion an drei Aufrufstellen unterschiedlich verwendet wird, verweist „Follow the Pattern“ auf drei Muster.
• Die Anweisung lautete: „Bereinigen Sie die Konfiguration“, ohne anzugeben, um welche Konfiguration es sich handelte oder in welchem Umfang die Bereinigung erfolgen sollte.
• Die Testsuite, für die ein Dienst ausgeführt werden muss, dessen Start Ihnen jedoch nirgends mitgeteilt wird.

Auch ein menschlicher Entwickler stößt auf solche Probleme, zuckt mit den Schultern, findet einen Weg, sie zu umgehen, und meldet selten etwas – die Schwierigkeiten liegen unterhalb der Schwelle dessen, was „es wert wäre, im Meeting angesprochen zu werden“. Ein Agent wird, wenn er richtig befragt wird, jeden einzelnen Fall melden und die entsprechenden Belege beifügen. Darin liegt der Wert: nicht darin, dass die KI Ihren Prozess besser versteht, sondern darin, dass sie einen frischen Blick darauf wirft – ohne Ego und ohne eine sich im Laufe der Zeit aufgebaute Toleranz gegenüber den kleinen Ärgernissen. Die Zusammenarbeit zwischen Mensch und KI funktioniert am besten, wenn beide Seiten sagen können, was sie ausgebremst hat.

Eine wichtige Einschränkung, bevor wir fortfahren, da sie alles Folgende prägt: Die KI ist ein Teilnehmer, niemals ein Moderator oder Richter. Sie bringt ebenso wie jeder andere Teilnehmer Punkte in die Retrospektive ein. Sie leitet das Meeting nicht, bewertet Ihr Team nicht und entscheidet nicht, was verbessert werden muss. Menschen lesen ihr Feedback, prüfen es auf Plausibilität und entscheiden, was wichtig ist. Solange diese Grenze gewahrt bleibt, bleibt die Praxis intakt; verwischen Sie sie, und Sie haben Ihren Verbesserungsprozess einem Werkzeug überlassen, das keine Verantwortung für das Ergebnis übernehmen kann.

Das Training: eine Rückschau zum Abschluss der Trainingseinheit

Der Mechanismus ist bewusst klein gehalten. Am Ende einer Arbeitssitzung – sei es eine Programmieraufgabe, eine Recherche oder eine Refaktorisierung – schreibt der Agent einen ehrlichen Retro-Eintrag in eine Datei in dem Repository, in dem er gearbeitet hat. Das dauert weniger als eine Minute. Ein Mensch benötigt etwa genauso lange, um den Eintrag auf seine Richtigkeit zu überprüfen. Das ist der gesamte Ablauf.

Ein guter Eintrag besteht aus vier Teilen:

1. Was gut gelaufen ist – die Momente, die es wert sind, festgehalten zu werden, bezogen auf etwas Konkretes, das während der Sitzung geschehen ist. Kein Lob, keine Füllworte. Wenn sich der Punkt nicht auf einen bestimmten Moment beziehen lässt, wird er nicht aufgenommen.
2. Reibungspunkte – Stellen, an denen die Arbeit mühsamer war, als sie hätte sein müssen. Jeder Reibungspunkt wird mit einer von zehn festgelegten Ursachenbezeichnungen (siehe unten) versehen und – das ist die Regel, die ihn nützlich macht – endet mit einem „→ Beheben:“ in Ticketgröße. Keine Feststellung ohne Lösung.
3. Eine „Das sollten Sie zuerst tun“-Lösung – die eine Änderung, die am meisten geholfen hätte. Ein Punkt, der ganz oben steht, damit ein vielbeschäftigter Leser, der sonst nichts liest, genau das liest, worauf es ankommt.
4. Getroffene Vermutungen – jede Stelle, an der der Agent eine Lücke mit einer Annahme gefüllt hat. Diese sind von unschätzbarem Wert. Eine Vermutung ist eine Stelle, an der Ihr Kontext mehrdeutig war oder fehlte; der Agent zeigt Ihnen genau, wo er eine Antwort erfinden musste.

Zwei Grundsätze sorgen dafür, dass die Beiträge vertrauenswürdig bleiben. Ausschließlich belegte Sachverhalte – jeder Punkt bezieht sich auf etwas, das tatsächlich geschehen ist, sodass niemand allgemeine Ratschläge liest. Und die Ehrlichkeit gilt in beide Richtungen: Der Bearbeiter kritisiert sowohl das ihm übergebene Material als auch seine eigenen Fehler. Ein Eintrag, der ausschließlich die Codebasis kritisiert und niemals zugibt: „Ich habe das falsch gelesen und zwanzig Minuten verschwendet“, ist nicht ehrlich; diese Vorgehensweise verlangt beides.

Die zehn Bezeichnungen für die Grundursachen

Jedes Reibungsproblem erhält genau eine Bezeichnung. Ein festes, kleines Vokabular verwandelt einen Haufen einzelner Beschwerden in ein Muster, auf das Sie reagieren können: Wenn dieselbe Bezeichnung in zehn Sitzungen auftaucht, wissen Sie, womit Sie Ihre nächste Stunde verbringen sollten. Die zehn Bezeichnungen decken die Arten ab, wie echte Arbeit blockiert wird.

Bezeichnung	Was das bedeutet	Wo die Korrektur in der Regel ansetzt
ambiguous-instruction	Der Auftrag lässt sich auf verschiedene Weisen interpretieren.	Die Person, die die Aufgabe verfasst
missing-context	Die Informationen, die der Sachbearbeiter benötigte, wurden nicht bereitgestellt.	Die Aufgabenstellung bzw. der gemeinsame Kontext
incorrect-context	Die bereitgestellten Informationen waren falsch oder veraltet.	Die Aufgabenstellung bzw. der gemeinsame Kontext
missing-documentation	Im Repo fehlt eine Dokumentation, die eigentlich vorhanden sein sollte.	Die Dokumentation / CLAUDE.md / AGENTS.md
incorrect-documentation	Die Dokumente sind zwar vorhanden, aber fehlerhaft oder veraltet.	Die Dokumentation / CLAUDE.md / AGENTS.md
codebase-friction	Der Code selbst erschwerte die Änderung – eine verworrenen Struktur, keine nahtlosen Übergänge.	Der Code-Bestand / der Rückstand bei den technischen Schulden
missing-access-or-tool	Es standen keine Anmeldedaten, Berechtigungen oder Tools zur Verfügung.	Betrieb / Plattform / Zugriffskontrolle
agent-error	Der Mitarbeiter hat sich geirrt – falsch gelesen, falsche Abzweigung, vergebliche Mühe.	Der Bericht des Agenten selbst, ehrlich gesagt
changed-requirements	Das Tor wurde im Verlauf der Trainingseinheit versetzt.	Planung / Umfangsmanagement
environment-friction	Die Entwicklungsumgebung machte uns das Leben schwer – unzuverlässige Builds, langsame Einrichtung, fehlerhafte Tools.	Entwicklererfahrung

Beachten Sie, wie die Bezeichnungen die Verantwortlichkeiten klar voneinander abgrenzen. Einige verweisen auf Sie — ambiguous-instruction, missing-context. Andere verweisen auf das Projekt — missing-documentation, codebase-friction, environment-friction. Undagent-error verweist auf den Ausführenden. Genau diese Streuung ist der springende Punkt: Sie verhindert, dass das Protokoll zu einer Liste von Beschwerden wird, und macht es stattdessen zu einer Übersicht darüber, wo auf allen Seiten Verbesserungsbedarf besteht.

Das Protokoll: reines Markdown, in Ihrem Repo

Für den Erfassungsschritt muss kein Produkt installiert werden. Der Agent schreibt die Datendocs/ai-retros/entries/als reines Markdown in , das zusammen mit dem Code committet wird. Dies ist eine bewusste Entscheidung:

• Es befindet sich dort, wo die Arbeit stattgefunden hat. Die Unstimmigkeit lag in diesem Repo; ebenso wie die Aufzeichnung darüber. Jeder, der den Git-Verlauf liest, sieht das Feedback direkt neben der Änderung, die dazu geführt hat.
• grepEs lässt sich vergleichen und mit grep durchsuchen. Möchten Sie allemissing-documentationEinträge des letzten Monats? Das ist kein Problem. Möchten Sie sehen, wie der Friction-Trend nach der Behebung des Build-Fehlers sinkt? Das finden Sie in der Versionskontrolle.
• Es ist toolunabhängig. Markdown in einem Ordner funktioniert mit jedem Agent, jedem Editor und jedem Prozess. Keine proprietären Lösungen, nichts, was später migriert werden müsste.

Hier ist ein anschauliches Beispiel – es handelt sich um eine fiktive Sitzung, die der Veranschaulichung dient, und nicht um echte Fluggastdaten:

# Session retro — add rate limiting to the public API
Agent: Claude Code · 2026-07-13 · ~50 min

## Do this first
→ Fix: Document the Redis connection setup in CLAUDE.md — three of us
  will hit this same wall. (missing-documentation)

## What went well
- The `middleware/` folder has a clear pattern; the existing auth
  middleware was a clean model to copy for the rate limiter.
- Tests ran fast once the service was up.

## Friction
- Nothing documented that the test suite needs Redis running locally.
  Spent ~15 min chasing a connection error before finding it by reading
  docker-compose.yml. (missing-documentation)
  → Fix: Add a "Running tests locally" section to CLAUDE.md naming the
    Redis dependency and the `docker compose up redis` command.
- The brief said "add sensible rate limits" without numbers. I chose
  100 req/min per key. (ambiguous-instruction)
  → Fix: Decide the real limits with the team and put them in the ticket.
- `config/limits.ts` and `config/throttle.ts` both looked like the right
  home for the setting; I couldn't tell which was canonical. (codebase-friction)
  → Fix: Merge or clearly comment which config owns rate limiting.

## Guesses I made
- Assumed 100 req/min because the payment endpoints use that. May be
  wrong for read-heavy public endpoints — please check.
- Assumed rate-limit responses should be 429 with a Retry-After header.

Betrachten Sie dies als Notiz eines Teilnehmers, denn genau das ist es. Sie ist konkret, enthält eigene Vermutungen, und für jedes Problem wird ein nächster Schritt aufgezeigt.

Einbeziehung in Ihre Team-Retrospektive

Die einzelnen Einträge bilden das Ausgangsmaterial. Vor Ihrem Retro-Meeting liest ein begleitender Syntheseschritt die seit dem letzten Mal eingetragenen Einträge aus und erstellt eine einseitige Zusammenfassung für das Meeting: die immer wieder auftretenden Reibungspunkte, die wichtigsten Lösungen, gruppiert nach Bezeichnungen, sowie die Vermutungen, die an derselben Stelle immer wieder auftauchen. Es unterliegt denselben Maßstäben wie die Einträge – kein Lob und keine Füllwörter, keine Feststellung ohne Lösungsvorschlag – und seine Ehrlichkeit gilt in beide Richtungen: Es kritisiert die ihm vorgelegten Einträge (dünne Belege, ein Lösungsvorschlag, der zu vage ist, um umgesetzt zu werden) ebenso bereitwillig, wie es sie zusammenfasst.

Dann der menschliche Aspekt, der sich nicht ändert:

1. Lesen Sie die Zusammenfassung vor der Retrospektive – betrachten Sie sie als eine weitere Vorbereitung der Teilnehmer und nicht als Tagesordnung.
2. Hängen Sie die obersten ein oder zwei Punkte an die Tafel, direkt neben das, was Ihre Mitarbeiter mitgebracht haben. Nun steht die Notiz dermissing-documentation KI neben dem Eintrag eines Teamkollegen „Die Einarbeitung hat eine Woche gedauert“ – und Sie können erkennen, dass es sich um dasselbe Problem handelt.
3. Besprechen Sie die Angelegenheit im Team und treffen Sie gemeinsam eine Entscheidung. Der Agent hat das Thema zur Sprache gebracht; die Anwesenden entscheiden nun, wie es weitergeht. Manche Punkte werden Sie umsetzen, andere zurückstellen, bei wieder anderen werden Sie anderer Meinung sein. Das ist völlig in Ordnung – so leistet ein Teilnehmer einen Beitrag, statt dass ein System etwas vorschreibt.

Es gibt zwei Möglichkeiten, diesen letzten Schritt abzuschließen, und die erste davon ist kostenlos:

• Mit jedem beliebigen Retro-Tool. Die Aufgabenstellung ist lediglich ein Dokument. Lesen Sie sie vor der Besprechung durch und fügen Sie den oder die wichtigsten Punkte zu dem von Ihnen verwendeten Board hinzu – Haftnotizen eingeschlossen. Das gesamte Verfahren funktioniert von Anfang bis Ende auf diese Weise, ganz ohne TeamRetro oder ein anderes spezifisches Produkt.
• [AI retro]Bei TeamRetro veröffentlicht der Agent die Beiträge selbst. Wenn Ihr Team seine Retros in TeamRetro durchführt, kann der Agent seine Empfehlungen anhand des Protokolls vorbereiten und – nach Ihrer Bestätigung zu jedem einzelnen Punkt – über den TeamRetro-MCP-Server veröffentlichen: zurückgestellte Punkte, die für Ihre nächste Retrospektive in die Warteschlange gestellt wurden, Maßnahmen, bei denen eine Lösung bereits einen Verantwortlichen hat, oder Ideen, die direkt auf das Running Board eingetragen werden. Jedem geposteten Punkt wird ein Präfix vorangestellt, sodass die Teilnehmer im Raum erkennen können, welcher Teilnehmer ihn eingebracht hat. Das ist der Unterschied in einem Satz: Anstatt dass Sie das Feedback der KI in die Besprechung einbringen, reicht der Teilnehmer es selbst ein.

In etwa 10 Minuten loslegen

Das gesamte Projekt ist als Open Source unter einer MIT-Lizenz verfügbar. Das teamretro-skills-Repo deckt beide Vorgehensweisen ab:ai-session-retro (schreibt den Eintrag zum Abschluss der Sitzung) undai-retro-brief (fasst Einträge zum „Pre-Retro“-Briefing zusammen) benötigen überhaupt kein Produkt, undteamretro-post-recommendations ergänzt den Veröffentlichungspfad für TeamRetro-Teams. Ein toolunabhängiges Prompt-Paket rundet das Ganze ab.

Zunächst einmal:

1. Klonen Sie das Repo und fügen Sie die Skills in Ihre Claude-Code-Konfiguration ein, oder übernehmen Sie das Prompt-Paket, falls Sie mit einer anderen Plattform arbeiten.
2. Sie nutzen Claude Code nicht? Das Prompt-Paket ist so konzipiert, dass es mit Cursor, GitHub Copilot oder jedem anderen Agenten funktioniert, dem Sie einen System-Prompt übermitteln können – derselbe vierteilige Eintrag, dieselben zehn Bezeichnungen, dasselbe Prinzip „keine Ergebnisse ohne Lösung“.
3. Führen Sie eine Sitzung damit durch. Lesen Sie am Ende den Eintrag, den das Programm erstellt hat. Beim ersten Lesen macht es meist „Klick“ – der Agent wird etwas an Ihrem Projekt benannt haben, das Sie zwar vage wussten, aber nie aufgeschrieben haben.

Verweisen Sie die Einträge auf einendocs/ai-retros/entries/Ordner in dem Repository, in dem Ihre Agenten arbeiten, führen Sie ein Commit durch, und schon können Sie loslegen.

Ehrliche Einschränkungen

Es handelt sich um eine junge Praxis, die Vertrauen gewinnt, indem sie offen zugibt, was sie nicht leisten kann.

• Eine KI kann nicht alle ihre eigenen Fehler erkennen. Mancheagent-error Reibungspunkte sind für den Agenten, der sie verursacht hat, unsichtbar – er weiß nicht, was er nicht weiß. Die Überprüfung durch Menschen ist kein optionales Extra; erst so lassen sich die blinden Flecken aufdecken. Aus diesem Grund bleibt die KI ein Teilnehmer und niemals der Richter.
• Ein Eintrag ist eine Anekdote. Sie benötigen etwa fünf Einträge, bevor die Muster aussagekräftig werden. Reibungsverluste in einer einzelnen Sitzung könnten einfach nur Pech in dieser Sitzung sein; dieselbe Kennzeichnung fünfmal hintereinander ist hingegen ein Signal. Warten Sie ein paar Wochen ab, bevor Sie weitreichende Schlussfolgerungen ziehen.
• Der Agent berichtet von seinen Erfahrungen, nicht von der tatsächlichen Situation. Wenn er angibt, dass die Dokumentation falsch ist, überprüfen Sie dies bitte – manchmal ist die Dokumentation korrekt und der Agent hat sie falsch interpretiert. Das ist zwar ebenfalls nützlich (es bedeutet, dass die Dokumentation leicht falsch interpretiert werden kann), erfordert jedoch eine andere Lösung.
• Unsinnige Vorgaben führen zu unsinnigen Einträgen. Diese Vorgehensweise bringt Reibungspunkte ans Licht; sie schafft keine Erkenntnisse, wo zuvor keine vorhanden waren. Eine Sitzung mit einer klaren Vorgabe und einem übersichtlichen Repo führt zu einem kurzen, langweiligen Eintrag – und genau das ist richtig so.

Nichts davon schwächt Ihre Argumentation. Ihre KI-Agenten erledigen die Arbeit bereits und stoßen dabei bereits an Grenzen. Die einzige Frage ist, ob Sie davon erfahren. Geben Sie ihnen am Ende der Sitzung eine Minute Zeit, um Ihnen davon zu berichten, lesen Sie die Rückmeldungen mit menschlichem Urteilsvermögen durch und bringen Sie die ehrlichen Aspekte in die Retrospektive ein, die Sie ohnehin bereits durchführen – direkt neben Ihren Mitarbeitern, wo das Feedback der Teilnehmer hingehört.

---

Möchten Sie erfahren, was geschah, als wir dies mit unserem eigenen Team ausprobiert haben? Lesen Sie „Unsere KI nahm an unserer Retrospektive teil – das hat sie uns gesagt“. Erstellen Sie Kontextdateien für Ihre Mitarbeiter? Erfahren Sie, warum „Context Engineering eine Feedbackschleife benötigt“. Und wenn Sie noch keine Erfahrung mit der Durchführung von Retrospektiven haben, beginnen Sie mit „So führen Sie eine agile Retrospektive durch“.