Wo soll die Korrektur ansetzen?

Zwei Mannschaften, gleiche Reibung, unterschiedliches Viertel

Zwei Teams beginnen beide damit, die Probleme zu protokollieren, auf die ihre KI-Agenten stoßen: die unklaren Anfragen, die veralteten Dokumente, die unzuverlässigen Tools, die wiederholten Ausführungen.

Das erste Team behebt alle Probleme auf der Ebene, die gerade am nächsten liegt. Jedes wiederkehrende Ärgernis wird zu einer spontanen Anpassung oder einer Notiz zur Erinnerung; alles, was darüber hinausgeht, wird zu einem weiteren Absatz in der Kontextdatei. Drei Monate später laufen ihre Agenten mit aufgeblähten Anweisungen, die niemand von Anfang bis Ende liest, und die entscheidenden Reibungspunkte – die kurze Vorlage, die den Umfang undefiniert lässt, das Anzeigenkonto, dessen Struktur bei jeder Sitzung Probleme bereitet – sind immer noch vorhanden, da keine sofortige Anpassung diese Probleme beheben kann.

Das zweite Team stellt pro Muster eine zusätzliche Frage: Wo gehört diese Korrektur eigentlich hin? Der Cluster „Die Mitarbeiter raten ständig, wer unsere Zielgruppe ist“ führt zu einer Änderung bei der Arbeitsbesprechung: eine Prozesskorrektur, die in einer Teambesprechung vereinbart wurde. Aus dem Cluster „veraltetes Runbook“ wird eine Korrektur in der Dokumentation mit einem Verantwortlichen. Die einmalige Eigenart wird zu einer Notiz zur Erinnerung und nichts weiter. Drei Monate später sind ihre Anleitungsdokumente kürzer als zu Beginn, und die von ihnen behobenen Reibungspunkte weisen einen rückläufigen Trend auf.

Der Unterschied liegt nicht in der Disziplin bei der Protokollierung. Beide Teams haben Protokoll geführt. Der Unterschied liegt in einer Frage zur Routenführung, die das erste Team nie gestellt hat.

Der entscheidende Schritt: Reibungspunkte in der Höhe

Wenn es bei einer KI-gestützten Sitzung zu Schwierigkeiten kommt, liegt die eigentliche Ursache auf einer Ebene, auf der die dauerhafte Lösung zu finden ist. Wir bezeichnen dies als die Ebene der Lösung; die verfügbaren Ebenen reichen von vorübergehenden bis hin zu strukturellen:

Gedächtnis → Kompetenz/Anleitung → Umgebung und Konfiguration → Dokumentation → das Arbeitsmaterial selbst → Prozess/Arbeitsablauf → vorgelagertes Produkt oder Anbieter

Indem man das Problem konkret benennt, wird aus einer Beschwerde eine behebbare Maßnahme. „Der Mitarbeiter hat die Gebotsstrategie wieder falsch umgesetzt“ ist eine Beschwerde. „Die Entscheidung zur Gebotsstrategie wurde nirgendwo schriftlich festgehalten, sodass der Mitarbeiter sie nicht finden konnte: eine Korrektur in der Dokumentation, und hier ist das Runbook, in das sie gehört“ ist ein Arbeitsauftrag mit einem konkreten Anhaltspunkt.

Eine falsche Einschätzung der Tragweite hat zwei negative Auswirkungen. Unterzielung – eine private Notiz, die eigentlich ein fehlendes Teamdokument ersetzt – bedeutet, dass die Reibungsverluste für alle außer Ihnen erneut auftreten: eine Wiederholungsbelastung für den Rest des Teams. Überzielung (eine neue Kompetenz für einen einmaligen Vorgang, ein weiterer Absatz in einer ohnehin schon überladenen Kontextdatei) ist eine Wartungsbelastung für das Artefakt; in der Fachliteratur wurden diese Anti-Muster präzise benannt: Kompetenzausuferung (16→48 Kompetenzen in 15 Tagen: „Fähigkeiten hinzuzufügen ist einfach. … Die Verwaltung ist der schwierige Teil.“) und die Aufblähung von Kontextdateien („eine Gedächtnisdatei, die nicht mehr gelesen wird“, gemäß dieser Feldnotiz). Die Anbieter haben sich vom anderen Ende her auf denselben Gradienten geeinigt – kurzlebige Speicherinhalte zurückstufen, dauerhaftes Lernen in der Versionskontrolle fördern: Windsurf/Devin („Schreiben Sie es als Regel oder fügen Sie es zu AGENTS.md hinzu … anstatt sich auf automatisch generierte Speicherinhalte zu verlassen“, Dokumentation), OpenAI Codex („Wenn Codex denselben Fehler zweimal macht, bitten Sie ihn um eine Retrospektive und aktualisieren Sie AGENTS.md“, Best Practices), die bewusste 28-tägige Gültigkeitsdauer des Copilot-Speichers.

Die Fachwelt kennt also beide Ausfallarten. Was bisher gefehlt hat, ist ein Instrument zur Fehlerverfolgung.

Ein festgelegter Wortschatz, der die Weiterleitung steuert

Unser Arbeitsvorschlag: Ordnen Sie jedem festgestellten Reibungspunkt genau eine Grundursache aus einem festgelegten Vokabular von zehn Bezeichnungen in fünf Gruppen zu: klein genug, um sie im Kopf zu behalten, eher ursachen- als symptomorientiert und bewusst werkzeug- und disziplinunabhängig:

• Einweisung: ambiguous-instruction, missing-context, incorrect-context, changed-requirements
• Dokumentation: missing-documentation, incorrect-documentation
• Arbeitsmaterial: work-material-friction
• Werkzeuge: missing-access-or-tool, environment-friction
• Agent: agent-error

Die Gruppe ist der Routing-Schlüssel. Sobald ein Befund gekennzeichnet ist, ist er bereits zur Hälfte geroutet:

Gruppendominant	Die Korrektur befindet sich in der Regel unter	Typische Artefakte
Einweisung	Prozess (die Art und Weise, wie Arbeitsaufträge erteilt werden) oder ein persistenter Speicher	Vorlage für eine Kurzbeschreibung, Checkliste für den Projektstart, Dokumentationsordner
Dokumentation	Dokumente	README, Runbook/SOP, Kontextdatei, Spezifikation
Arbeitsmaterial	das Material selbst	Code: die Umstrukturierung, auf die „friction“ immer wieder hinweist; Nicht-Code: die Umstrukturierung des Kontos, des Forums oder der Vorlage
Werkzeuge	environment/config oder Upstream	Einstellungen, MCP-Konfiguration, Zugriffsberechtigung, Hersteller-Ticket
Agent	Aufforderung, Fertigkeit oder Leitplanke	Fähigkeit bearbeiten, Hook, auswerten

Zunächst ein Hinweis zur Klarstellung: Die Gruppen sind nach ihren Fix-Zielen benannt, sodass die Aussage „Die Bezeichnung legt den Fix zur Hälfte fest“ konstruktionsbedingt zutrifft – es handelt sich um eine Designentscheidung, nicht um eine empirische Erkenntnis. Die zugrunde liegende empirische Behauptung lautet, dass die zum Zeitpunkt der Erfassung vergebenen Bezeichnungen genau und konsistent sind, was genau das ist, was wir bisher noch nicht gemessen haben (mehr dazu weiter unten).

Beachten Sie, waswork-material-frictiondamit abgedeckt wird, denn genau darin liegt der Grund für den fachbereichsübergreifenden Anspruch dieses Vokabulars. Im Programmcode handelt es sich um „Tech Debt“: das Modul, über das jede Sitzung stolpert. Auch außerhalb des Codes ist dies ebenso real. Stellen Sie sich ein Marketingteam vor, dessen Mitarbeiter ein Google-Ads-Konto überprüft, das durch schrittweises Wachstum entstanden ist: drei Generationen von Namenskonventionen, pausierte Kampagnen, die niemand zu löschen wagt, sowie Schlüsselwörter, die sich überlappenden Anzeigengruppen hinweg doppelt vorkommen. In jeder Sitzung verbringt der Mitarbeiter die erste Zeit damit, zu rekonstruieren, welche Kampagne zu was gehört, und jede Empfehlung ist mit einem Vorbehalt verbunden. Keine schnelle Lösung kann hier Abhilfe schaffen; keine Notiz hilft dem Nächsten weiter. Die Bezeichnung lautet „technische Schulden“ work-material-frictionund ist stets mit dem konkret benannten Material (diesem Konto) verbunden; der Kern des Problems ist das Material selbst: die Umstrukturierung, auf die die Reibungspunkte immer wieder hinweisen. Das gleiche Muster findet sich in verworrenen Tabellenkalkulationen, chaotischen CMS-Vorlagen und Support-Makro-Bibliotheken; eine durch Programmierer geprägte Schleife kann diese Probleme nirgendwo unterbringen.

Warum „festgelegt“ statt „sich herausbildend“? Weil die Taxonomie für ein Team ein Koordinationsinstrument ist und keine Klassifizierungsübung. „Die gleiche Reibung über acht Sitzungen hinweg ist ein Prozessproblem“ gilt nur, wenn alle acht Sitzungen dies einheitlich so bezeichnet haben; Aussagen zur Verteilung benötigen einen stabilen Nenner; und Trendlinien („Ist die Reibung bei der Briefing-Vorbereitung zurückgegangen, seit wir die Briefing-Vorlage festgelegt haben?“) sind nur dann aussagekräftig, wenn eine Bezeichnung im März und im Juli dasselbe bedeutet. Emergent entstandene Kategorien, bei denen jede Person ihre eigene Kodierung vornimmt, sind im Alleingang die richtige Wahl, doch im Team weichen sie je nach Person voneinander ab, und ohne einen Abgleichschritt, für den niemand verantwortlich ist, lässt sich nichts aggregieren. Wir halten den Mechanismus zur Erkennung neu entstehender Kategorien an zwei Stellen am Laufen: durch eine mit Belegen untermauerte Anmerkung unter jeder Bezeichnung sowie durch eine regelmäßige Überprüfung des Vokabulars, bei der die gesammelten Anmerkungen die Bezeichnungen auf ihre Stichhaltigkeit hin überprüfen. Das Vokabular ist versioniert; es ist darauf ausgelegt, sich anhand von Belegen zu ändern, und nicht, verteidigt zu werden.

Was bereits existiert – ein ehrlicher Vergleich

Wir haben die Klassifikationen von Fehlern nicht erfunden, und die bestehenden erfüllen ihren Zweck sehr gut.

MAST (arXiv 2503.13657) ist die maßgebliche, festgelegte Taxonomie: 14 Fehlermodi in 3 Kategorien, abgeleitet aus 150 von Experten untersuchten Ablaufverläufen und validiert anhand eines Korpus von über 1.600 Fällen, mit hoher Übereinstimmung zwischen den Annotatoren (κ = 0,88). Sie klassifiziert, wie Multi-Agenten-Systeme versagen, und wurde für Forschungszwecke und Benchmarking entwickelt – fachlich am nächsten an unserer Arbeit, jedoch mit einem anderen Gegenstand: Wir klassifizieren, warum es zu Reibungen bei der Zusammenarbeit zwischen Mensch und Agent kam.

Die Schule der Fehleranalyse, die Evaluierungsmethodik von Husain & Shankar (evals FAQ, Jan. 2026), vertritt das Gegenteil einer festen Liste: Kategorien „sollten sich aus beobachteten Fehlermustern ergeben … nicht aus vorab festgelegten Abfrageklassifikationen“, und die offene Auswertung der eigenen Protokolle ist „die wichtigste Aktivität bei Evaluierungen“.“ Wir sind der Ansicht, dass sie auf Einzelebene Recht haben und dass sich das Verhältnis auf Teamebene aus den oben genannten Gründen der Aggregation umkehrt. Ihre Auswertungsdisziplin ist in unserem Vorschlag in jedem Fall von zentraler Bedeutung; genau das machen die Evidenznotizen aus.

Um diese Pole herum: Die Vier-Ebenen-Taxonomie (Greyling, Mai 2026) klassifiziert, welche Ebene des Stacks versagt hat, wobei nur etwa 9,9 % der Fehler der Modelllogik zugeschrieben werden: Die meisten Fehler sind Probleme des Harness (der Harness ist das Gerüst um das Modell herum), weshalb unsereagent-error Kennzeichnung eine Restkategorie darstellt, die nur dann verwendet wird, wenn die Eingaben angemessen waren (die „Harness-Engineering“-Schule lehnt die Standardannahme, dem Agenten die Schuld zu geben, ausdrücklich ab – man muss den Harness reparieren, nicht den Agenten: Osmani, Agent Harness Engineering). TraceProbe klassifiziert Aktionen zur Fehlerbehandlung in Ablaufverfolgungen. Gargs Feedback-Flywheel bündelt vier Signaltypen in Team-Artefakte – das Framework, in dem sich unser Ansatz befindet: Sein Kontext ≈ unsere Briefing- und Dokumentationsgruppen; sein „Failure Arm“ entspricht dem, was unsere Taxonomie aufschlüsselt. Factory Signals klassifiziert Symptome von Sitzungen in automatisch erstellte Tickets; Braintrust Topics ist das produktisierte Ergebnis dieser neuen Denkschule, das Ihre Trace-Daten täglich neu gruppiert.

Zwei ehrliche Betrachtungen dieses Vergleichs. Erstens klassifizieren die meisten dieser Ansätze Symptome, Ebenen oder Ziele; unser Ansatz klassifiziert Ursachen – genau das macht die Bezeichnung zu einem Routing-Schlüssel, und darin liegt der eigentliche Neuheitsanspruch, so wie er ist. Zweitens, und noch wichtiger: MAST hat die Zuverlässigkeit der Kennzeichnung gemessen, wir hingegen nicht. Die Interrater-Reliabilität unserer zehn Bezeichnungen wurde nicht gemessen, und wir betrachten dies als Grundvoraussetzung, nicht als Randbemerkung: Das Experiment (bei dem unabhängige Bewerter dieselben realen Einträge blind kennzeichnen, wobei die Übereinstimmung unabhängig vom Ergebnis berichtet wird) läuft derzeit mit Einträgen aus unserem eigenen Live-Test, wobei der κ-Wert von MAST (κ = 0,88) als Maßstab dient. Bis die Ergebnisse vorliegen, handelt es sich bei dieser Taxonomie um einen Arbeitsvorschlag mit versionierten Bezeichnungen und nicht um ein validiertes Instrument. Wir möchten Ihnen dies lieber mitteilen, als dass Sie es selbst herausfinden.

Wir unterstützen zudem alle bereits laufenden Loops: Loop Engineering, Compound Engineering, agent-retro, AGENTS.md-Retrospektiven, Vendor-Speichersysteme sowie automatisierte Sitzungsberichte. Behalten Sie sie alle bei; nichts hier ersetzt sie.

Warum die Höhenlage eine Frage des Teams ist

Hier liegt die Gemeinsamkeit dieser bestehenden Kreisläufe: Fast alle sind „Solo“-Lösungen (ein Entwickler und sein Agent oder ein Anbieter und seine Flotte). Und die Zahlen aus der Branche selbst zeigen, dass der kostspielige Schritt nicht die Überwachung ist: Etwa 90 % der Teams erfassen Agent-Traces, aber nur etwa 37–52 % werten diese systematisch aus (LangChain State of Agent Engineering, Juni 2026). Die noch unerschlossene Ebene ist die Synthese auf Teamebene, und genau hier kommt es aus zwei Gründen auf die übergeordnete Perspektive an.

Durch die Aggregation werden Prioritäten neu gewichtet. Was für eine Person ein zehnminütiges Ärgernis darstellt, ist nur „Rauschen“; niemand würde dies rational beheben. Derselbe Begriff, der in acht Sitzungen und bei fünf Personen verwendet wurde, stellt einen der größten Kostenfaktoren des Teams dar, und dies lässt sich nur anhand der aggregierten Sichtweise erkennen. Die Aggregation ist auch der Vorteil eines festgelegten Vokabulars: Die Zahlen ergeben nur dann Sinn, wenn alle dieselben Begriffe verwendet haben.

Die höchsten Ebenen liegen in der Verantwortung des Teams. Eine einzelne Person kann ihre eigenen Erinnerungen, Anweisungen und Einstellungen festlegen. Doch Prozessänderungen, werkzeugübergreifende Ermessensentscheidungen, das Budget für Werkzeuge sowie Eskalationen an übergeordnete Ebenen – also jene Ebenen, auf denen in der Regel die größten wiederkehrenden Reibungspunkte liegen – sind Entscheidungen, die keine Einzelperson allein treffen kann. Dies ist auch der Grund, warum wir der Ansicht sind, dass ein menschlicher Platz in der Synthese auch dann bestehen bleibt, wie gut die Modelle auch immer werden mögen: Die Korrekturen fließen in Artefakte ein, für die Menschen verantwortlich sind und Rechenschaft ablegen: Briefings, Prozesse, Budgets, Teamvereinbarungen. Das ist eine Aussage über organisatorische Autorität, nicht über die Leistungsfähigkeit von Modellen. Und es handelt sich um eine Rolle im Entscheidungsprozess, nicht um eine Sperre in der Pipeline: Agenten sollten frei erkennen, aufzeichnen, gruppieren und Entwürfe erstellen; Menschen fügen die Entscheidung über den weiteren Weg hinzu und tragen die Verantwortung.

Falls Ihr Team bereits eine Zeremonie zur kontinuierlichen Verbesserung durchführt, fügt sich dies nahtlos darin ein: Die Gesamtübersicht über die Reibungsverluste wird vorgelegt, das Team fragt: „Wo wird die jeweilige Korrektur ansetzen?“, und jedes Muster wird mit einer Prioritätsstufe und einem Verantwortlichen versehen. Kein neues Ritual – eine Retrospektive mit besseren Inputs. ML-Ingenieure bezeichnen dies als Fehleranalyse; Teams nennen diese Veranstaltung eine „Retro“.

Was könnte uns umstimmen?

Da es sich hierbei um ein Diskussionspapier handelt, möchten wir Ihnen die Punkte darlegen, bei denen wir uns tatsächlich unsicher sind:

• Zuverlässigkeit. Sollte das Interrater-Experiment eine geringe Übereinstimmung ergeben, sind die Abgrenzungsregeln (oder die Bezeichnungen selbst) falsch, und wir werden diese unter dem Versionsstempel überarbeiten, anstatt sie zu verteidigen.
• Größe. Die Anzahl von zehn Etiketten ist vorgegeben und nicht abgeleitet. Bei MAST sind es 14, bei Four-Layer 4. Unsere Etikettenverteilung nach einem Viertel der tatsächlichen Einträge ist der Beleg dafür, ob diese Zahl beibehalten oder angepasst wird.
• environment-frictionFehlende Modi. Reibungsverluste zwischen Agenten (Verlust bei der Übergabe zwischen Unteragenten, Koordinationsfehler) werden derzeit unter [ ] erfasst; konkrete Vorkommnisse erfordern möglicherweise eine eigene Bezeichnung.
• Umfang der Nicht-Code-Prüfung. Wir legen den Umfang der Prüfungen danach fest, wo die Korrekturen umgesetzt werden: im Repository für den Großteil der Entwicklungsarbeit; außerhalb davon unter „Konto“, „Arbeitsbereich“ oder „Auftrag“. Diese Nicht-Code-Grenzen sind Vorschläge, die wir anhand realer Teams testen möchten.
• Durchführbarkeit zum Zeitpunkt der Erfassung. Können stark ausgelastete Teams Ursachen direkt im Moment kennzeichnen, oder muss die Kennzeichnung erst bei der Nachbesprechung erfolgen? Teams, die dies ausprobieren, würden diese Frage schneller klären, als wir sie theoretisch erörtern könnten.

Sollten Sie eine beliebige Version dieses Kreislaufs ausführen (emergente Kategorien, eine Anbieter-Pipeline, eine einfache Tabellenkalkulation), würden wir gerne erfahren, an welcher Stelle die Routing-Tabelle versagt. Insbesondere, wenn Sie uns ein Reibungsmuster aufzeigen können, das überhaupt nicht auf eine Höhe hinweist: ai-discussion@teamretro.com.

---

Nächstes Kapitel: Der Bericht existiert. Der Raum nicht. – warum die Zuweisung der Korrekturmaßnahmen eine Teamentscheidung ist und wie das Team vorgeht, wenn der Friktionsbericht eintrifft. Teil des Leitfadens für Retrospektiven mit KI-Agenten.