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 seinen Weg daran vorbei erraten 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 Repo 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 hinzuzufügen. Es geht nicht um ein neues Format für Retrospektiven und auch nicht darum, die Beiträge Ihrer Mitarbeiter zu automatisieren, sondern um einen neuen Teilnehmer. Die KI liefert Feedback; Ihr Team entscheidet weiterhin, was damit gemeint ist. Hier erfahren Sie, wie Sie dieses Feedback sammeln und in die Retrospektive einbinden können, die Sie bereits durchführen.

Dieser Beitrag dient als Schnellstart. Zu diesem Thema liegt nun ein vollständiger Leitfaden vor: Retrospektiven mit KI-Agenten, der den gesamten Zyklus von der Erfassung bis zur Teamzeremonie abdeckt; beginnen Sie hier und lesen Sie dort weiter, um sich einen umfassenden Überblick zu verschaffen.

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 ist das Problem noch ausgeprägter: Sein Arbeitsgedächtnis verblasst nicht, es löst sich in Luft auf. Sobald eine Sitzung beendet wird, ist der Kontext verloren. Nichts davon wird in die nächste Sitzung übertragen, es sei denn, jemand hält es schriftlich fest: die fehlende README-Datei, von der er sich wünschte, sie gäbe es, die nicht dokumentierte Umgebungsvariable, die Aufgabenstellung, die auf drei verschiedene Arten hätte interpretiert werden können.

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 vorbeiguckt, 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 Vorgabe 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 laufen muss, dessen Start Ihnen jedoch nirgends mitgeteilt wird.

Auch ein menschlicher Entwickler stößt auf solche Probleme, zuckt mit den Schultern, findet eine Umgehungslösung und meldet selten etwas, da der Aufwand unterhalb der Schwelle liegt, die es „wert macht, das Thema im Meeting anzusprechen“. Ein Agent wird, wenn er richtig befragt wird, jedes einzelne Problem melden und die entsprechenden Belege beifügen. Darin liegt der Wert: nicht darin, dass die KI Ihre Prozesse besser versteht, sondern darin, dass sie einen unvoreingenommenen Blickwinkel bietet – ohne Ego und ohne angehäufte Toleranz gegenüber den kleinen Ärgernissen. Die Zusammenarbeit zwischen Mensch und KI funktioniert am besten, wenn beide Seiten angeben können, was sie ausgebremst hat.

Eine wichtige Vorbemerkung, bevor wir fortfahren, denn sie prägt alles, was folgt: Die KI ist ein Teilnehmer, niemals ein Moderator oder Richter. Sie liefert Beiträge zur Retrospektive, so wie es jeder Teilnehmer tut. 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 Sie diese Grenze einhalten, bleibt die Praxis gesund; verwischen Sie sie, und Sie haben Ihren Verbesserungsprozess einem Tool überlassen, das keine Verantwortung für das Ergebnis übernehmen kann.

Das Training: eine Rückschau zum Abschluss der Trainingseinheit

Der Mechanismus ist bewusst einfach gehalten. Am Ende einer Arbeitssitzung (einer Programmieraufgabe, einer Recherche oder einer Refaktorisierung) schreibt der Agent einen ehrlichen Retro-Eintrag in eine Datei in dem Repository, in dem er gearbeitet hat. Dies dauert weniger als eine Minute. Ein Mensch benötigt etwa ebenso viel Zeit, 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, und die sich auf etwas Konkretes beziehen, das während der Sitzung geschehen ist. Kein Lob, keine Füllworte. Wenn sich der Verweis nicht auf einen bestimmten Moment beziehen lässt, wird er nicht aufgenommen.
2. Reibungspunkte: Bereiche, in denen die Arbeit aufwendiger war, als sie hätte sein müssen. Jeder Reibungspunkt ist mit einer von zehn festgelegten Ursachenbezeichnungen (siehe unten) versehen und endet mit einem „→ Behebung:“ in Ticketgröße – der Regel, die ihn nutzbar macht. Keine Feststellung ohne Behebung.
3. Eine „Das sollten Sie als Erstes 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, das Wesentliche mitbekommt.
4. Getroffene Vermutungen: Jede Stelle, an der der Agent eine Lücke mit einer Annahme gefüllt hat. Diese sind Gold 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 gewährleisten die Vertrauenswürdigkeit der Beiträge. 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 sagt: „Ich habe das falsch gelesen und zwanzig Minuten verschwendet“, ist nicht ehrlich; diese Vorgehensweise verlangt beides.

Die zehn Bezeichnungen für die Grundursachen

Jedes Reibungspunkt 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, auf die echte Arbeit blockiert wird.

Bezeichnung	Was das bedeutet	Wo der Fix normalerweise landet
ambiguous-instruction	Der Auftrag lässt sich auf verschiedene Weisen auslegen.	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 wird etwas nicht dokumentiert, das eigentlich dokumentiert werden sollte.	Die Dokumentation / CLAUDE.md / AGENTS.md
incorrect-documentation	Die Dokumentationen sind zwar vorhanden, jedoch fehlerhaft oder veraltet.	Die Dokumentation / CLAUDE.md / AGENTS.md
work-material-friction	Das zu bearbeitende Material erschwerte die Änderung (verwickelter Code, Account oder Vorlage).	Der Arbeitsrückstand / das Backlog an 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 interpretiert, falsche Entscheidung, 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 zu schaffen: unzuverlässige Builds, langsame Einrichtung, fehlerhafte Werkzeuge.	Entwicklererfahrung

(Version 2 der Fähigkeiten wurde codebase-frictionin umbenanntwork-material-friction; ältere Einträge, die noch die alte Bezeichnung tragen, gelten weiterhin als derselbe Eintrag.)

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, work-material-friction, environment-friction. Und agent-errorverweist auf den Ausführenden. Genau diese Verteilung ist der springende Punkt: Sie verhindert, dass das Protokoll zu einer Liste von Beschwerden wird, und macht es zu einer Übersicht darüber, wo auf allen Seiten Verbesserungsbedarf besteht.

Das Protokoll: reines Markdown, in Ihrem Repository

Für den Erfassungsschritt muss kein Produkt installiert werden. Der Agent schreibt die Daten alsdocs/ai-retros/entries/ 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 war in diesem Repository zu finden; ebenso wie die Aufzeichnung darüber. Wer die Git-Historie liest, sieht das Feedback direkt neben der Änderung, die dazu geführt hat.
• Es lässt sich vergleichen und mit grep durchsuchen. Möchten Sie alle missing-documentationEinträge des letzten Monats? Das ist kein Problemgrep. Möchten Sie sehen, wie die Reibung nach der Behebung des Build-Fehlers abnimmt? Das finden Sie in der Versionskontrolle.
• Es ist toolunabhängig. Markdown in einem Ordner funktioniert mit jedem Agenten, 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 hierbei um eine fiktive Sitzung, die den Aufbau veranschaulichen soll – es liegen keine echten Fliegerdaten vor:

# 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. (work-material-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 zu jeder Aufgabe wird ein nächster Schritt angegeben.

Einbeziehung in Ihre Team-Retrospektive

Die einzelnen Einträge bilden das Ausgangsmaterial. Vor Ihrer Retro-Sitzung liest ein begleitender Synthese-Schritt die Einträge seit dem letzten Mal aus und erstellt eine einseitige Zusammenfassung für das Treffen: 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 oder Füllmaterial, keine Feststellung ohne Lösungsvorschlag), und seine Ehrlichkeit gilt in beide Richtungen: Es kritisiert die 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 Nachbesprechung: Betrachten Sie sie als die Vorbereitung eines weiteren Teilnehmers 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 Notizmissing-documentation der 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 gemeinsam im Team und treffen Sie 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 alles 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 es vor der Besprechung durch und fügen Sie den wichtigsten Punkt oder die beiden wichtigsten Punkte zu dem von Ihnen verwendeten Board hinzu – Haftnotizen eingeschlossen. Die gesamte Vorgehensweise funktioniert auf diese Weise von Anfang bis Ende, ohne TeamRetro oder ein anderes spezifisches Produkt.
• Mit TeamRetro erstellt 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 diese – nach Ihrer Bestätigung zu jedem einzelnen Punkt – über den TeamRetro-MCP-Server veröffentlichen: zurückgestellte Punkte, die für Ihre nächste Retro 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. Jeder gepostete Punkt ist mit einem Präfix versehen[AI retro], sodass die Teilnehmer im Raum erkennen können, welcher Teilnehmer ihn vorgebracht hat. Das ist der Unterschied in einer Zeile: 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 Wege ab: ai-session-retro(schreibt den Eintrag zum Abschluss der Sitzung) und ai-retro-brief(fasst Einträge zum „Pre-Retro“-Briefing zusammen) benötigen keinerlei Produkt, und teamretro-post-recommendationsergä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 eine Systemprompt ü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 in der Regel „Klick“: Der Agent wird etwas an Ihrem Projekt benannt haben, das Sie zwar schon halb wussten, aber nie aufgeschrieben haben.

Verweisen Sie die Einträge auf einen Ordnerdocs/ai-retros/entries/ 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. Manche agent-errorReibungspunkte sind für den Agenten, der sie verursacht hat, unsichtbar. Sie weiß nicht, was sie nicht weiß. Die Überprüfung durch Menschen ist kein optionales Extra; erst dadurch werden die blinden Flecken aufgedeckt. 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önnen einfach 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, prü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 missverständlich ist), erfordert jedoch eine andere Korrektur.
• Unsinnige Vorgaben führen zu unsinnigen Einträgen. Diese Vorgehensweise bringt Reibungspunkte ans Licht; sie schafft keine neuen 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 dies feststellen. Geben Sie ihnen am Ende der Sitzung eine Minute Zeit, um es Ihnen mitzuteilen, 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. Dort gehört das Feedback eines Teilnehmers hin: direkt neben Ihre Mitarbeiter.

Wir haben die gesamte Runde mit unserem eigenen Team absolviert, einschließlich der Agenten. Sehen Sie selbst, was geschah, als unsere KI-Teamkollegen an unserer Retrospektive teilnahmen.

---

Erstellen Sie Kontextdateien für Ihre Agenten? Erfahren Sie, warum Context Engineering eine Feedbackschleife benötigt. Und falls Sie noch keine Erfahrung mit der Durchführung von Retrospektiven haben, beginnen Sie mit So führen Sie eine agile Retrospektive durch.