Durchführung der AI-Kooperation im Rückblick

Bei TeamRetro interessieren wir uns für jeden Zyklus der kontinuierlichen Verbesserung, den ein Team durchläuft. KI-gestützte Arbeit ist ein neues Gebiet, das wir aus der Perspektive unserer Retrospektiven beleuchtet haben; in diesem Leitfaden teilen wir Ihnen mit, zu welchen Erkenntnissen wir bislang gelangt sind. Nehmen Sie ihn an, passen Sie ihn an und setzen Sie ihn in den Tools oder im Rahmen der Rituale ein, die Sie bereits nutzen.

Teil 1 – Der Leitfaden

Warum dies Teil einer Teamfeier sein sollte

Irgendwo in Ihrem Team hat ein KI-Assistent diesen Monat vierzig Minuten damit verbracht, eine „fehlgeschlagene“ Werbekampagne zu überprüfen, die absichtlich pausiert worden war, da dies im Auftrag nicht vorgesehen war. Die für die Sitzung verantwortliche Person hat den Fehler korrigiert, mit den Schultern gezuckt und ist zur nächsten Aufgabe übergegangen. Wenn vier Kollegen auf unterschiedliche Varianten derselben Lücke stoßen, bedeutet das stundenlange, unbemerkte Zeitverschwendung pro Monat – und niemand weiß davon, da jeder diese Belastung allein verkraftet hat.

Das ist das typische Muster bei Reibungsverlusten in KI-Sitzungen: Sie sind chronisch und geringfügig, sodass sie niemals eine Nachanalyse auslösen, und sie sind vergänglich, sodass sie sich mit Ende der Sitzung in Luft auflösen. Die meisten Teams können diese Probleme bereits beobachten (etwa 90 % erfassen die Protokolle ihrer Agenten), doch weitaus weniger setzen dies in Korrekturmaßnahmen um: Nur etwa 37–52 % werten die erfassten Daten systematisch aus (LangChain, Juni 2026).

Die bereits vorhandenen Verbesserungszyklen sind gut, und diese Vorgehensweise baut auf allen auf:AGENTS.md Aktualisierungen von Kontextdateien, Speichersysteme, Pipelines zur Selbstoptimierung der Anbieter sowie Fehleranalysen anhand von Trace-Daten (Husain & Shankar, evals FAQ). Selbst die Anbieter greifen auf den Begriff „Retrospektive“ 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). Doch fast alle diese Zyklen finden im Alleingang statt: eine Person und ihr Agent oder eine Plattform und ihre Flotte. Was die Teamebene hinzufügt, ist Aggregation: Reibungsverluste, die pro Person nur fünf leichtfertig abgetane Minuten ausmachen, werden erst in der aggregierten Sicht zu einem erheblichen Teamkostenaufwand – und um darauf zu reagieren (die gemeinsame Vorlage umschreiben, den Aufnahmeprozess ändern, das Tool anschaffen), bedarf es einer Entscheidungsbefugnis, über die kein Einzelner verfügt. Rahul Gargs „Feedback Flywheel“ benennt den Rahmen: „Ein Tagesordnungspunkt in der bestehenden Sprint-Retrospektive: Was hat in diesem Sprint im Zusammenhang mit KI gut funktioniert?“ (martinfowler.com), und dieser Leitfaden ist eine Möglichkeit, dies umzusetzen.

Ein ehrliches Eingeständnis gleich zu Beginn: Was hier benötigt wird, ist eine regelmäßig stattfindende, vorwurfsfreie und auf Fakten basierende Zeremonie, an der die für die Fehlerbehebung Verantwortlichen teilnehmen. Für die meisten Teams ist das die Retro, aber ein Termin im Rahmen der Sprintplanung, eine monatliche Betriebsbesprechung oder die Account-Besprechung des Medienteams eignen sich ebenso gut. Die Retro oder Ihre bestehende Zeremonie ähnlicher Art.

Wissenswertes für Moderatoren: Scrum.org nähert sich demselben Thema aus der Perspektive der Metriken; ihr Leitfaden zur Durchführung der Sprint-Retrospektive, wenn die Hälfte Ihres Teams aus KI-Agenten besteht betrachtet die Veranstaltung als datengestützte Überprüfung der Agentenleistung (Neufassung von Prompts, Abweichungsraten, Token-Verbrauch). Dieser Leitfaden verfolgt den komplementären Ansatz: Ursachenanalyse und Lösungsansätze für die gesamte Zusammenarbeit, wobei die Agenten ihre eigenen Berichte zur Arbeit beisteuern, die über den TeamRetro-MCP-Server eingereicht werden, sofern Sie TeamRetro nutzen. Teams mit einer großen Anzahl von Agenten könnten Elemente aus beiden Ansätzen nutzen wollen.

So funktioniert die Praxis von Anfang bis Ende

1. Erfassung pro Sitzung. Am Ende jeder umfangreichen, KI-gestützten Sitzung verfasst der Agent einen kurzen, strukturierten Eintrag: Was lief gut, was zog sich in die Länge (jeder Punkt wird mit einer Grundursache und einer Lösungsvorschlag versehen), welche Vermutungen wurden angestellt und welche Maßnahme hat die größte Wirkung. Eine Datei pro Eintrag in einem gemeinsam genutzten Protokoll.
2. Zusammenfassung nach ca. 5 Einträgen. Vor der Zeremonie fasst der Bearbeiter das Protokoll zu einem einseitigen Bericht zusammen: wiederkehrende Themen, geordnet nach Häufigkeit × Kosten, eine Verteilung der Grundursachen, eine Überprüfung, ob frühere Korrekturmaßnahmen umgesetzt wurden, sowie die drei wichtigsten empfohlenen Maßnahmen.
3. Entscheiden Sie sich innerhalb von 15 Minuten. Der Bericht ist ein Tagesordnungspunkt in Ihrer bestehenden Retrospektive, kein neues Meeting. Das Team nimmt eine Priorisierung vor: Es entscheidet, ob jedes Hindernis beibehalten oder beseitigt werden soll, legt fest, wo die jeweiligen Lösungen umgesetzt werden sollen, und weist den wichtigsten Maßnahmen Verantwortliche zu. Im Bericht des nächsten Zyklus wird festgehalten, ob das Hindernis tatsächlich abgebaut wurde.

Die Erfassungs- und Syntheseschritte sind als Open-Source-Agentenfähigkeiten in unserem TeamRetro-skills-Repo implementiert, falls Sie einen schnellen Einstieg wünschen.

Der Agent meldet ohne Einschränkung: Ein Agent, der eine Berechtigung zur Erfassung von Reibungsverlusten benötigt untermeldet, und nachträgliche Korrekturen durch Menschen stellen ein zusätzliches Signal dar, nicht einen Kontrollpunkt, auf den die Schleife wartet. Die Entscheidung liegt beim Team, und zwar nicht aus Höflichkeit: Die Korrekturen fließen in Budgets, Dokumente, Prozesse und Werkzeuge ein, für die die Mitarbeiter verantwortlich sind und Rechenschaft ablegen. Der Agent liefert Belege und Entwürfe; das Team entscheidet.

So sieht ein guter Beitrag aus

Hier ist ein anschauliches Beispiel, bei dem es bewusst nicht um das Programmieren geht:

# 2026-07-16 — Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

## Guesses made
- Assumed the target CPA unchanged from June — unverified

## Do this first
Campaign-status flags in the brief template — kills the largest single time sink this month.

(est.)Beachten Sie die Systematik. Jeder Reibungspunkt enthält einen Zeitpunkt und Kosten (grobe Schätzungen sind mit gekennzeichnet) sowie genau eine Ursache-Bezeichnung aus einem kleinen, festgelegten Vokabular (Bezeichnungen wie ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool,agent-error , oder work-material-friction, wobei das Material selbst den Widerstand darstellte: eine verworrenen Kampagnenstruktur, eine veraltete Tabellenkalkulation, ein Modul, das niemand anfassen möchte – stets unter Nennung des konkreten Materials) und endet mit einer Lösung im Ticket-Format, die ihre Priorität angibt: Gehört diese Lösung in eine private Notiz, in eine Vorgehensweise, in die Umgebung, in die Dokumentation, in das Arbeitsmaterial selbst, in den Prozess oder auf einer vorgelagerten Ebene bei einem Lieferanten? Feste Bezeichnungen sorgen dafür, dass Einträge über Personen und Sitzungen hinweg vergleichbar sind; „die Dokumentation war verwirrend“ lässt sich nicht aggregieren, achtmissing-documentationEinträge hingegen schon. Vagheit ist der Fehlermodus; „nichts Bemerkenswertes“ ist ein gültiger Eintrag.

Ein guter Bericht umfasst eine Seite: Themen mit Häufigkeitsangaben („4 von 9 Sitzungen“) und datierten Beispielen, eine klare Angabe, welche Gruppe von Grundursachen überwiegt (Briefing, Dokumentation, Arbeitsmaterial, Werkzeuge oder Mitarbeiter; darauf sollte sich die Aufmerksamkeit des Teams konzentrieren), die Überprüfung der Umsetzung früherer Vorschläge sowie drei Maßnahmen, denen jeweils ein Verantwortlicher zugewiesen werden kann. Er dient als Grundlage für den Dialog; er ersetzt diesen jedoch nicht.

Geltungsbereich: ein Protokoll pro Prüfungsbereich

Führen Sie pro Prüfungsbereich ein Protokoll: Dabei handelt es sich um den Bereich, in dem Korrekturen vorgenommen werden. Bei der Entwicklungsarbeit ist dies in der Regel das Repository, da sich dort die Dokumentation, die Konfiguration und die Konventionen befinden. Bei nicht-codebezogenen Aufgaben sind dies das Anzeigenkonto, der Support-Posteingang oder die Kundenbetreuung; das Protokoll wird im Dokumentenverzeichnis des jeweiligen Arbeitsbereichs abgelegt. Ein Eintrag, der außerhalb seines Geltungsbereichs abgelegt wird, wird vom späteren Verantwortlichen für die Fehlerbehebung niemals gefunden. Das Schema bleibt überall identisch; das Schema – nicht der Speicherort – sorgt dafür, dass Einträge zusammengefasst werden.

Die „Never-Log“-Regeln

Einträge werden festgehalten, weitergegeben und überdauern ihren Kontext; daher dürfen bestimmte Dinge niemals darin erscheinen: Geheimnisse, Zugangsdaten oder Schlüssel jeglicher Art; Kundendaten oder personenbezogene Informationen; noch nicht veröffentlichte Geschäftszahlen; und – was für die Retro-Kultur am wichtigsten ist – Namen, Rollen oder alles, was eine Person identifiziert. Beschreiben Sie die Lücke und die damit verbundenen Kosten, niemals jedoch, wer sie verursacht hat: „Das Briefing ließ die Zielgruppe offen“, nicht „Xs Briefing“. Reibungspunkte kritisieren Eingaben und Systeme, nicht Personen. Wenn sich die Reibung eines Projektumfangs nicht ohne sensiblen Kontext beschreiben lässt, halten Sie diese Einträge privat und geben Sie nur das aggregierte Briefing weiter.

Teil 2 – Die Vorlage „AI Collaboration Retro“

Ein gebrauchsfertiges Format: fünf Leitfragen, die auf dem Einstiegsschema basieren und in TeamRetro oder auf jedem Whiteboard durchgeführt werden können:/retrospectives/

Kolumne	Eingabeaufforderung	Einzeiler
Es ist gut gelaufen	Was konnte in diesem Zyklus durch KI-gestützte Arbeit schneller oder besser erledigt werden?	Ausschließlich belegte Erfolge: Was es zu bewahren und zu wiederholen gilt, ohne übertriebene Lobeshymnen.
Reibung und deren Ursache	Wo kam es zu Verzögerungen, und was war die eigentliche Ursache?	Auf jeder Karte sind der Zeitpunkt, die ungefähren Kosten und ein Begriff aus dem festgelegten Vokabular des Teams angegeben.
Vermutungen, die wir unberücksichtigt lassen	Was hat der Makler (oder haben wir) ohne ausreichende Informationen angenommen?	Latente Spannungen, die bislang noch keine negativen Auswirkungen gezeigt haben; kennzeichnen Sie alles, was noch nicht überprüft wurde.
Behalten oder töten	Welche dieser Reibungspunkte haben wir bewusst gewählt?	Prüfungsschritte und Genehmigungsphasen können bewusst festgelegte Kontrollpunkte sein (Zusammenfassung des Vortrags von Ronacher auf der AIE Europe); die Streichung eines solchen Schritts ist eine Entscheidung des Teams.
Bitte führen Sie dies zuerst durch	Von all dem hier: Welche Korrektur zahlt sich am meisten aus, und in welcher Höhe?	Maximal drei, jeweils mit einem Verantwortlichen und der Ebene, auf der sie angesiedelt sind: Dokumentation, Umgebung, Prozess, Material oder vorgelagerte Bereiche.

Teil 3 – Hinweiskarten für Moderatoren

Fragen, die Sie stellen sollten, wenn ein Team einen AI-Retro-Auftrag zur Sitzung mitbringt. Je eine pro Karte; verwenden Sie diejenigen, die für das Gespräch relevant sind.

1. „Aus welcher Sitzung stammt dies, und wie hoch waren die Kosten?“ Für Musterangaben sind datierte Nachweise erforderlich; eine Karte ohne Zeitangabe und Kostenangabe kann nicht geprüft werden.
2. „Ist diese Reibung ein Kontrollpunkt, den wir bewusst gewählt haben?“ Zunächst einmal das Prinzip „Behalten oder streichen“: Ein gewisses Maß an Reibung dient der Steuerung (Zusammenfassung von Ronachers Vortrag auf der AIE Europe), und Reibungsfreiheit hat ihren Preis; Thoughtworks warnt vor der kognitiven Verschuldung, die dadurch entsteht (Ankündigung).
3. „Wir haben diese Lösung bereits beim letzten Mal vorgeschlagen. Was hat die Umsetzung verhindert?“ Nicht umgesetzte, wiederholt vorgebrachte Vorschläge sind der wichtigste Punkt in jedem Bericht; ohne diese Frage ist das Ganze nur Show.
4. „Das hat jeden von Ihnen zehn Minuten gekostet – was kostet das das Team pro Monat?“ Die Aggregation ist der entscheidende Vorteil der Teamebene; fragen Sie danach, wann immer eine Karte einfach abgetan wird.
5. „Gehört diese Korrektur in die Dokumentation, in die Umgebung oder in die Arbeitsanweisungen?“ Die Frage nach dem richtigen Maß. Liegt das Ziel zu niedrig, tritt das Problem erneut auf; liegt es zu hoch, bläht man das falsche Artefakt auf.
6. „Wem gehört das Artefakt, bei dem diese Korrektur ansetzt?“ Eine Handlung ohne Eigentümer ist ein Wunschobjekt. Befindet sich der Eigentümer nicht im Raum, handelt es sich ebenfalls um einen Fund.
7. „Bevor wir dies als Fehler des Agenten bezeichnen: Waren die Eingaben angemessen?“agent-error– dies ist die Restbezeichnung, nicht die Standardbezeichnung; die abzulehnende Standardhaltung besteht darin, dem Agenten die Schuld zu geben, obwohl das Problem beim Harness oder bei der Aufgabenstellung lag – beheben Sie stattdessen den Fehler im Harness (Osmani, Agent Harness Engineering).
8. „Welche Gruppe von Grundursachen dominiert die Verteilung, und richten wir unsere Aufmerksamkeit darauf?“ Die Zahlen in der Zusammenfassung geben Aufschluss darüber, ob das Problem bei der Einweisung, der Dokumentation, den Arbeitsunterlagen, den Arbeitsmitteln oder der Einrichtung der Arbeitsstationen liegt. Die Aufmerksamkeit sollte sich an den Daten orientieren.
9. „Hat dies eine Person bemerkt oder war es der Agent?“ Die Korrektur durch den Menschen ist nach wie vor der maßgebliche Sensor: Eine Produktionsstudie ergab, dass etwa 70 % der stillen Fehler zunächst von einer Person entdeckt wurden, der etwas Ungewöhnliches auffiel (arXiv 2606.14589). Behandeln Sie diese Feststellungen als erstklassige Hinweise und nicht als Unterbrechungen.
10. „Betrifft dies den Zuständigkeitsbereich unseres Teams oder den eines anderen Teams?“ Korrekturen fallen in den Zuständigkeitsbereich des jeweiligen Überprüfungsbereichs; eine Karte, die sich auf die gemeinsame Vorlage oder den Prozess eines anderen Teams bezieht, sollte weitergeleitet und nicht übernommen werden.
11. „Handelt es sich hier um eine Diskussion oder um eine Eintragung?“ Die offensichtlichen Korrekturen werden direkt in den Tracker eingetragen; widmen Sie die fünfzehn Minuten ausschließlich den strittigen Entscheidungen: Beibehalten oder Streichen, Höhenstreitigkeiten, Prioritäten.
12. „Liegt diese Entscheidung über den Befugnissen eines Einzelnen von uns?“ Der Kauf eines Werkzeugs, die Änderung der Ansaugung, die Eskalation an einen Lieferanten – die neu gewichtete Prioritätenliste überschreitet oft die Entscheidungsgrenze des Einzelnen. Genau das ist der Grund, warum dieses Thema überhaupt zur Sprache kommt.

---

Nächstes Kapitel: In zehn Minuten loslegen. Installieren Sie die Skills und führen Sie Ihre erste Erfassung durch, oder übertragen Sie die obige Vorlage auf das Board, das Ihr Team bereits verwendet. Teil des Leitfadens für Retrospektiven mit KI-Agenten.