Wo sollte die Korrektur ansetzen?

Zwei Mannschaften, gleiche Reibung, unterschiedliche Viertel

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

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 nach aufgeblähten Anweisungen, die niemand von Anfang bis Ende liest, und die entscheidenden Reibungspunkte (die kurze Vorlage, die den Umfang undefiniert lässt, das Werbekonto, 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: Wohin gehört diese Korrektur eigentlich? Der Cluster „Die Mitarbeiter raten ständig, wer unsere Zielgruppe ist“ führt zu einer Änderung bei der Arbeitsbesprechung: eine Prozesskorrektur, die in einer Teamsitzung 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 Ursache auf einer Ebene, auf der auch 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 lösbare Aufgabe. „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 eine Arbeitsaufgabe mit einem konkreten Anhaltspunkt.

Eine falsche Einschätzung der Tragweite hat zweierlei 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 von der anderen Seite aus auf denselben Gradienten geeinigt: kurzlebige Erinnerungen 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 Erinnerungen 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 festes Vokabular, das weiterleitet

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 die Reibung 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 Schutzvorrichtung	Fähigkeit bearbeiten, Hook, auswerten

Zunächst eine Anmerkung zur Ehrlichkeit: Die Gruppen sind nach ihren Fix-Zielen benannt, sodass die Aussage „Die Bezeichnung bestimmt den Fix zur Hälfte“ konstruktionsbedingt zutrifft – es handelt sich also um eine gestalterische Entscheidung und nicht um eine empirische Erkenntnis. Die zugrunde liegende empirische Behauptung lautet, dass die Zeitstempel zum Zeitpunkt der Erfassung genau und konsistent sind – genau das haben wir jedoch noch nicht gemessen (mehr dazu weiter unten).

Beachten Sie, was damit abgedecktwork-material-friction 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 Hinzufügen gewachsen ist: drei Generationen von Namenskonventionen, pausierte Kampagnen, die niemand zu löschen wagt, sowie Suchbegriffe, die sich überlappenden Anzeigengruppen hinweg doppelt vorkommen. In jeder Sitzung verbringt der Mitarbeiter die erste Zeit damit, zu rekonstruieren, welche Kampagne wofür zuständig ist, 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; die „Höhe“ ist das Material selbst: die Umstrukturierung, auf die die Reibung immer wieder hinweist. Das gleiche Muster findet sich in verworrenen Tabellenkalkulationen, chaotischen CMS-Vorlagen und Makrobibliotheken für den Support; eine durch Programmierer geprägte Schleife kann diese Elemente 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“ trifft nur zu, 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 innerhalb eines Teams weichen sie je nach Person voneinander ab, und es lässt sich nichts aggregieren, ohne einen Abgleichschritt, für den niemand verantwortlich ist. Wir halten den Mechanismus der spontanen Kategorisierung an zwei Stellen am Laufen: durch eine mit Belegen untermauerte Notiz unter jeder Bezeichnung sowie durch eine regelmäßige Überprüfung des Vokabulars, bei der die gesammelten Notizen die Bezeichnungen auf ihre Stichhaltigkeit hin überprüfen. Das Vokabular ist versioniert; es ist darauf ausgelegt, sich aufgrund von Belegen zu ändern, und nicht darauf, 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 feste Taxonomie: 14 Fehlermodi in 3 Kategorien, abgeleitet aus 150 von Experten geprüften Ablä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, wurde für Forschungszwecke und zum Benchmarking entwickelt, ist unserer Disziplin am nächsten, unterscheidet sich jedoch im 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 … und 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 Aggregationsgründen umkehrt. Ihre Auswertungsdisziplin ist in unserem Vorschlag in jedem Fall tragend; genau das sind die Evidenznotizen.

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 auf die Modellschlussfolgerung zurückgeführt werden: Die meisten Fehler sind „Harness“-Probleme (der „Harness“ ist das Gerüst um das Modell herum), weshalb unsere agent-errorKennzeichnung eine Restgröße darstellt, die nur verwendet wird, wenn die Eingaben angemessen waren (die „Harness-Engineering“-Schule lehnt die Standardannahme, dem Agenten die Schuld zu geben, ausdrücklich ab und korrigiert den „Harness“ anstelle des Agenten: Osmani, Agent Harness Engineering). TraceProbe klassifiziert Maßnahmen zur Fehlerbehandlung in Trace-Daten. Gargs Feedback-Flywheel bündelt vier Signaltypen in Team-Artefakte, dem Rahmenwerk, in das sich unser Ansatz einfügt: Sein Kontext ≈ unsere Briefing- und Dokumentationsgruppen; sein „Fehlerarm“ entspricht dem, was unsere Taxonomie aufschlüsselt. Factory Signals klassifiziert Symptome aus 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, was die Bezeichnung zu einem Routing-Schlüssel macht, und genau darin besteht 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 Kennzeichnungen ist nicht gemessen worden, 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-Memory-Systeme sowie automatisierte Sitzungsberichte. Behalten Sie sie alle bei; nichts hier ersetzt sie.

Warum die Höhenlage eine Frage der Mannschaft ist

Hier liegt die Gemeinsamkeit dieser bestehenden Kreisläufe: Fast alle sind „Solo“-Kreisläufe (ein Entwickler und sein Agent oder ein Anbieter und seine Flotte). Und die Zahlen aus der Branche selbst zeigen, dass der aufwendige 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 über acht Sitzungen und fünf Personen hinweg verwendet wird, stellt einen der größten Kostenfaktoren für das Team dar, und nur in der aggregierten Ansicht wird dies sichtbar. Die Aggregation ist auch das, was das festgelegte Vokabular ermöglicht: Die Zahlen ergeben nur dann Sinn, wenn alle dieselben Begriffe verwenden.

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, Eskalationen an übergeordnete Ebenen – also jene Ebenen, auf denen in der Regel die größten wiederkehrenden Reibungspunkte auftreten – sind Entscheidungen, die keine einzelne Person allein treffen kann. Dies ist auch der Grund, warum wir der Ansicht sind, dass ein menschlicher Platz in der Synthese bestehen bleibt, egal wie gut die Modelle auch 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 Entscheidungskreislauf, 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 ein: Die Gesamtübersicht über die Reibungspunkte 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, sondern lediglich eine Retrospektive mit besseren Eingaben. ML-Ingenieure bezeichnen dies als Fehleranalyse; Teams nennen diese Veranstaltung eine Retrospektive.

Was würde uns umstimmen?

Da es sich hierbei um ein Diskussionspapier handelt, möchten wir folgende Punkte ansprechen, bei denen wir uns wirklich 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 wird vererbt und nicht abgeleitet. MAST verwendet 14, Four-Layer 4. Unsere Etikettenverteilung nach einem Viertel der tatsächlichen Einträge ist der Beleg dafür, dass diese Anzahl beibehalten oder angepasst wird.
• Fehlende Modi. Reibungsverluste zwischen Agenten (Verlust bei der Übergabe von Unteragenten, Koordinationsfehler) werden derzeit unter […] geführtenvironment-friction; konkrete Vorkommnisse erfordern möglicherweise eine eigene Bezeichnung.
• Umfang der Überprüfungen außerhalb des Code-Bereichs. Wir legen den Umfang der Überprüfungen danach fest, wo die Korrekturen umgesetzt würden: im Repository für den Großteil der Entwicklungsarbeit; außerhalb davon in den Bereichen „Konto“, „Arbeitsbereich“ oder „Auftrag“. Diese Grenzen außerhalb des Code-Bereichs 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 Weiterleitung der Korrekturen eine Teamentscheidung ist und was das Team unternimmt, wenn der Friktionsbericht eintrifft. Teil des Leitfadens für Retrospektiven mit KI-Agenten.