Der Bericht existiert. Der Raum existiert nicht.

Vor kurzem hat ein KI-Agent sechs Einträge auf unserem eigenen Retro-Board hinterlegt.

Der erste lautete: „Überprüfen Sie zunächst, bevor Sie handeln – Fehler bei der Agentenausführung machen 38 % der Reibungsverluste aus (das Doppelte der nächsthäufigsten Ursache); die wiederkehrenden Kosten entstehen dadurch, dass eine Ursache behauptet, ein Push durchgeführt oder eine Neuausrichtung vorgenommen wird, bevor der Live-Code, die Daten oder der Zweigstatus überprüft wurden.“ Dahinter verbargen sich die Musterbelege: Fehler im Zusammenhang mit Git-Zweigstatus bei der Arbeit mit mehreren Agenten über acht Sitzungen und zwei Repositories hinweg; unvollständige Pre-Push-Prüfungen, die die CI in vier Sitzungen zum Absturz brachten, davon zweimal in einem Repository am selben Tag; eine Lücke bei den Test-Mocks, die in einer Sitzung am Vortag gemeldet worden war, mit dem Vermerk, dass die Dokumentation zur Behebung nie verfasst wurde.

Zwei Aspekte dieser Tabelle sind besonders bemerkenswert. Erstens hätte keine einzelne Arbeitssitzung irgendetwas davon als ihr größtes Problem eingestuft: Jeder einzelne Vorfall war ein Achselzucken, ein paar verlorene Minuten, ein Ärgernis, das jemand umgangen hat. Die Rangfolge ergibt sich erst in der Gesamtheit, über alle Sitzungen und Personen hinweg. Zweitens, und das ist noch unangenehmer: Die schwerwiegendsten Punkte betrafen überhaupt nicht den Agenten oder den Code. Sie betrafen uns: Korrekturen, denen wir zugestimmt, aber nicht umgesetzt hatten, sowie immer wiederkehrende Verzögerungen, bei denen „zwischen den einzelnen Sitzungen keine dauerhafte Korrektur bereitgestellt wurde“.

Ein automatisierter Bericht kann Ihnen all dies aufzeigen. Was er jedoch nicht leisten kann, ist, die Verantwortlichen für den Prozess, die Dokumentation, das Budget für die Werkzeuge und die Prioritäten an einen Tisch zu bringen, damit sie gemeinsam entscheiden, wie damit umgegangen werden soll. Der Bericht liegt vor. Der Raum jedoch nicht. In diesem Beitrag geht es um diesen Raum.

Alle haben die Schleife gebaut

Bis Mitte 2026 gilt es als gängige Praxis, „Fehler bei der KI-gestützten Arbeit zu erfassen und als Feedback weiterzugeben“. Dieses Konzept ist unter mindestens sechs Bezeichnungen bekannt, die alle treffend sind. Rahul Gargs Feedback Flywheel nutzt Reibungspunkte aus Arbeitssitzungen, um Einführungsdokumente und Leitlinien zu erstellen. Das Compound Engineering von Every sorgt dafür, dass jede Arbeitseinheit der nächsten als Vorbild dient. Thoughtworks stattet Agenten mit Sensoren aus; Addy Osmani bezeichnet diese Disziplin als Loop Engineering. Die Plattformanbieter schließen den Kreislauf auf Flottenebene: OpenAI’s „Dreaming“, Anthropic’s Kontextkuratierung sowie Factory Signals mit der automatischen Erfassung von Tickets. GitHubs Open-Source-Projekt gh-aw, ein Framework für agentenbasierte Workflows, das in Markdown in natürlicher Sprache verfasst ist, kommt unserem Thema am nächsten: Seine Workflows zur Sitzungsauswertung generieren bereits automatisierte Berichte zur Sitzungsanalyse. Ein öffentliches Beispiel, die automatisierte Analyse von 50 Sitzungen an einem einzigen Tag, kennzeichnet eine Überspringrate von 24 % und eine Erfolgsquote der Ausführenden von 33 % als „Fehler-Signale“.

Falls Sie eine dieser Methoden verwenden: Behalten Sie sie bei. In diesem Beitrag wird nicht vorgeschlagen, eine davon zu ersetzen. Sortieren Sie jedoch die Schleifen nach der Ebene, auf der sie ausgeführt werden, und erkennen Sie das Muster:

Ein Leitfaden für Fachkräfte. Eine Sitzungskonfiguration. Ein Plattformspeicher. Ein Observability-Stack. Eine Anbieterflotte.

Nahezu jeder Zyklus in diesem Bereich ist ein Einzelzyklus: eine Person und ihr Betreuer oder ein Anbieter und dessen Flotte. Gargs „Flywheel“ ist das einzige Konzept, das auf gemeinsame Team-Artefakte abzielt, und seine Kadenzliste enthält einen Punkt, den fast niemand in die Praxis umgesetzt hat: „Bei der Retrospektive: ein Tagesordnungspunkt in der bestehenden Sprint-Retrospektive: Was hat in diesem Sprint im Zusammenhang mit KI gut funktioniert?“ Er nennt den Ort und fährt fort. Das Dogfooding von GitHub hingegen liefert genau den Reibungsbericht, den eine Teamzeremonie als Input wünschen würde, und positioniert ihn schlicht und einfach als technische Beobachtbarkeit.

Eine Art Ausnahme findet sich bei Scrum.org, dessen Reihe zu Hybridteams den Beitrag „Wie man die Sprint-Retrospektive durchführt, wenn die Hälfte Ihres Teams aus KI-Agenten besteht“ enthält. Der Beitrag ist lesenswert, da er die Frage nach dem Rahmen ernst nimmt und anders beantwortet als wir: Ihre Retrospektive wird zu einer datengestützten Debugging-Sitzung, bei der die Metriken der Agenten (Häufigkeit der Prompt-Neuformulierung, Abweichungsraten, Token-Verbrauch) im Mittelpunkt stehen. Das ist eine nützliche Perspektive, und ein Team könnte beides durchführen. Allerdings werden dabei die Agenten überprüft; der Ansatz, um den es in diesem Beitrag geht, befasst sich hingegen mit der Zusammenarbeit: Ursachen statt Symptomen, Korrekturen, die auf die jeweilige Ebene geleitet werden, auf die sie gehören (die Aufgabenstellung, die Dokumentation, den Prozess, das Material), wobei die Agenten ihre eigene Darstellung der Arbeit einbringen, anstatt lediglich als Dashboard zu erscheinen.

Die Lücke liegt nicht in der Technologie. Alle Komponenten (Erfassung, Zusammenführung, Berichterstellung) sind bereits heute verfügbar. Die Lücke liegt in der Praxis: Fast niemand hat bisher dargelegt, was das Team gemeinsam unternimmt, wenn der Bericht vorliegt.

Was benötigt eigentlich einen Raum?

Der erste Impuls ist hier, die Automatisierung weiter voranzutreiben: besseres Clustering, automatisch zugeordnete Korrekturen, ein Dashboard. Für eine große Gruppe von Befunden ist dies richtig, und die oben genannten Pipelines erfüllen diese Aufgabe gut. Listen Sie jedoch die Entscheidungen auf, die der Bericht tatsächlich aufwirft, und beachten Sie deren Struktur:

• Behalten oder streichen. Welche wiederkehrenden Reibungsverluste sind Verschwendung, und welche dienen der bewussten Steuerung? Die Überprüfungsinstanz, die den Agenten verlangsamt, könnte die Leine sein, für die sich jemand entschieden hat (eine Zusammenfassung des Vortrags von Armin Ronacher auf der AIE Europe: „Reibung ist das, was notwendig ist … um zu steuern“); Thoughtworks’ Radar warnt nun vor der kognitiven Verschuldung, die durch das Entfernen von zu vielen Elementen entsteht. Das Löschen eines Kontrollpunkts verändert das Risiko für alle Beteiligten. Das ist per Definition eine Teamentscheidung.
• Wo die Lösung ansetzt. Ein wiederkehrendes Problem lässt sich auf einer bestimmten Ebene: eine persönliche Notiz, eine Anweisung oder Fertigkeit, die Konfiguration der Arbeitsumgebung, die Dokumentation, das Arbeitsmaterial selbst, der Prozess oder auf der übergeordneten Ebene bei einem Anbieter beheben. Diese Elemente haben Verantwortliche, und diese Verantwortlichen sind verschiedene Personen.
• Priorität bei der Aggregation. Fünf Minuten, die pro Person und Sitzung einfach ignoriert werden, sind für den Einzelnen nicht wahrnehmbar, summieren sich jedoch zu erheblichen Kosten für das Team. Um hier Abhilfe zu schaffen (die gemeinsame Vorlage überarbeiten, den Aufnahmevorgang ändern, die Angelegenheit an den Anbieter eskalieren), ist eine Entscheidungsbefugnis erforderlich, über die kein Einzelner verfügt.
• Die Übernahmeprobe. Wurde die Korrektur aus dem letzten Zyklus tatsächlich übernommen, und hat die Reibung aufgehört? Der wertvollste Satz unseres eigenen Boards lautete genau so: gestern markiert, nie geschrieben. Eine Schleife ohne diese Überprüfung ist wie ein Schwungrad, das sich in der Luft dreht.

Keine dieser Maßnahmen ist eine Berechnung. Bei allen handelt es sich um Abstimmungen zwischen Personen, die für unterschiedliche Aspekte der Teamarbeit verantwortlich sind. Einzelkämpfer integrieren diese Entscheidungen zu Recht nach Gefühl; agile Pipelines erstellen zu Recht die maschinenlesbare Teilmenge in maschineller Geschwindigkeit. Die teamweiten Varianten erfordern Menschen in einem Raum, die über ein gemeinsames Vokabular verfügen und die Befugnis haben, die Aufmerksamkeit neu zu verteilen. Das ist keine Pipeline. Das ist eine Zeremonie.

Warum der Retro-Stil oder eine Zeremonie in ähnlicher Form?

Eine vollständige Offenlegung vor der Argumentation: Wir verkaufen Retrospektive-Software. Genau aus diesem Grund stützt sich dieser Abschnitt auf Eigenschaften und nicht auf die Marke: Bitte berücksichtigen Sie dies bei Ihrer Schlussfolgerung und überprüfen Sie die Eigenschaften selbst.

Die Eigenschaften, die die Entscheidungsgruppe erfüllen muss: ein Ort, der regelmäßig stattfindet (chronische kleinere Reibungspunkte lösen niemals ein einmaliges Treffen aus), nach den geltenden Normen frei von Schuldzuweisungen, bereichsübergreifend (die Verantwortlichen für Prozesse, Dokumentation, Werkzeuge und Prioritäten sind anwesend) sowie auf Fakten gestützt sein. Für die meisten Teams ist die Sprint-Retrospektive bereits der Ort, an dem diese vier Eigenschaften gegeben sind: kein neues Meeting, das in einem Kalenderkrieg verteidigt werden muss, und eine Konvention der Schuldfreiheit, die wichtiger ist, als es den Anschein hat, denn der verlockende Fehlermodus ist hier die Postmortem-Analyse, bei der Einzelpersonen die Schuld zugewiesen wird, und die „Harness-Engineering“-Schule lehnt diesen Standard ausdrücklich ab: Der Ingenieur macht das Modell verantwortlich und legt es unter „Auf die nächste Version warten“ ab; Stattdessen sollte man den Harness korrigieren (Osmani, Agent Harness Engineering).

Die ehrliche Formulierung dieser Behauptung bewertet jedoch eher die Konkurrenten, anstatt einen Sieger zu benennen:

• Die Sprintplanung hat im Raum das größte Gewicht, doch ihre Tagesordnung ist zukunftsorientiert und stets überfüllt; die Retrospektive kommt in einem Planungszeitfenster regelmäßig zu kurz. In der Planung werden beschlossene Maßnahmen terminiert, nicht Muster analysiert.
• Die „tadellose Nachbesprechung“ verfügt über genau die richtigen Vorgaben, aber den falschen Auslöser: Sie wird bei großen, punktuellen Fehlschlägen einberufen, niemals jedoch bei dem Muster „fünf Minuten, acht Personen pro Sprint“, das genau das Muster ist, das nur durch eine Gesamtbetrachtung erkennbar wird.
• Asynchron (ein Bericht plus ein Tracker) ist die kostengünstigste Lösung und reicht für die meisten Routineaufgaben aus. Was damit jedoch nicht möglich ist, ist die Entscheidungsfindung: Die Entscheidung „behalten oder streichen“ ist eine Verhandlung, Streitigkeiten über den Prioritätsgrad gehen über Zuständigkeitsgrenzen hinaus, und eine Neugewichtung der Prioritäten erfordert, dass alle Verantwortlichen an derselben Besprechung teilnehmen.
• Die Nullalternative (einfach im Retro über KI sprechen, keine Aufzeichnungen, keine Kennzeichnungen) ist kostenlos, passt zum aktuellen Zeitpunkt und kann für ein kleines Team mit geringem Agenteneinsatz tatsächlich ausreichen. Beginnen Sie damit. Was diese Vorgehensweise jedoch nicht leisten kann, ist die Vergleichbarkeit über Sitzungen hinweg, die Erkennung von Trends oder die Überprüfung der Akzeptanz: Ein Gespräch, das jedes Mal bei Null beginnt. Die im Folgenden beschriebene Vorgehensweise wenden Sie an, wenn sich dieses Gespräch ständig wiederholt.

Die Behauptung also, ehrlich ausgedrückt: die Retro-Sitzung oder Ihre bestehende Besprechung mit vergleichbarem Ablauf. Die monatliche Kampagnenüberprüfung durch ein Medienteam und die Triage-Überprüfung durch ein Support-Team sind ein und dieselbe Prozedur unter unterschiedlichen Bezeichnungen, und nichts an dieser Vorgehensweise setzt Programmierkenntnisse voraus: Das Fehlerprotokoll eines verworrenen Anzeigenkontos oder einer inkonsistenten Vorlagenbibliothek liest sich genau wie das Fehlerprotokoll eines veralteten Repositorys.

Die Person im Raum: Teilnehmer, niemals Moderator

Wenn die Beweise von Agenten stammen, sollte dann der Agent den Fall bearbeiten? Nein, und das nicht in erster Linie aus dem Grund, den Sie vermuten würden.

Der Grund dafür ist folgender: Die heutigen Modelle sind gerade bei dieser Art von Beurteilung unzuverlässig: Die Entscheidungen von LLM schwanken bei identischen Eingaben in ~13,6 % der Fälle, und in einer achtwöchigen Produktionsstudie wurden ~70 % der stillen Agentenausfälle zunächst von einer Person entdeckt, nicht durch Tests oder Überwachung. Das trifft heute zu; Modelle verbessern sich jedoch.

Der Grund, warum dies nicht nachlässt: Moderation und Entscheidungsfindung verteilen die Aufmerksamkeit eines Teams und verändern die Artefakte, für die das Team verantwortlich ist und über die es entscheidet. Diese Befugnis geht nicht auf die kompetenteste Person im Raum über, genauso wenig wie sie auf den kompetentesten Ingenieur im Raum übergeht. Es handelt sich um eine organisatorische Tatsache, nicht um eine Kompetenzlücke.

Der Mitarbeiter beteiligt sich also so, wie es der am besten informierte Mitwirkende tut. Er legt Belege vor: seine Sitzungsprotokolle, mit Beschriftungen und Kostenangaben versehen. Er beantwortet Fragen: Auf die Frage „Was haben Sie vor der Umgehungslösung tatsächlich versucht?“ gibt es eine durch das Protokoll belegte Antwort. Er entwirft, entscheidet jedoch nie: Vorgeschlagene Korrekturen werden mit empfohlenen Prioritätsstufen eingereicht; die Gruppe überarbeitet, priorisiert neu oder verwirft sie. Und er nimmt akzeptierte Maßnahmen zurück (die Dokumentbearbeitung, die Konfigurationsänderung) und führt sie nach der Besprechung im Rahmen der üblichen Überprüfung durch. In der Forschungspraxis gibt es einen Begriff für diese Aufgabenteilung: Im ACE-Framework fungiert der Agent als Reflektor, während ein Kurator die Inhalte konsolidiert, die in das Playbook aufgenommen werden. Wir nehmen eine bewusste Anpassung vor: In ACE ist der Kurator eine deterministische Komponente; hier bilden die Teammitglieder die Kuratoren.

Eine Asymmetrie betrifft die Datenübertragung. Alles, was der Agent in den Raum einbringt, sollte uneingeschränkt zugänglich sein, da ein Agent, der eine Berechtigung benötigt, um Reibungsverluste zu melden, diese nur unvollständig erfasst. Alles, was den Raum in Bereiche verlässt, auf die sich Agenten später stützen (Speicher, Kontextdateien, Konfiguration), durchläuft eine reguläre Überprüfung, da dieser Schreibpfad eine anerkannte Angriffsfläche für Manipulation und Abweichungen darstellt (OWASP Agentic Top 10, ASI06). Die Maßnahme liegt genau an dieser Grenze: unkontrollierte Eingaben nach innen, kontrollierte Schreibvorgänge nach außen.

Die fünfzehn Minuten

Was wir einem Team tatsächlich vorschlagen, ist, dies in diesem Sprint auszuprobieren, wobei jede Schleife bereits einwandfrei läuft:

1. Pro Sitzung verfasst der Bearbeiter eine kurze Retrospektive auf seine eigene Arbeit: Was gut gelaufen ist, alle Probleme mit Angabe der Grundursache und der damit verbundenen Kosten, einen Vorschlag für eine Lösung im Umfang eines Tickets sowie die angestrebte Zielebene. Wird zusammen mit der Arbeit committet, ohne Sperre.
2. Vor dem Rückblick werden die seit dem letzten Mal eingegangenen Beiträge in einem einseitigen Überblick zusammengefasst: häufig auftretende Themen, welche Gruppe von Grundursachen überwiegt, ob frühere Korrekturmaßnahmen umgesetzt wurden sowie die drei wichtigsten empfohlenen Maßnahmen. Der Überblick dient als Grundlage für die Diskussion; er ersetzt diese jedoch nicht.
3. Im Rückblick (ein Tagesordnungspunkt, kein neues Meeting): 15 Minuten zum Thema „Was hat in diesem Zyklus im Bereich KI gut funktioniert und was hat immer wieder Probleme verursacht?“ Die Verantwortlichen treffen eine Vorauswahl: beibehalten oder streichen, die Ziele bestätigen oder neu ausrichten, den drei wichtigsten Punkten Verantwortliche zuweisen.
4. Im nächsten Zyklus wird im Annahmecheck des Briefings festgestellt, ob die Reibung tatsächlich abgenommen hat. Durch diesen Check entsteht eine Schleife im Bericht. Genau an dieser Stelle hat uns unser eigener Vorstand auf den Fehler hingewiesen.

Fehlermodi, die so benannt sind, dass Sie sich gegen sie wappnen können: Retro-Theater (die Zeremonie, die Sie für das Publikum abhalten: kurze Lesung, Kopfnicken, keine Entscheidungen; dafür gibt es die „Top-3-mit-Eigentümern“-Regel); Agent-Blame (die Aussage „der Agent hat einen Fehler gemacht“ als Erklärung statt als Restfehler zu betrachten; die meisten Fehler lassen sich auf den Testrahmen und die Eingaben zurückführen, nicht auf die Modellschlussfolgerungen); Wunschliste-Ausuferung (zwanzig Maßnahmen, keine Verantwortlichen); und die Schleife schließt sich nie (die Lücke bei der Umsetzung: Korrekturen werden umgesetzt, niemand überprüft den Trend). Wir haben einen ganzen Leitfaden darüber verfasst, wie Zeremonien scheitern; jeder darin beschriebene Modus trifft auch hier zu.

Was wir nicht behaupten

Kein Ersatz für irgendeinen Anbieter-Kreislauf: Deren Ergebnisse sind die Eingaben für diesen Prozess. Kein neues Meeting. Kein KI-gesteuerter Prozess; bei einem Unternehmen, dessen Produkt Retrospektiven sind, ist diese Leitplanke bewusst gewählt. Nicht notwendig für Selbstständige, deren Kreisläufe sich intuitiv gut schließen. Und das Ziel ist nicht „Reibungsfreiheit“: Ein gewisses Maß an Reibung dient als Steuerungsinstrument, und der Tagesordnungspunkt dient dazu, eine Auswahl zu treffen, nicht dazu, etwas sofort zu verwerfen.

Was würde uns umstimmen?

Da es sich hierbei um ein Diskussionspapier handelt, folgt nun der falsifizierbare Teil: Sollten die Anbieter-Schleifen zu einer echten, werkzeug- und personenübergreifenden Beurteilung führen – und nicht nur zu flottenweiten Speicherschreibvorgängen –, schrumpft der Spielraum auf eine reine Prüfungsfunktion. Sollten Teams, die die rein asynchrone „Brief“-Version durchführen, denselben Trend zur Reibungsreduzierung aufweisen wie Teams, die den Tagesordnungspunkt bearbeiten, dann sind diese fünfzehn Minuten reine Show – und das werden wir auch so sagen. Unsere Behauptung bezüglich des „gelabelten Vokabulars“ stützt sich zudem auf ein Experiment zur Interrater-Reliabilität, das wir derzeit an realen Einträgen durchführen, anstatt dies im Voraus zu behaupten. Wir möchten lieber die Zahlen veröffentlichen als unsere Zuversicht.

Falls Ihr Team eine beliebige Variante davon durchführt (den Tagesordnungspunkt, den asynchronen Brief oder eine Zeremonie, an die wir noch nicht gedacht haben), würden wir gerne erfahren, wie es gelaufen ist: ai-discussion@teamretro.com.

---

Nächstes Kapitel: Durchführung der AI-Kooperations-Retrospektive. Der Leitfaden für Moderatoren für die fünfzehn Minuten: die Vorlage, das Eingabeformat und die Prompt-Karten. Teil des Leitfadens für AI-Agenten-Retrospektiven.