Wo sollte die Korrektur ansetzen?

Zwei Mannschaften, gleiche Reibung, unterschiedliches Viertel

Zwei Teams beginnen gleichermaßen damit, die Hindernisse zu erfassen, auf die ihre KI-Agenten stoßen: die mehrdeutigen 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: 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 Teambesprechung vereinbart wurde. Aus dem Cluster „veraltete Betriebsanleitungen“ 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 zeigen einen rückläufigen Trend.

Der Unterschied liegt nicht in der Disziplin bei der Protokollführung. 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 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:

Erinnerung → 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 Bezugspunkt.

Eine falsche Einschätzung der Tragweite hat zwei negative Auswirkungen. Unterzielung – eine private Gedächtnisnotiz für das, was eigentlich ein fehlendes Teamdokument ist – bedeutet, dass die Reibungsverluste für alle außer Ihnen erneut auftreten: eine Wiederholungsbelastung für den Rest des Teams. Notizen, die bereits auf diese Weise verloren gegangen sind, können durch eine teamweite Gedächtniserhebung wiedergewonnen werden. **Überzielung (eine neue Fertigkeit 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 die Anti-Muster präzise benannt: Fertigkeitsausuferung (16→48 Fertigkeiten in 15 Tagen: „Fertigkeiten hinzuzufügen ist einfach. … Das Management 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 Trend 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 es 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, Archivdatei
Dokumentation	Dokumente	README, Runbook/SOP, Kontextdatei, Spezifikation
Arbeitsmaterial	das Material selbst	Code: die Umstrukturierung, auf die „The 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

Eine Vorbemerkung zur Ehrlichkeit: Die Gruppen sind nach ihren Fix-Zielen benannt; daher trifft die Aussage „Die Bezeichnung legt den Fix zur Hälfte fest“ naturgemäß zu – es handelt sich um eine Designentscheidung und nicht um eine empirische Erkenntnis. Die zugrunde liegende empirische Behauptung lautet, dass die zum Zeitpunkt der Erfassung vergebenen Bezeichnungen genau und konsistent sind – genau das haben wir jedoch noch nicht gemessen (mehr dazu weiter unten).

Die Tabelle weist einer Korrektur ihre erste Adresse zu, und durch Wiederholungen kann sie verschoben werden. Wenn nach einer Korrektur in der Dokumentation oder in einer Kontextdatei erneut Probleme auftreten, funktioniert der Text wahrscheinlich nicht. Verschieben Sie die Korrektur an eine Sicherheitsbarriere: einen Hook oder eine CI-Prüfung, die unabhängig davon, ob jemand sie liest oder nicht, die Korrektur aufrechterhält. Es gilt dieselbe Argumentation wie bei der Wahl eines Capture-Triggers: Eine Konventionsregel hängt davon ab, dass sich jemand daran erinnert, ein Hook hingegen nicht.

Beachten Sie, was damit abgedecktwork-material-friction wird, denn genau darin liegt der Grund für den fachbereichsübergreifenden Anspruch dieses Vokabulars. Im Code 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 zunächst viel Zeit damit, zu rekonstruieren, welche Kampagne wozu 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 Elemente nirgendwo unterbringen.

Warum festgelegt statt emergent? 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 der spontan entstehenden Kategorien an zwei Stellen am Laufen: durch eine mit Belegen untermauerte Anmerkung unter jeder Bezeichnung und 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 aufgrund 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 feste 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, 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 (Evaluierungs-FAQ, Januar 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 der Evaluierung“. 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 entscheidender 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, und führt nur etwa 9,9 % der Fehler auf die Modelllogik zurück: Die meisten Fehler sind Probleme des „Harness“ (der „Harness“ ist das Gerüst um das Modell herum), weshalb unsere Kennzeichnungagent-error 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 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 Arten von Signalen 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 aus Sitzungen in automatisch erstellte Tickets; „Braintrust Topics“ ist das produktisierte Ergebnis der emergenten Schule, das Ihre Traces täglich neu gruppiert.

Zwei objektive 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 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 bestehenden „Loops“: Loop Engineering, Compound Engineering, Agent-Retro, AGENTS.md-Retrospektiven, Vendor-Speichersysteme und 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 Ablä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 aufwendige Schritt nicht im Fokus steht: 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 „Höhe“ an.

Durch die Aggregation werden Prioritäten neu gewichtet. Was für eine Person ein zehnminütiges Ärgernis darstellt, ist bloßes 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 des Teams dar, und nur die aggregierte Sichtweise macht 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 sowie Eskalationen an übergeordnete Ebenen – also jene Ebenen, auf denen die größten wiederkehrenden Reibungspunkte in der Regel auftreten – sind Entscheidungen, die niemand 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 finden ihren Niederschlag in Artefakten, 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.

Beim Durchsehen verschiedener Personen und Repositories stoßen Sie zudem auf Erkenntnisse, die sich widersprechen. Ersetzen Sie, anstatt zu überschreiben: Die neue Erkenntnis wird als datierter Eintrag hinzugefügt, der auf den alten verweist, und der alte bleibt lesbar, damit später niemand unbemerkt die falsche Überzeugung erneut ableitet. Um zwischen ihnen zu entscheiden, prüfen Sie zunächst die Herkunft (Beweise aus erster Hand sind einer nur wiederholt wordenen Erkenntnis vorzuziehen), dann die Aktualität, indem Sie die tatsächlichen Zeitstempel lesen. Wenn beides keine Klarheit schafft, kennzeichnen Sie das Paar als ungelöst, anstatt einen Gewinner zu erzwingen. Prüfen Sie auch den Geltungsbereich. In einem unserer Repos gab es eine Lektion, die besagte, man dürfe niemals einen Symlink zum Arbeitsverzeichnis erstellennode_modules; eine andere besagte, man müsse einen Symlink erstellen, da sonst der Build fehlschlägt. Jede davon war in ihrem jeweiligen Repo zutreffend. Eine später gemeinsam genutzte Lösung – eine Kopie mit Hardlink – funktionierte in beiden Fällen, sodass die Lektion zum Symlink ersetzt wurde.

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

Was würde 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 sie 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 verwendet 4. Unsere Etikettenverteilung nach einem Viertel der tatsächlichen Einträge ist der Beleg dafür, dass diese Beibehaltung oder Neugestaltung erfolgt.
• Fehlende Modi. Reibungsverluste zwischen Agenten (Verlust bei der Übergabe zwischen Unteragenten, Koordinationsfehler) werden derzeit unter [ ] erfasstenvironment-friction; 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 würden: 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 durch theoretische Überlegungen.

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 Korrekturmaßnahmen eine Teamentscheidung ist und wie das Team vorgeht, wenn der Friktionsbericht eintrifft. Teil des Leitfadens zu Retrospektiven mit KI-Agenten.