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, lesen Sie zunächst den 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 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 Ergebnisse bezeichnen? Alles hier ist in sich geschlossen: 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 Reibungspunkte 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: 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 Befehlszeilenschnittstelle · Web · IDE · CI/Headless · zeitgesteuert	k. A.
1 · Erkennung	Wie lässt sich Reibung feststellen?	Selbstüberprüfung · Überprüfung durch einen sekundären 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 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	k. A.
5 · Synthese und gezielte Ausrichtung	Rohdatensätze → Muster → In welchem Umfang sollte eine Korrektur erfolgen?	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 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 gegenüber der Reproduzierbarkeit und der 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 Transkript 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 zuerst von einem Menschen entdeckt wurden, dem auffiel, dass etwas nicht stimmte (arXiv 2606.14589). Telemetrie (Fehlerraten der Tools, verweigerte Berechtigungen, Schleifenzahlen) erfolgt automatisch, ist jedoch oberflächlich: Sie weiß was, nicht warum. Die leistungsfähigsten Verfahren nutzen eine dreifache Überprüfung: 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, 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 Reibungspunkte unerfasst: Niemand hat den Agenten angewiesen, danach zu suchen.

Phase 3: Aufzeichnung

Zwei Fragen: Was macht einen guten Datensatz aus, und wo wird er gespeichert? Ein nützlicher Datensatz enthält Belegangaben (was geschah, 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, so gibt es jeweils einen echten Kompromiss: Speicherdateien (dauerhaft und reibungslos, jedoch 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 mit Tags versehene Commits und PRs, z. B. ein Tagwork-material-friction, 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 Aufzeichnungsmedien gilt, auf die sich Agenten später stützen: Von Agenten geschriebene Speicherdaten stellen eine bekannte Angriffs- und Drift-Oberfläche dar (OWASP Agentic Top 10, ASI06) – ein Argument für belegte und überprüfte Schreibvorgänge.

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 gegenüber der Erfassung am Sitzungsende) und die wenig glamouröse Arbeit der Dublettenbereinigung: Dieselbe Reibung, die von fünf Personen auf fünf verschiedene Arten formuliert wurde, muss zu einem Muster mit einer ehrlichen Zählung zusammengefasst werden. Bei der Ernte 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 Summe einen erheblichen Kostenfaktor für das Team dar. Ein anschauliches Beispiel für die Ernte über Personen hinweg statt nur über Sitzungen hinweg finden Sie darin, wie fünf von uns unsere privaten Erinnerungen an den Claude-Code zu gemeinsamen Regeln zusammengefasst haben.

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 Lösung 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 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 Gradienten zubewegt: vorübergehendes Gedächtnis zurückstufen, dauerhaftes Lernen in die Versionskontrolle überführen. In den Dokumenten von Windsurf/Devin heißt es, wiederkehrende Erkenntnisse sollten in Regeln oder in die Datei „AGENTS.md“ (die Datei mit den festen Anweisungen, die Agenten lesen) überführt werden, anstatt sich auf automatische Gedächtnisabläufe 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 von Design her nach 28 Tagen ab: 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 die Reibung dieser Art 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 Gargs „Feedback-Flywheel“-Prinzip und die Prämisse des Compounding Engineering: Jede Korrektur 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 Folgendes ist zu beachten, sobald die Tabelle sortiert ist:

Schleife	Läuft um	Schließt den Kreis, indem
Loop Engineering / Verbundwerkstofftechnik	ein Praktizierender	persönliche Regeln, Anweisungen, Leitfäden
continuous-learning-v2 (Everything Claude Code)	ein Praktizierender	ein im Hintergrund laufender Agent, der Werkzeugaufrufprotokolle in Regeln mit Konfidenzbewertung umwandelt, die zu Beginn der Sitzung geladen werden
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
Dreaming (Anthropic, OpenAI)	der Speicher einer Plattform	Auswertung des Sitzungsverlaufs in Gated-Memory-Diffs während der Leerlaufzeit, flottenweit
LangSmith-Engine / Braintrust-Themen	ein Observability-Stack	Produktionsausfälle zu Problemen zusammenfassen, PRs und Bewertungen erstellen
Werkssignale	eine Maklerplattform	Erkennung von Mustern bei Sitzungsproblemen und automatische Erstellung von Support-Tickets
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)
Rückkopplungsschwungrad (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 sein gesamter Kundenstamm. 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 aus; die Teamebene nutzt deren Ergebnisse, sie steht nicht in Konkurrenz zu ihnen.

„Everything Claude Code“ (ECC), ein unter der MIT-Lizenz stehendes Projekt, ist das anschaulichste Beispiel auf dieser Karte für einen lokalen Regelkreis, in dem der Agent seine eigenen Regeln schreibt. Seine „Continuous-Learning-v2“-Fähigkeit (ECC 2.2.3 zum Zeitpunkt der Erstellung dieses Artikels) protokolliert Tool-Aufrufe über einen Claude-Code-Hook. Ein im Hintergrund auf Haiku laufender Beobachter-Agent liest dieses Protokoll in regelmäßigen Abständen aus und schreibt „Instinkte“: kurze Regeln aus Auslöser und Aktion, jeweils mit einem Konfidenzwert, der steigt, wenn das Muster erneut erkannt wird, und von Woche zu Woche abnimmt, wenn dies nicht der Fall ist. Zu Beginn einer Sitzung werden standardmäßig bis zu sechs Instinkte mit einem Konfidenzwert von 0,7 oder höher direkt in den Kontext des Agenten übernommen, ohne dass ein Überprüfungsschritt erfolgt. Der Beobachter ist standardmäßig deaktiviert, sodass dessen Aktivierung eine bewusste Entscheidung darstellt. Für die Konfiguration einer einzelnen Person stellt dies einen vollständigen Regelkreis dar. Für einen Kontext, auf den sich ein ganzes Team stützt, würden wir stattdessen die Einträge filtern: Belege werden frei aufgenommen, Regeln durch Überprüfung ausgeschlossen.

Die Klassifizierungssysteme

Um Reibungspunkte zu gruppieren, 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 Protokolle ist „die wichtigste Tätigkeit bei Evaluierungen“
Vierlagig (Greyling)	Welche Ebene des Stacks ist ausgefallen?	4 Schichten	Zusammenfassung der Fehlerberichte aus der Praxis; ~9,9 % der Fehler sind auf die Modelllogik zurückzuführen
TraceProbe	Aktionen zur Fehlerbehandlung in Ablaufverfolgungen	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

Zwei 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 (eine work-material-frictionFeststellung 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 „universell“ und „emergent“ 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 kodierte Belegnotizen unter jeder Bezeichnung. Und eine Warnung, die sich das gesamte Fachgebiet redlich 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 Entwickler das Modell verantwortlich macht 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 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 „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 Korrekturen (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 alle Tools und Personen 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 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 Einleitungsabschnitt schildert die Geschichte in erzählerischer Form; in den folgenden Kapiteln geht es darum, wie man Reibungspunkte im Moment erfasst, Erkenntnisse über mehrere Sitzungen hinweg sammelt, die Entscheidung über die Höhe trifft und wie ein Veranstaltungsort auf Teamebene in der Praxis aussieht. Beginnen Sie dort, wo sich Ihre leere Zeile befindet.

Nächstes Kapitel: Wie eine gute Reibungsprotokollierung aussieht – darin geht es um die Erfassung des Augenblicks, die Kennzeichnung der Grundursachen und die Regeln für nicht zu protokollierende Ereignisse.