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 dargelegt. Wenn Sie lieber mit der Geschichte beginnen möchten, starten Sie am Einleitungsteil des Leitfadens und kehren Sie anschließend hierher zurück.

Worum es auf dieser Seite geht

Drei Punkte, 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 von Fehlern 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 durch und mit welchem Vokabular würden Sie Ihre Ergebnisse bezeichnen? Alles hier ist für sich allein stehend: Nichts davon erfordert die Übernahme unserer Vorgehensweise, unserer Bezeichnungen oder unseres Produkts.

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

Wenn ein Mitarbeiter, der tatsächliche Arbeit verrichtet, 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 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: ~90 % der Teams erfassen Agentenverläufe, doch nur ~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 Befehlszeilenschnittstelle · Web · IDE · CI/Headless · zeitgesteuert	—
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	—
3 · Aufzeichnung	Wie wird dies erfasst, und wo?	Speicher · MCP-Speicher · Protokolle/Traces · Tickets · markierte Commits	offene Kodierung, episodisches Gedächtnis
4 · Ernte	Wie können Sie über eine einzelne Sitzung hinaus Informationen sammeln?	Trace-Mining vs. Artefakt-Aggregation · Sweep vs. Ereignis · Deduplizierung	—
5 · Synthese und gezielte Ausrichtung	Rohdatensätze → Muster → In welchem Umfang sollte eine Korrektur erfolgen?	Cluster + Punktzahl, anschließend nach Höhe sortieren	Axiale Kodierung, 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 Beenden 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 von 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, jedoch 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 etwas auffiel (arXiv 2606.14589). Telemetrie (Fehlerraten der Tools, verweigerte Berechtigungen, Schleifenzahlen) erfolgt automatisch, liefert jedoch nur oberflächliche Erkenntnisse – sie weiß was, nicht warum. Die leistungsstärksten Verfahren nutzen eine Kombination aus beiden: Die Telemetrie zeigt an, wo nachgeschaut werden muss, und eine Überprüfung erklärt, warum.

Phase 2: Instrumentierung

Ein Agent zeichnet Reibung nur dann auf, wenn etwas diese verursacht. 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: eindeutig, muss jedoch 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, auf Vertrauensbasis) 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 Reibungspunkte unerfasst: 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 geschehen ist, was es gekostet hat), ist mit einem Begriff 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, 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 einsehbar, jedoch pro Eintrag ressourcenintensiv) oder mit Tags versehene Commits und PRs, z. B. einwork-material-friction Label, 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 Drift-Oberfläche dar (OWASP Agentic Top 10, ASI06), was für belegte und überprüfte Schreibvorgänge spricht.

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, aber kostspielig und mit hohem Datenschutzaufwand verbunden) versus Artefakt-Aggregation (Durchsuchen der gezielt erstellten Aufzeichnungen: kostengünstig, aber nur so gut wie die Disziplin in Phase 3); echte Pipelines kombinieren beides. Dann die Kadenz (eine planmäßige Durchsicht im Vergleich zur 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 gezielte Ausrichtung

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 Ebene der Behebung weiter, von kurzfristigen bis hin zu strukturellen Maßnahmen (Gedächtnis → Fertigkeit/Aufforderung → Umgebung & Konfiguration → Dokumentation → das Arbeitsmaterial selbst → Prozess → vorgelagertes Tool oder Anbieter). Unterziel (eine private Gedächtnisnotiz für das, was 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 Ansatz geeinigt: 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 überführen, anstatt sich auf automatische Gedächtnisfunktionen zu verlassen. die Codex-Leitlinien von OpenAI besagen, dass der Fall „derselbe Fehler zweimal“ eine Aktualisierung von AGENTS.md nach sich zieht, und das Copilot-Gedächtnis läuft nach 28 Tagen ab – so ist es vorgesehen: Nicht befördertes Gedächtnis sollte 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, bezieht sich auf die Ebene, auf der die jeweilige Schleife abläuft – und worauf Sie achten sollten, sobald die Tabelle sortiert ist:

Schleife	Läuft um	Schließt den Kreis, indem
Loop-Engineering / Compound-Engineering	ein Praktiker	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, Pull-Requests und Bewertungen erstellen
Werkssignale	eine einzige 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 den gesamten Ablauf des agentenbasierten 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 konkret umzusetzen. 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 teilnehmen. Wenn Sie einen der oben genannten Kreisläufe betreiben, führen Sie ihn weiter fort; die Teamebene nutzt deren Ergebnisse und steht nicht in Konkurrenz zu ihnen.

Die Klassifizierungsschemata

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

Schema	Was darin klassifiziert wird	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 Evaluierungen“
Vierlagig (Greyling)	Welche Ebene des Stacks ist ausgefallen?	4 Schichten	Zusammenfassung von Ausfallberichten aus der Praxis; ~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 des Codierungsbeauftragten
Unser Vokabular zu den Grundursachen	Warum es zu Reibungen bei der Zusammenarbeit kam	10 Kennzeichnungen / 5 Gruppen; die Gruppe gibt die feste Höhe an	Arbeitssitzungen, Entwickler und Nicht-Entwickler; Interrater-Reliabilität noch nicht gemessen: Das Experiment läuft derzeit, und das Vokabular ist versioniert und überarbeitbar

agent-errorZwei Anmerkungen zum Text. Erstens unterscheiden sich die Achsen tatsächlich voneinander: Symptomschemata (Signale der Factory) zeigen Ihnen an, dass eine Sitzung fehlgeschlagen ist; Ebenen-Schemata (Four-Layer) zeigen Ihnen, an welcher Stelle im Stack; ein Ursachenvokabular erklärt Ihnen das „Warum“ – und genau das ermöglicht es einer Kennzeichnung, die Lösung teilweise selbst zu lenken (einwork-material-frictionBefund verweist auf das Material selbst – technische Schulden im Code oder ein verworrenes Konto, eine Tabelle 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, ergänzt durch offen codierte Belegnote unter jeder Bezeichnung. Und eine Warnung, die sich das gesamte Fachgebiet redlich verdient hat: Bezeichnungen im -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“ ablegt; stattdessen sollte man das „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 Funktion, 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 „Derselbe Fehler zweimal“-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 Korrekturen (Engine, Topics, Signals) → Synthese auf Stack-Ebene für den Datenverkehr, den der Stack erfasst.
• Jemand gibt regelmäßig einen Überblick über Sitzungen, Personen und Tools, und die Verantwortlichen für die Maßnahmen entscheiden gemeinsam → 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 dabei die damit verbundene Frage nach dem Umfang der Überprüfung: Welche Arbeit gehört in einen bestimmten Bereich für eine bestimmte Diskussion? Das Repo, 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 ablaufen wie die im Code.

Im weiteren Verlauf dieses Leitfadens werden die einzelnen Ebenen nacheinander behandelt: Der Auftakt erzählt die Geschichte in erzählerischer Form; in den nachfolgenden Kapiteln geht es um die Erfassung von Reibungspunkten im Moment, das Sammeln von Erkenntnissen über mehrere Sitzungen hinweg, die Entscheidung über die Ebene und 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 – Erfassung im Moment, die Kennzeichnungen der Grundursachen und die Regeln für nicht zu protokollierende Ereignisse.