KI-Agenten sind Ihrem Team beigetreten. Ihr Verbesserungszyklus hat dies noch nicht registriert.

In diesem Leitfaden geht es darum, etwas, das Teams bereits kennen – den Zyklus der kontinuierlichen Verbesserung –, auf etwas Neues anzuwenden: die Arbeit, die Ihr Team derzeit mit KI-Agenten leistet. Da wir Software für Retrospektiven entwickeln, ist diese Herangehensweise diejenige, mit der wir am besten vertraut sind; der darin beschriebene Zyklus lässt sich mit allen Tools und Ritualen umsetzen, über die Sie bereits verfügen.

Möchten Sie zunächst die 10-Minuten-Version lesen? Beginnen Sie mit dem Schnellstart-Beitrag Feedback von KI-Agenten einholen, und kehren Sie anschließend hierher zurück, um sich einen umfassenden Überblick zu verschaffen.

Der älteste Trick in der Teamarbeit

Jede Methode, die Ihr Team einsetzt, um sich zu verbessern, ist eine Variante eines Kreislaufs: die Arbeit erledigen, überprüfen, wie es gelaufen ist, etwas ändern, überprüfen, ob die Änderung geholfen hat. Deming übertrug dies auf die Fertigung als „Plan–Do–Check–Act“; Toyota machte es zu einem Teil seiner Unternehmenskultur und nannte es „Kaizen“; in der Softwareentwicklung wurde daraus ein festes Ritual. Norm Kerths Project Retrospectives (2001) machte die Retrospektive für Softwareteams populär, und das agile Manifest verankerte sie als Prinzip: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an“ (Prinzip 12). Schuldfreie Nachbesprechungen durchlaufen denselben Zyklus bei Vorfällen; die Kampagnenauswertung eines Medienteams und die Triage-Überprüfung eines Support-Teams wenden diesen Zyklus an, ohne jemals das Wort „agil“ zu verwenden.

Der Kreislauf funktioniert aufgrund einer Prämisse: Arbeit liefert Erkenntnisse darüber, wie sich die Arbeit verändern sollte. Teams, die diese Erkenntnisse nutzen, erzielen einen Synergieeffekt: Jeder Zyklus verbessert den nächsten. Teams, die dies nicht tun, wiederholen sich.

Siebzig Jahre lang stammten die Hinweise von Menschen. Die Menschen bemerkten die Reibung, beschwerten sich in der Mittagspause und sprachen das Thema im Retro an. Die Sensoren des Kreislaufs waren Menschen.

Eine neue Art von Arbeitnehmer

Irgendwann in den letzten zwei Jahren hat Ihr Team begonnen, echte Aufgaben an eine neue Art von Mitarbeitern zu delegieren. KI-Agenten schreiben und prüfen mittlerweile Code, prüfen Werbekonten, entwerfen Support-Antworten, erstellen Berichte und migrieren Inhalte. Und diese Arbeitskraft weist ein ungewöhnliches Profil auf: unermüdlich, schnell, kompetent und kontextarm. Rahul Gargs Formulierung hat sich in der Branche als Kurzform durchgesetzt: „KI-Assistenten sind wie Nachwuchsentwickler mit unendlicher Energie, aber ohne jeglichen Kontext“, weshalb „die durch KI-generierten Code eingesparte Zeit oft durch den Aufwand aufgezehrt wird, der für dessen Korrektur erforderlich ist“ (Patterns for Reducing Friction in AI-Assisted Development).

Diese Korrekturkosten sind Reibungsverluste, und die Arbeit von Mitarbeitern verursacht sie ständig: der mehrdeutige Auftrag, der eine Vermutung erzwang; das Dokument, das nicht vorhanden war; die Kontostruktur, die bei jeder Sitzung Probleme bereitet; das Tool, bei dem die Zeit ablief; die Anforderung, die sich mitten in der Aufgabe änderte. Nichts davon ist neu. Menschliche Arbeit führt zu derselben Liste. Zwei Aspekte daran sind jedoch neu.

Der neue Mitarbeiter beschwert sich in der Mittagspause nicht. Ein Mitarbeiter stößt auf ein Hindernis, findet einen Weg, es zu umgehen, und macht weiter. Er ist nicht frustriert genug, um das Problem bei der Retrospektive am Freitag anzusprechen. Das Signal, auf das sich Ihr Verbesserungskreislauf stets verlassen hat (dass jemand die Reibungspunkte im Auge behält, bis sie im Rahmen einer Zeremonie aufgegriffen werden), wird nicht ausgelöst.

Und die Anhaltspunkte verflüchtigen sich. Wenn die Sitzung endet, geht der Kontext der Reibung mit ihr verloren. Die nächste Sitzung (nächste Person, derselbe Mitarbeiter) stößt erneut auf dieselbe Hürde. Sie können Anhaltspunkte, die Sie nie erfasst haben, nicht weiter auswerten; der Kreislauf versiegt still und leise, während die Arbeit auf den ersten Blick einwandfrei erscheint.

Die Situation lässt sich also ganz einfach so zusammenfassen: Ein wachsender Anteil der Arbeit Ihres Teams liefert nun Belege für Verbesserungen, für deren Erfassung Ihr Verbesserungskreislauf ursprünglich gar nicht ausgelegt war.

Das Feld nahm dies wahr und baute die Schleife eigenständig wieder auf

Diejenigen, die am engsten mit der Arbeit der Agenten befasst waren, erkannten dies schon früh, und bis Mitte 2026 war „Reibungsverluste bei Agenten erfassen und zurückmelden“ unter mindestens einem halben Dutzend Bezeichnungen zur gängigen Praxis geworden: Gargs Feedback Flywheel, Everys Compound Engineering, Osmanis Loop Engineering, Thoughtworks’ sensor-instrumented harness engineering, die flottenweiten Memory-Loops der Plattformanbieter (OpenAI’s „dreaming“, Factory Signals) sowie GitHubs gh-aw, dessen Workflows zur Sitzungsauswertung bereits automatisierte Berichte zur Sitzungsanalyse erstellen. Selbst die Anbieter greifen auf den Begriff „Retro“ zurück: In den Codex-Leitlinien von OpenAI heißt es: „Wenn Codex denselben Fehler zweimal macht, bitten Sie es um eine Retrospektive und aktualisieren Sie AGENTS.md“ (Best Practices).

Diese Schleifen sind gut. Falls Ihr Team eine davon verwendet, behalten Sie sie bei; alles in diesem Leitfaden baut auf ihnen auf, anstatt sie zu ersetzen. Beachten Sie jedoch zwei Lücken.

Zunächst zur Praxislücke: Beobachten allein führt nicht zu Verbesserungen. Rund 90 % der Teams erfassen die Abläufe ihrer Agenten; nur etwa 37–52 % werten die gewonnenen Daten systematisch aus (LangChain, Juni 2026). Die meisten Teams verfügen über das Dashboard. Weitaus weniger haben den Regelkreis etabliert.

Zweitens die Formlücke: Nahezu jeder Kreislauf in diesem Bereich verläuft isoliert. Ein Praktiker, der sein persönliches Spielbuch optimiert, eine Plattform, die das Gedächtnis ihrer Flotte kuratiert, ein Observability-Stack, der seine eigenen Traces bündelt. Siebzig Jahre kontinuierlicher Verbesserung zeigen, dass die Synergieeffekte auf der Team-Ebene entstehen: dort, wo die Gesamtübersicht entsteht, wo Prioritäten neu gewichtet werden, wo Prozesse, Dokumente und Budgets Verantwortliche haben. Genau diese Ebene ist das Element, das noch niemand neu aufgebaut hat. Die Berichte liegen vor; der Raum wurde noch nicht gebucht.

Der Aufbau der Schleife

Wenn Ihr Team beschließt, dies zu implementieren, weist der Ablauf mehr bewegliche Teile auf, als es zunächst den Anschein hat. Der Weg, den ein einzelnes Reibungselement zurücklegen muss:

Bühne	Die Frage
Hosting	Wo wird der Agent ausgeführt, und was lässt sich dadurch beobachten?
Erkennung	Wie wird Reibung bemerkt? (Selbstwahrnehmung, ein Überwachungsmechanismus, Telemetrie und menschliche Korrektur, die nach wie vor den dominierenden Sensor darstellt: ~70 % der stillen Ausfälle werden zunächst von einer Person entdeckt)
Instrumentierung	Was bewirkt, dass der Sachbearbeiter dies festhält? (Niemand protokolliert Reibungspunkte, auf die er nicht ausdrücklich hingewiesen wurde.)
Aufnahme	Was beinhaltet ein aussagekräftiger Datensatz, und wo befindet er sich?
Ernte	Wie lassen sich Aufzeichnungen aus zahlreichen Sitzungen und von vielen Personen zusammenführen?
Zusammenfassung	Welche Muster sind von Bedeutung, und auf welcher Ebene ist die jeweilige Korrektur anzusiedeln?
Den Kreislauf schließen	Hat die Maßnahme die Reibung tatsächlich verringert, oder war das nur Show?

Drei Bereiche unterscheiden eine „Loop“ von einem Tagebuch, und jedem davon ist in diesem Leitfaden ein eigenes Kapitel gewidmet:

• Fakten statt Eindrücke. Ein nützlicher Eintrag beschreibt den Moment, nennt eine der Hauptursachen aus einem kleinen, festgelegten Vokabular und schlägt eine Lösung im Umfang eines Tickets vor. Festgelegte Bezeichnungen ermöglichen es, Einträge zu aggregieren: „Die Dokumentation war verwirrend“ lässt sich nicht zählen; acht Einträgemissing-documentation hingegen schon. (Kapitel: Wie ein guter „Friction“-Eintrag aussieht)
• Die Frage nach der Ebene. Jedes wiederkehrende Muster wird auf einer bestimmten Ebene behoben: in einer Notiz, einer Eingabeaufforderung, einer Konfiguration, der Dokumentation, dem Arbeitsmaterial selbst, dem Prozess oder auf übergeordneter Ebene bei einem Anbieter. Wenn Sie die Korrektur auf einer zu niedrigen Ebene vornehmen, tritt das Problem bei allen anderen erneut auf; wenn Sie sie auf einer zu hohen Ebene vornehmen, blähen Sie ein Artefakt auf, das niemand liest. (Kapitel: Wo sollte die Korrektur ansetzen?)
• Urteilsbildung im Raum. Ein gewisses Maß an Reibung ist beabsichtigt: das Review-Gate, das jemand als Kontrollpunkt gewählt hat (eine Zusammenfassung von Ronachers Vortrag auf der AIE Europe: „Reibung ist das, was notwendig ist … um zu steuern“; Thoughtworks warnt nun vor der kognitiven Verschuldung durch eine zu reibungslose Arbeit der Agenten). „Behalten oder streichen“, Prioritäten und bereichsübergreifende Fehlerbehebungen sind Verhandlungsprozesse, keine Berechnungen. Dazu müssen die Verantwortlichen für die Fehlerbehebung in einem gemeinsamen Gespräch zusammenkommen. (Kapitel: Der Bericht existiert. Der Raum nicht.)

Wohin die Geschichte führt

Gargs Kadenzliste für das Schwungrad enthält einen Punkt, der fast schon eine Herausforderung darstellt: „Ein Tagesordnungspunkt in der bestehenden Sprint-Retrospektive: Was hat in diesem Sprint im Zusammenhang mit KI gut funktioniert?“ (martinfowler.com). Das ist der rote Faden, an dem dieser Leitfaden ansetzt. Keine neue Zeremonie, keine von KI geleitete: die Verbesserungsschleife, auf die Ihr Team bereits vertraut, erweitert um den neuesten Mitarbeiter im Team, wobei der Agent als Teilnehmer fungiert: Er liefert die Belege, entwirft die Korrekturen, beantwortet Fragen; das Team behält die Entscheidungshoheit, denn die Korrekturen fließen in Prozesse, Dokumente und Budgets ein, für die Menschen verantwortlich sind und Rechenschaft ablegen.

Und um ganz ehrlich zu sein: Wenn Ihr Team lediglich den Tagesordnungspunkt hinzufügt und darüber spricht (ohne Protokoll, ohne Kennzeichnungen), ist das bereits besser als Schweigen, und bei geringer Nutzung durch die Mitarbeiter mag dies ausreichen. Der Rest dieses Leitfadens befasst sich mit den Maßnahmen, die Sie ergreifen sollten, wenn sich diese Situation immer wieder wiederholt.

Die Kapitel

1. Diese Seite: Warum KI-gestützte Arbeit den Arbeitsablauf benötigt, den Ihr Team bereits nutzt.
2. Die Karte: Feedbackschleifen, Werkzeuge und Ansätze für Agenten: Das Referenzrahmenwerk, das den Lebenszyklus von Reibungen, die in der Fachliteratur benannten Schleifen sowie die verwendeten Klassifizierungsschemata abdeckt. Beginnen Sie hier, wenn Sie top-down denken.
3. So sieht ein guter Reibungsprotokoll ein: Erfassung im Moment, die Bezeichnungen der Grundursachen, die Regeln für nicht zu protokollierende Ereignisse.
4. Wo sollte die Korrektur ansetzen? Das Höhenproblem und die Routingtabelle.
5. Der Bericht existiert. Der Raum hingegen nicht. Warum die Synthese eine Teamzeremonie ist, deren Preis im Vergleich zu ihren Konkurrenten steht.
6. Durchführung der AI-Kooperations-Retrospektive: Der Leitfaden für Moderatoren, einschließlich des 15-minütigen Tagesordnungspunkts, der Vorlage und der Prompt-Karten.
7. In zehn Minuten loslegen: ai-session-retro und ai-retro-brief, die Aufzeichnungs- und Synthese-Endpunkte der Schleife, bereit zur Installation.

Bevorzugen Sie die Kurzfassung? Zwei begleitende Beiträge im Blog: die Schnellstartanleitung, Feedback von KI-Agenten einholen, und der Bericht über unseren ersten eigenen Durchlauf, unsere KI-Teamkollegen nahmen an unserer Retrospektive teil.

Häufig gestellte Fragen

Benötigen KI-Agenten eine eigene, separate Retrospektive?

Nein. Der in diesem Leitfaden beschriebene Ansatz erweitert den Verbesserungskreislauf, den Ihr Team bereits durchführt – oft als einzelner Tagesordnungspunkt im Rahmen der bestehenden Retrospektive –, anstatt eine neue Zeremonie einzuführen. Der Betreuer beteiligt sich, indem er Belege vorlegt und Lösungsvorschläge ausarbeitet; die Entscheidung liegt weiterhin beim Team.

Warum werden Reibungspunkte bei KI-Agenten in normalen Retrospektiven nicht thematisiert?

Dafür gibt es zwei Gründe. Die Spieler beschweren sich nicht: Sie stoßen auf eine Hürde, finden einen Weg, diese zu umgehen, und machen weiter, sodass niemand das Problem in die nächste Spielrunde mitnimmt. Und die Anhaltspunkte verflüchtigen sich: Wenn die Spielsitzung endet, geht der Kontext der Reibungspunkte mit ihr unter, sodass die nächste Spielsitzung erneut auf dieselbe Hürde stößt.

Wir protokollieren bereits unsere Agenten-Traces. Reicht das nicht aus?

Beobachten allein führt nicht zu Verbesserungen. Rund 90 % der Teams erfassen ihre Agent-Traces, doch nur etwa 37–52 % werten die gewonnenen Daten systematisch aus. Die Traces sind Rohmaterial; der Prozess erfordert Disziplin bei der Erfassung, eine Synthese der Ergebnisse sowie ein Forum auf Teamebene, in dem die für die Behebung Verantwortlichen gemeinsam Entscheidungen treffen.

Sollte die KI die Retrospektive selbst durchführen?

Nein. Der Beauftragte ist ein Beteiligter: Er liefert die Belege, entwirft die Korrekturmaßnahmen und beantwortet Fragen. Die Entscheidungsgewalt verbleibt beim Team, da die Korrekturmaßnahmen in Prozesse, Dokumente und Budgets einfließen, für die bestimmte Personen verantwortlich sind und Rechenschaft ablegen.

Was ist die minimal funktionsfähige Version dieser Vorgehensweise?

Fügen Sie Ihrer bestehenden Retrospektive einen Tagesordnungspunkt hinzu (Was hat in diesem Zyklus im Zusammenhang mit KI gut funktioniert?) und tauschen Sie sich darüber aus. Kein Protokoll, keine Etikettierungen. Das ist bereits besser als Schweigen, und bei geringem Einsatz von Agenten mag dies ausreichen. Der Rest des Leitfadens befasst sich mit den Punkten, die Sie hinzufügen, wenn sich dieses Gespräch immer wieder wiederholt.

Wir ziehen es vor, wenn man uns widerspricht, anstatt uns höflich zuzustimmen. Jedes Kapitel endet mit der Frage, was uns umstimmen würde.