Die Übersicht: Rückkopplungsschleifen, Werkzeuge und Ansätze für Agenten

TeamRetro interessiert sich für jeden Zyklus der kontinuierlichen Verbesserung, den Teams durchlaufen; KI-gestützte Arbeit ist ein neuer Bereich, den wir aus der Perspektive der Retrospektive beleuchten. Diese Seite dient als Begleitmaterial zu diesem Leitfaden: Hier wird das gesamte Thema systematisch dargestellt. Wenn Sie lieber mit der Geschichte beginnen möchten, starten Sie am Einleitungsabschnitt des Leitfadens und kehren Sie anschließend hierher zurück.

Worum es auf dieser Seite geht

Drei Dinge, der Reihe nach: der Lebenszyklus, den ein einzelnes Reibungsproblem vom Auftreten bis zur Behebung durchläuft; die benannten Schleifen, die in der Praxis zur Abwicklung dieses Lebenszyklus etabliert wurden, sortiert nach der Ebene, auf der sie jeweils ablaufen; und die Klassifizierungsschemata, die zur Benennung der aufgetretenen Fehler verwendet werden. Lesen Sie den Text von oben nach unten, um die Position Ihres Teams zu ermitteln: Welche Phasen decken Ihre Tools bereits ab, welche Schleife führen Sie bereits unter einem anderen Namen aus und mit welchem Vokabular würden Sie Ihre Erkenntnisse kennzeichnen? Alles hier steht für sich allein: Nichts davon erfordert die Übernahme unserer Vorgehensweise, unserer Bezeichnungen oder unseres Produkts.

Der Lebenszyklus: sieben Phasen – von der Problemerkennung bis zur Lösung

Wenn ein Mitarbeiter bei der eigentlichen Arbeit auf Hindernisse stößt (ein fehlendes Dokument, eine mehrdeutige Anweisung, ein unzuverlässiges Tool), ist dieses Signal nur von kurzer Dauer: Der Mitarbeiter umgeht das Problem, die Sitzung endet, und bei der nächsten Sitzung stößt er erneut auf dieselbe Hürde. Rahul Gargs Reibungsmuster beschreiben die Kosten erster Ordnung (den Frustrationskreislauf aus „Erstellen → Überprüfen → Passt nicht → Neu erstellen“); der untenstehende Lebenszyklus veranschaulicht das Problem zweiter Ordnung: Was muss geschehen, damit aus Reibung eine Lösung auf der richtigen Ebene wird? Die Lücke ist messbar: Etwa 90 % der Teams erfassen Agentenverläufe, doch nur etwa 37–52 % werten diese systematisch aus (LangChain, Juni 2026). Die meisten Teams können Reibungspunkte beobachten; weitaus weniger setzen diese in Lösungen um.

Bühne	Die Frage, die damit beantwortet wird	Optionen	Fachbegriff
0 · Hosting	Wo wird der Agent ausgeführt?	lokale CLI · Web · IDE · CI/headless · zeitgesteuert	k. A.
1 · Erkennung	Wie lässt sich Reibung feststellen?	Selbstüberprüfung · Überprüfung durch einen zweiten Bearbeiter · manuelle Korrektur · Telemetrie	Trace-Überprüfung, Fehleranalyse
2 · Instrumentierung	Woher weiß der Mitarbeiter, dass er dies nachverfolgen muss?	Fähigkeit · Aufhänger · Konvention · Befehl	k. A.
3 · Aufzeichnung	Wie wird es erfasst, und wo?	Speicher · MCP-Speicher · Protokolle/Traces · Tickets · mit Tags versehene Commits	offene Kodierung, episodisches Gedächtnis
4 · Ernte	Wie können Sie Informationen über eine einzelne Sitzung hinaus sammeln?	Trace-Mining vs. Artefakt-Aggregation · Sweep vs. Ereignis · Deduplizierung	k. A.
5 · Synthese und gezielte Ausrichtung	Rohdatensätze → Muster → In welchem Umfang ist eine Korrektur erforderlich?	Cluster + Punktzahl, anschließend nach Höhe sortieren	Axialkodierung, Fehlertaxonomie
6 · Den Kreislauf schließen	Hat die Korrektur künftige Reibungsverluste verringert?	den Trend ermitteln	Rückkopplungs-Schwungrad, Compounding-Technik

Phase 0: Hosting

Alles, was danach folgt, hängt davon ab, wo der Agent ausgeführt wird. Ein lokaler CLI-Agent hinterlässt ein Protokoll auf der Festplatte und kann Speicherdateien schreiben; ein CI- oder Headless-Agent ist möglicherweise kurzlebig, wobei seine einzige Spur das ist, was er vor dem Absturz des Containers protokolliert hat; ein Web- oder IDE-Agent speichert einen serverseitigen Verlauf, den Sie abfragen, aber nicht mit „grep“ durchsuchen können; ein zeitgesteuerter Agent läuft ohne menschliche Überwachung. Die Art des Hostings bestimmt die Rahmenbedingungen für alle nachfolgenden Phasen: Was ist beobachtbar, wo kann der Status persistent gespeichert werden und wer (oder was) kann ihn einsehen? Der Kompromiss: umfassendere lokale Beobachtbarkeit im Vergleich zur Reproduzierbarkeit und zentralen Speicherung bei gehosteten Ausführungen.

Phase 1: Erkennung

Vier Kanäle, selten exklusiv. Selbsterkennung (der Agent erkennt seine eigenen Wiederholungsversuche und Rückverfolgungen) ist am kostengünstigsten, aber am stärksten verzerrt: Der Agent weiß nicht, was er nicht weiß. Die Überprüfung durch einen zweiten Agenten, bei der ein neuer Agent das Protokoll im Nachhinein liest, ist objektiver, erfordert jedoch einen zweiten Durchgang. Menschliche Korrektur ist das qualitativ hochwertigste Signal und nach wie vor das vorherrschende: Eine achtwöchige Produktionsstudie ergab, dass etwa 70 % der stillen Fehler zunächst von einem Menschen entdeckt wurden, dem auffiel, dass etwas nicht stimmte (arXiv 2606.14589). Telemetrie (Fehlerraten der Tools, abgelehnte Berechtigungen, Schleifenzahlen) erfolgt automatisch, ist jedoch oberflächlich: Sie erfasst das, nicht das Warum. Die leistungsstärksten Verfahren nutzen eine dreifache Überprüfung: Die Telemetrie zeigt an, wo nachgeschaut werden muss, und ein Überprüfungsdurchgang erklärt, warum.

Phase 2: Instrumentierung

Ein Agent zeichnet keine Reibung auf, solange nicht etwas diese auslöst. Die Optionen, je nachdem, inwieweit sie sich darauf stützen, dass sich das Modell daran erinnert: eine Fähigkeit (ein explizites, übertragbares Verfahren, das an einem Haltepunkt aufgerufen wird: klar, muss aber tatsächlich ausgelöst werden), ein Hook (wird automatisch beim Start oder Ende einer Sitzung ausgelöst: zuverlässig, aber undifferenziert), eine Konvention (eine Anweisung in einer Kontextdatei: keine Infrastruktur, basiert auf Vertrauen) oder ein Befehl (vom Menschen ausgelöst: bewusst, aber vom Menschen gesteuert). Dies ist die Phase, die am häufigsten übersprungen wird, und deshalb bleiben so viele Reibungsverluste unberücksichtigt: Niemand hat den Agenten angewiesen, danach zu suchen.

Phase 3: Aufzeichnung

Zwei Fragen: Was ein guter Datensatz enthält und wo er gespeichert ist. Ein nützlicher Datensatz enthält Belegangaben (was geschah, was es gekostet hat), ist mit einer Bezeichnung aus einem festgelegten Vokabular versehen, damit Datensätze später vergleichbar sind, und schließt mit einem Vorschlag für den nächsten Schritt ab. Was den Speicherort betrifft, so gibt es jeweils einen echten Kompromiss: Speicherdateien (dauerhaft und reibungslos, aber privat und locker strukturiert), ein MCP-Speicher (gemeinsam genutzt und abfragbar, benötigt jedoch einen Server), Protokolle/Traces (automatisch und vollständig, doch das Signal geht im Rauschen unter), Tickets (umsetzbar und für das Team sichtbar, jedoch pro Eintrag ressourcenintensiv) oder getaggte Commits und PRs, z. B. ein work-material-frictionLabel, das den Aufwand mit der genauen Änderung verknüpft – allerdings nur dort, wo die Arbeit in der Versionskontrolle landet. Nichts davon ist codespezifisch: Das Account-Protokoll eines Medienteams oder der kommentierte Verlauf einer Support-Warteschlange sind ebenfalls Aufzeichnungssubstrate. Eine Warnung, die für alle Substrate gilt, auf die sich Agenten später stützen: Von Agenten geschriebene Speicherinhalte stellen eine benannte Angriffs- und Driftfläche dar (OWASP Agentic Top 10, ASI06), was ein Argument für belegte und überprüfte Schreibvorgänge ist.

Phase 4: Ernte

Reibungsverluste in einer Sitzung sind nur Störgeräusche; dieselben Reibungsverluste über acht Sitzungen hinweg stellen jedoch ein Prozessproblem dar. Die strategische Entscheidung lautet: Trace-Mining (erneutes Durchlesen der Rohprotokolle: vollständig, jedoch kostspielig und mit hohem Datenschutzaufwand verbunden) versus Artefakt-Aggregation (Durchsuchen der gezielt erstellten Aufzeichnungen: kostengünstig, jedoch nur so gut wie die Disziplin in Phase 3); echte Pipelines kombinieren beides. Dann die Kadenz (eine planmäßige Durchsicht gegenüber einer Erfassung am Sitzungsende) und die wenig glamouröse Arbeit der Dublettenbereinigung: Dieselbe Reibung, die von fünf Personen auf fünf verschiedene Weisen formuliert wurde, muss zu einem Muster mit einer ehrlichen Zählung zusammengefasst werden. Bei der Erfassung entsteht der Mehrwert, denn erst die Aggregation gewichtet die Prioritäten neu: Ein fünfminütiges Ärgernis, das niemand einzeln beheben würde, stellt in der Gesamtheit einen erheblichen Kostenfaktor für das Team dar.

Phase 5: Synthese und Zielausrichtung

Zwei Schritte. Clusterbildung und Bewertung: Gruppieren Sie die Ergebnisse nach Mustern, geordnet nach Häufigkeit × Kosten; genau dafür sind die nachstehenden Klassifizierungsschemata vorgesehen. Die richtige Ebene anvisieren: Leiten Sie jedes Muster auf die richtige Korrekturebene weiter, von kurzlebig bis strukturell (Gedächtnis → Fertigkeit/Aufforderung → Umgebung & Konfiguration → Dokumentation → das Arbeitsmaterial selbst → Prozess → vorgelagertes Tool oder Anbieter). Unterziel (eine private Gedächtnisnotiz für etwas, das eigentlich ein fehlendes Teamdokument ist) und die Reibung tritt für alle anderen erneut auf; Überziel (eine neue Fertigkeit für einen einmaligen Vorgang) und Sie blähen ein Artefakt so lange auf, bis es nicht mehr gelesen wird. Die Praxis hat sich unabhängig voneinander auf denselben Gradienten zubewegt: vorübergehendes Gedächtnis zurückstufen, dauerhaftes Lernen in die Versionskontrolle überführen. Windsurf/Devins Dokumentation empfiehlt, wiederkehrende Erkenntnisse in Regeln oder in die Datei „AGENTS.md“ (die Datei mit den festen Anweisungen, die Agenten lesen) zu übertragen, anstatt sich auf automatische Gedächtnisfunktionen zu verlassen. OpenAI’s Codex-Leitfaden besagt, dass der Fall „derselbe Fehler zweimal“ eine Aktualisierung von AGENTS.md nach sich zieht, und Copilot-Speicher läuft nach 28 Tagen ab – so ist es vorgesehen: Nicht beförderte Erinnerungen sollten verfallen. Eine zusammenfassende Erkenntnis lässt sich leicht übersehen: Nicht jede Reibung ist Verschwendung. Ein Teil davon ist die Steuerfläche: „Reibung ist das, was notwendig ist … um zu steuern“ (eine Zusammenfassung von Ronachers Vortrag auf der AIE Europe), daher umfasst die Triage nicht nur die Behebung, sondern auch die Entscheidung „behalten oder löschen“.

Schritt 6: Den Kreislauf schließen

Der echte Test für den gesamten Lebenszyklus: Nimmt diese Art von Reibung im Laufe der folgenden Sitzungen ab? Eine Korrektur, die zwar gemeldet, aber nie umgesetzt wird – oder zwar umgesetzt wird, aber nichts ändert –, ist reine Show. Dies ist die Prämisse von Gargs Feedback Flywheel und die Grundlage des Compounding Engineering: Jeder Fix erleichtert die nächste Arbeitseinheit, sofern sich der Kreislauf tatsächlich schließt.

Die benannten Schleifen, nach Betriebsebene

In der Fachwelt hat sich dieser Lebenszyklus unter mindestens einem halben Dutzend Bezeichnungen etabliert. Alle diese Bezeichnungen sind zutreffend; nichts auf dieser Seite ersetzt eine davon. Die einzige Sortierung, die in dieser Tabelle vorgenommen wird, ist die Ebene, auf der die jeweilige Schleife abläuft, und Folgendes ist zu beachten, sobald die Sortierung erfolgt ist:

Schleife	Läuft bei	Schließt den Kreis, indem
Loop-Engineering / Compound-Engineering	ein Praktizierender	persönliche Regeln, Anweisungen, Leitfäden
agent-retro	eine Sitzung	Änderungen an Fähigkeiten und Konfigurationen pro Sitzung anhand des Protokolls
Sensoren für die Kabelbaumtechnik (Thoughtworks)	das „Harness“ einer Codebasis (das Gerüst rund um das Modell)	Einbindung nativer Feedback-Instrumente (Tests, Linter, CI) in die Schleife des Agenten
Träumen (Anthropic, OpenAI)	der Speicher einer Plattform	Auswertung des Sitzungsverlaufs in Gated-Memory-Diffs während der Leerlaufzeit, flottenweit
LangSmith Engine / Braintrust Topics	ein Observability-Stack	Produktionsausfälle zu Problemen zusammenfassen, PRs und Bewertungen erstellen
Werkssignale	eine Maklerplattform	Erkennung von Mustern bei Sitzungsproblemen und automatische Erstellung von Supportanfragen
Einblicke in die gh-aw-Sitzung (GitHub)	die Sitzungen einer Plattform	Automatisierte Berichte zur Sitzungsanalyse über mehrere Durchläufe des Agenten-Workflows hinweg (Beispiel mit 50 Sitzungen)
Feedback-Schwungrad (Garg)	die Artefakte eines Teams	Erfahrungen in Einführungsdokumente, Befehle, Playbooks und Leitlinien einfließen lassen

Lesen Sie die mittlere Spalte noch einmal: ein Praktiker, eine Sitzung, eine Plattform, ein Stack. Nahezu jeder Prozess in diesem Bereich läuft auf Einzel- oder Flottenebene ab: eine Person und ihr Agent oder ein Anbieter und seine gesamte Installationsbasis. Nur Gargs „Flywheel“ bezieht das Team mit ein, und seine Kadenzliste nennt den Rahmen (einen Tagesordnungspunkt in der bestehenden Sprint-Retrospektive), ohne ihn jedoch zu operationalisieren. Das ist unsere Interpretation dieser Art von Ansatz, und genau hier zeigt sich der eigene Blickwinkel dieses Leitfadens: Die Teamebene ist die offene Ebene (viele Personen, viele Agenten, mehr als ein Tool, wobei die Verantwortlichen für die Fehlerbehebung am selben Gespräch beteiligt sind). Wenn Sie einen der oben genannten Kreisläufe betreiben, führen Sie ihn weiter aus; die Teamebene nutzt deren Ergebnisse, sie steht nicht in Konkurrenz zu ihnen.

Die Klassifizierungssysteme

Um Reibungspunkte zu bündeln, benötigen Sie Kategorien, und die Schemata der einzelnen Fachgebiete klassifizieren unterschiedliche Dinge; sie sind weniger Konkurrenten als vielmehr Instrumente, die auf unterschiedliche Fragestellungen ausgerichtet sind:

Schema	Was es klassifiziert	Form	Zuverlässigkeit / Herkunft
MAST	Wie Multi-Agenten-Systeme versagen	14 Modi / 3 Kategorien	150 von Experten geprüfte Spuren, validiert anhand von über 1.600; Inter-Annotator-Kappa = 0,88
Schule der Fehleranalyse (Husain/Shankar)	was auch immer Ihre eigenen Spuren zeigen	offen; die Kategorien ergeben sich aus Ihren Daten	Methodik, kein festes Schema; das Auswerten Ihrer Traces ist „die wichtigste Tätigkeit bei der Bewertung“
Vierlagig (Greyling)	Welche Ebene des Stacks ist ausgefallen?	4 Schichten	Zusammenfassung von Feldausfallberichten; ca. 9,9 % der Ausfälle sind auf die Modelllogik zurückzuführen
TraceProbe	Aktionen zur Fehlerbehandlung in Trace-Aufzeichnungen	9 Maßnahmen	automatisierte Spurenanalyse
Werkssignale	Welches Symptom einer Reibung zeigt eine Sitzung?	7 Signaltypen	Produktionssitzungen mit Codierungsagenten
Unser Vokabular zu den Grundursachen	Warum es zu Reibungen bei der Zusammenarbeit kam	10 Kennzeichnungen / 5 Gruppen; die Gruppe kodiert die feste Höhe	Arbeitssitzungen, Entwickler und Nicht-Entwickler; die Interrater-Reliabilität wurde noch nicht gemessen: Das Experiment läuft derzeit, und das Vokabular ist versioniert und kann überarbeitet werden

Zwei Anmerkungen zum Text. Erstens unterscheiden sich die Achsen tatsächlich voneinander: Symptomschemata (Signale der Factory) zeigen Ihnen an, dass eine Sitzung fehlgeschlagen ist; Ebenenschemata (Four-Layer) zeigen Ihnen, an welcher Stelle im Stack; ein Ursachenvokabular erklärt Ihnen das „Warum“ – und genau das ermöglicht es einer Kennzeichnung, ihre eigene Lösung teilweise selbst zu lenken (ein work-material-frictionBefund verweist auf das Material selbst: technische Schulden im Code oder ein verworrenes Konto, ein Board oder eine Vorlage außerhalb des Codes; eine Briefing-Kennzeichnung verweist auf den Prozess). Zweitens ist die Spannung zwischen universellen und emergenten Kategorien real: Feste Taxonomien gewährleisten Vergleichbarkeit und messbare Zuverlässigkeit der Kennzeichnung (MASTs κ = 0,88 ist der Maßstab), während emergente Kategorien Ihrer tatsächlichen Fehlerverteilung entsprechen. Ein praktikabler Mittelweg besteht darin, ein kleines festes Vokabular für die Aggregation beizubehalten und unter jeder Bezeichnung offen codierte Belegnote anzubringen. Und eine Warnung, die sich das gesamte Fachgebiet verdient hat: Bezeichnungen im agent-error-Stil sollten die Ausnahme sein, nicht die Regel. Die „Harness-Engineering“-Schule lehnt diesen Reflex ausdrücklich ab, bei dem der Ingenieur dem Modell die Schuld gibt und es unter „Warten auf die nächste Version“ abheftet; stattdessen sollte man den „Harness“ reparieren (Osmani, Agent Harness Engineering). Die Vier-Schichten-Analyse führt nur etwa 9,9 % der Fehler auf die Modelllogik zurück.

Bestimmen Sie Ihren Standort

Eine kurze Bestandsaufnahme. Gehen Sie die einzelnen Schritte durch und markieren Sie, was Sie bereits haben:

• Sie verfügen über Protokolle oder Sitzungsprotokolle (Observability-Tools, JSONL auf Festplatte, serverseitiger Verlauf) → Erkennung und Aufzeichnung sind damit abgedeckt. Die Zahlen von LangChain deuten darauf hin, dass die meisten Teams an dieser Stelle aufhören.
• Etwas erinnert den Agenten daran, Reibungsverluste zu protokollieren (eine Fertigkeit, ein Stopp-Hook, eine Konvention in der Kontextdatei) → Die Instrumentierung ist damit abgedeckt; falls nichts davon zutrifft, ist dies in der Regel die kostengünstigste erste Abhilfe.
• Sie aktualisieren AGENTS.md / CLAUDE.md, wenn etwas wiederholt auftritt → Sie betreiben Synthese auf Solo-Ebene, das „denselben Fehler zweimal machen“-Muster aus dem Codex.
• Ihre Plattform kuratiert Erinnerungen für Sie (Konsolidierung im „Dreaming“-Stil, Copilot-Gedächtnis) → Erfassung und Synthese auf Flottenebene innerhalb dieser Plattform.
• Ihr Observability-Stack bündelt Fehler und Entwürfe für Behebungsmaßnahmen (Engine, Topics, Signals) → Synthese auf Stack-Ebene für den Datenverkehr, den der Stack erfasst.
• Jemand gibt regelmäßig einen Überblick über verschiedene Sitzungen, Personen und Tools, und die Verantwortlichen für die Fehlerbehebung treffen gemeinsam eine Entscheidung → Erfassung und Synthese auf Teamebene. Diese Zeile lassen die meisten Teams leer.

Die häufigste Lücke besteht unserer Beobachtung nach in dieser letzten Zeile: der Gesamtüberblick über Tools und Mitarbeiter sowie die daraus resultierenden Ermessensentscheidungen: Beibehalten oder streichen, auf welcher Ebene, wessen Priorität. Beachten Sie die damit verbundene Frage nach dem Umfang der Überprüfung: Welche Arbeit gehört in einen Bereich für eine bestimmte Diskussion? Das Repository, das Produkt, das Anzeigenkonto, der Support-Posteingang, die Kundenbetreuung? Legen Sie den Umfang danach fest, wo Korrekturen umgesetzt würden, und lassen Sie die Fälle außerhalb des Codes ebenso natürlich zuweisen wie die im Code.

Im weiteren Verlauf dieses Leitfadens werden die einzelnen Ebenen nacheinander behandelt: Der Einstieg erzählt die Geschichte in Form einer Erzählung; in den folgenden Kapiteln geht es um die Erfassung von Reibungspunkten im Moment, das Sammeln von Erkenntnissen über mehrere Sitzungen hinweg, die Entscheidung über die Höhe sowie darum, wie ein Veranstaltungsort auf Teamebene in der Praxis aussieht. Beginnen Sie dort, wo sich Ihre leere Zeile befindet.

Nächstes Kapitel: So sieht eine gute Reibungsprotokollierung aus befasst sich mit der Erfassung im Moment, den Kennzeichnungen der Grundursachen und den Regeln für nicht zu protokollierende Ereignisse.