So sieht eine gute Reibungsbilanz aus

Warum Aufzeichnungen und nicht Erinnerungen?

Reibungspunkte in einer einzelnen Sitzung sind bloßes Rauschen. Die gleichen Reibungspunkte über acht Sitzungen hinweg bilden ein Muster, das Ihr Team beheben kann – allerdings nur, wenn diese acht Sitzungen Aufzeichnungen hinterlassen haben, die Sie tatsächlich gemeinsam auswerten können: konsistent (gleiches Schema, sodass sie vergleichbar sind) und fundiert (auf Belegen basierende Beobachtungen, keine vagen Eindrücke).

Beides geschieht nicht automatisch. Der Moment, in dem Reibungspunkte auftreten, ist der Moment, in dem die Informationen darüber am umfassendsten sind – die genaue veraltete Zeile im Runbook, der genaue Parameter, den die Vorgabe offen gelassen hat. Diese Informationen verlieren schnell an Aktualität. Der Agent normalisiert seine eigene Umgehungslösung innerhalb weniger Durchläufe, und am Ende der Sitzung ist das Signal verschwunden, sofern es nicht schriftlich festgehalten wurde; was auch immer ein Unteragent herausfindet, „verschwindet in dem Moment, in dem es zurückkehrt“ (Hindsight, Mai 2026). In diesem Kapitel geht es um das Festhalten in schriftlicher Form.

Wie Reibung wahrgenommen wird

Bevor etwas aufgezeichnet werden kann, muss es erst einmal wahrgenommen werden. Vier Kanäle, und jeder nimmt etwas anderes wahr:

Der Agent bemerkt, dass er Schwierigkeiten hat. Wiederholungsschleifen, Backtracking, das erneute Einlesen derselben Datei oder die erneute Abfrage derselben Analyseansicht – eine Vermutung, die durch eine Lücke im Auftrag erzwungen wird. Produktionsplattformen haben sich im Wesentlichen auf diese Liste von Verhaltenssignalen geeinigt (Factory Signals, Jan. 2026). Der kostengünstigste Kanal, mit zwei offensichtlichen Einschränkungen: Er nimmt fehlende Dinge nicht wahr (eine Wiederholungsschleife wird wahrgenommen; ein Dokument, das nie existiert hat, erzeugt kein Signal), und die Selbstbeobachtung übertrifft die Selbstdiagnose – Modelle lokalisieren ihre eigenen agentischen Fehler selbst bei kuratierten Trace-Daten nur unzureichend (~11 %, TRAIL). Die Aufgabe während der Sitzung besteht daher darin, Symptome zu beobachten und Belege anzuführen, wobei die Diagnose offen gehalten wird.

Ein zweiter Sachbearbeiter überprüft das Protokoll. Ein neuer Prüfer entdeckt, was der zuständige Sachbearbeiter als normal angesehen hat. Dies ist objektiver; erfordert jedoch einen zweiten Durchgang und birgt eigene Beurteilungsfehler.

Ein Mensch korrigiert den Agenten. Nach wie vor der dominierende Sensor: Eine achtwöchige Produktionsstudie ergab, dass etwa 70 % der stillen Agent-Ausfälle zunächst von einer Person entdeckt wurden, der etwas auffiel – und nicht durch Unit-Tests, Zustandsprüfungen oder Governance-Audits (arXiv 2606.14589). Jede Korrektur (das „Nein, ich meinte …“ eines Prüfers, die erneute Erläuterung des Auftrags durch einen Beteiligten während des Audits) markiert genau die Stelle, an der der Kontext von der Absicht abwich, und der Agent kann dies im selben Moment ohne zusätzlichen Prozessaufwand erfassen.

Telemetrie. Fehlerraten bei Tools, abgelehnte Berechtigungen, Schleifenanzahlen, lange Laufzeiten. Automatisch und objektiv, jedoch oberflächlich: Das System weiß dass etwas passiert ist, nicht warum.

Die leistungsstärksten Konfigurationen arbeiten nach dem Dreiecksprinzip: Die Telemetriedaten geben an, wo Sie suchen müssen, ein Überprüfungsdurchlauf erklärt, warum, und manuelle Korrekturen decken jene Problemkategorien ab, die durch automatische Signale nicht erfasst werden können. Ganz gleich, welche Kombination Sie verwenden – das Ergebnis sollte immer dasselbe sein: eine Aufzeichnung.

Was veranlasst den Agenten dazu, dies zu protokollieren?

Ein Agent erfasst keine Reibung, nach der er nicht gesucht hat. Die meisten Reibungen bleiben nicht deshalb unberücksichtigt, weil sie nicht bemerkt wurden, sondern weil nichts die Erfassung ausgelöst hat. Vier Mechanismen, die sich hauptsächlich darin unterscheiden, was die Auslösung gewährleistet:

• Eine Funktion: Eine versionierte, schriftlich festgehaltene Prozedur, die der Agent am Ende einer Sitzung ausführt. Sie enthält das Schema und die Ehrlichkeitsregeln, sodass die Ausführung konsistent ist: Dieselbe Prozedur funktioniert sowohl bei einer Refaktorisierung als auch bei der Überprüfung eines Werbekontos. Schwäche: Der Aufruf erfolgt stochastisch; es kann vorkommen, dass die Funktion unbemerkt nie ausgelöst wird.
• Ein Hook: Das Harness selbst löst einen Vorgang aus oder erinnert daran (eine Injektion zu Beginn einer Sitzung, ein Trigger am Ende einer Sitzung). Deterministisch (die einzige Option, bei der es nicht darauf ankommt, dass sich jemand an etwas erinnert), jedoch zu pauschal (er wird auch bei einer zweiminütigen Sitzung ausgelöst) und plattformgebunden.
• Eine Konventionsregel: eine feste Anweisung in der Kontextdatei des Anwendungsbereichs oder deren nicht-codegebundene Entsprechung, ein Schritt in der Standardarbeitsanweisung des Teams: „Beenden Sie jede umfangreiche KI-gestützte Sitzung, indem Sie Reibungspunkte protokollieren.“ Keine Infrastruktur erforderlich, doch das Verfahren stützt sich vollständig darauf, dass das Modell eine von vielen Regeln einhält, und verliert an Wirksamkeit, je größer die Datei wird; der benannte Fehlermodus ist die Speicherdatei, die „nicht mehr gelesen wird“ (Feldnotiz zu Anti-Mustern).
• Ein Befehl: Ein vom Menschen eingegebener/retro Befehl am Ende eines Feature-Branches oder einer Triage-Schicht. Bedacht und zeitlich präzise abgestimmt; das menschliche Gedächtnis stellt dabei die Schwachstelle dar.

Diese Elemente setzen sich zusammen; ordnen Sie sie schichtweise an. Ein deterministischer Auslöser (Hook oder ein SOP-Schritt zum Schichtende), eine prozedurale Nutzlast (die Fertigkeit) und eine Konventionszeile, die die Vorgehensweise als Norm festlegt – wählen Sie mindestens einen Auslöser, zwei sind besser. Selbst Anbieter sind zu dieser Erkenntnis gelangt: In den Codex-Leitlinien von OpenAI heißt es: „Wenn Codex denselben Fehler zweimal macht, bitten Sie es um eine Retrospektive und aktualisieren Sie die Datei AGENTS.md“ (Best Practices).

Die Struktur eines guten Einleitungsabsatzes

Ein Datensatz stellt den Vertrag zwischen der Sitzung, die die Störung festgestellt hat, und allen nachgelagerten Komponenten dar – die Qualität der Synthese wird durch die Qualität des Datensatzes begrenzt. Vier tragende Komponenten:

1. Ein mit Belegen untermauerter Vorfall samt dessen Kosten. Was geschah, wann und welche beobachtbaren Folgen hatte dies – und zwar so konkret, dass jemand, der nicht an der Sitzung teilgenommen hat, darauf reagieren könnte. Kosten bedeuten nachbearbeitete Arbeit, verschwendete Zeit, fehlerhafte Ergebnisse; eine Aufzeichnung ohne Kostenangabe kann später nicht bewertet werden. Von einem Beteiligten geschätzte Kosten sind ungenau: Vermerken Sie diese(est.)lieber, anstatt Präzision vorzutäuschen.

2. Genau eine Bezeichnung für die Grundursache aus einem festen Vokabular mit zehn Bezeichnungen. Feste Vokabulare lassen sich zuverlässig kennzeichnen (MAST erreichte κ = 0,88 bei 14 Fehlermodi; siehe arXiv 2503.13657); frei definierte Kategorien variieren je nach Person und lassen sich nicht mehr aggregieren. Die zehn:

• ambiguous-instruction: In der Fragestellung blieben wichtige Parameter offen (Zielgruppe, Umfang, Definition, Zeitrahmen), sodass eine Vermutung erforderlich war
• missing-context: eine allgemein bekannte Tatsache, die dem Team zwar bekannt ist, die es jedoch nicht weitergegeben hat
• incorrect-context: Die bereitgestellten Informationen waren falsch
• missing-documentation: Eine Dokumentation, die eigentlich vorhanden sein sollte, fehlt (keine README-Datei, Spezifikation, Betriebsanleitung oder Standardarbeitsanweisung)
• incorrect-documentation: Es liegt ein Dokument vor, das jedoch veraltet oder fehlerhaft ist und auf das man sich verlassen hat
• work-material-friction: Das zu bearbeitende Material führte dazu, dass die Arbeit langsam oder fehleranfällig war: technische Schulden oder eine unübersichtliche Struktur im Code; ein unübersichtliches Konto, eine unübersichtliche Tabelle, eine unübersichtliche Kalkulationstabelle oder eine unübersichtliche Vorlage außerhalb des Systems (nennen Sie stets das konkrete Material)
• missing-access-or-tool: Ein erforderliches Anschlussteil, eine erforderliche Berechtigung oder ein erforderliches Werkzeug war nicht verfügbar
• agent-error: ein Fehler des Agenten selbst (falsche Annahme, veraltetes Wissen, ein von ihm verursachter Fehler)
• changed-requirements: Die Vorgaben wurden während der Sitzung geändert, und die Arbeit musste neu erledigt werden
• environment-friction: Fehler bei den Tools, Zeitüberschreitungen, Probleme mit der Sandbox oder der Plattform

ambiguous-instructionEine Bezeichnung pro Befund gewährleistet eine korrekte Einordnung: Wählen Sie die am besten passende Bezeichnung aus, beachten Sie die Unstimmigkeiten in den Belegen und erfinden Sie niemals mitten im Eintrag eine Bezeichnung. Drei Grenzregeln leisten den größten Teil der Arbeit bei der Eindeutigkeitsstiftung. Der Agent-Erkennbarkeitstest: War die Tatsache an einer Stelle auffindbar, an der der Akteur vernünftigerweise hätte suchen können? Nirgendwo gefunden, wo sie hätte sein sollen → missing-documentation; erst später von einer Person bereitgestellt → missing-context. Der Fehler des Akteurs ist der Restfall: Verwenden Sie diese Bezeichnung nur, wenn die Eingaben angemessen waren und der Akteur dennoch einen Fehler begangen hat; lässt sich der Fehler auf eine fehlerhafte Eingabe zurückführen, kennzeichnen Sie die Eingabe. Und Mehrdeutigkeit versus Zielverschiebung: Wenn die Klärung ergab, was schon immer gemeint war, war es ; wenn sich das Ziel tatsächlich verschoben hat, ist es changed-requirements.

3. Eine „Ticket“-große Lösung, die die betreffende Ebene benennt. Die Ebene ist der Bereich, auf den sich die Lösung bezieht: Gedächtnis, Kompetenz, Umfeld, Dokumentation, das Material selbst, der Prozess oder vorgelagerte Bereiche. Ein „Friction Record“ ohne beigefügte Lösung ist eine Beschwerde.

Hier finden Sie einen vollständigen Eintrag aus einer Sitzung, die nicht die Programmierung betrifft, nämlich einer monatlichen Überprüfung des Werbekontos:

- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

Ein Moment, Kosten mit einem(est.) Marker, eine Bezeichnung, eine Lösung, die jemand nächste Woche umsetzen könnte. Vergleichen Sie dies mit der unbrauchbaren Formulierung derselben Beobachtung: „Die Aufgabenstellung war verwirrend“ – kein Moment, keine Kosten, kein nächster Schritt. Unklarheit ist an sich schon eine Fehlerquelle.

4. Das Recht, nichts zu sagen. „Nichts Bemerkenswertes“ ist eine zulässige und sinnvolle Antwort; ein Protokoll, das mit erfundenen Ergebnissen aufgefüllt ist, überdeckt die tatsächlichen Befunde.

Noch ein weiterer Aspekt bei der Konzeption: Die Aufzeichnung sollte ungated erfolgen – ein Agent, der für die Aufzeichnung eine Genehmigung benötigt, führt zu einer Untererfassung von Reibungspunkten. Lassen Sie ihn ungehindert aufzeichnen, und lassen Sie menschliches Feedback erst im Nachhinein als Korrektur einfließen: als ergänzendes Signal von der Person, die ebenfalls an der Sitzung teilgenommen hat, und nicht als Kontrollpunkt, auf den die Schleife wartet.

Die „Never-Log“-Regeln

Datensätze überdauern ihre Sitzungen: Sie werden gespeichert, weitergegeben und zusammengefasst. Manche Dinge werden nie erfasst:

• Geheimnisse, Zugangsdaten, Tokens oder API-Schlüssel in jeglicher Form, auch in Teilform.
• Kundendaten oder personenbezogene Daten.
• Noch nicht veröffentlichte Geschäftszahlen oder vertrauliche Zahlen – beschreiben Sie die Auswirkungen, nicht die Daten.
• Vor allem: Menschen. Niemals ein Name, eine Funktion oder irgendetwas, das darauf hindeutet, wer eine Lücke verursacht hat. Beschreiben Sie die Lücke und welche Folgen sie hatte: „Der Auftrag ließ die Zielgruppe offen“, nicht „Xs Auftrag“. Die Einträge kritisieren Inputs und Systeme, nicht Personen – dieselbe Vorgehensweise, nach der eine gute Retrospektive abläuft, und die dafür sorgt, dass das Protokoll sicher gemeinsam gelesen werden kann.

Kritik an den Eingaben wird erwartet: Unklare Vorgaben, fehlender Kontext und verspätete Anforderungen sind in der Regel die Bereiche, in denen sich die umsetzbaren Erkenntnisse finden. Der Bearbeiter sollte sich selbst mit derselben Ehrlichkeit hinterfragen. Wenn sich die Schwierigkeiten eines Aufgabenbereichs nicht ohne vertrauliche Hintergrundinformationen beschreiben lassen, sollten die Einträge zu diesem Aufgabenbereich vertraulich behandelt und lediglich die zusammengefasste Vorgabe weitergegeben werden.

Wo sich das Protokoll befindet

Ein Protokoll pro Prüfungsbereich – die Grenze, innerhalb derer Korrekturen vorgenommen werden. Bei den meisten Entwicklungsaufgaben ist dies das Repository: Seine Dokumentation, Konfiguration und Konventionen sind im Repository angesiedelt, daher gilt dies auch für das entsprechende Protokoll. Außerhalb des Codes umfasst der Geltungsbereich das Anzeigenkonto, den Support-Posteingang und die Kundenbetreuung; bewahren Sie das Protokoll im Dokumentenverzeichnis dieses Arbeitsbereichs auf. Ein außerhalb seines Geltungsbereichs abgelegter Eintrag wird vom späteren Verantwortlichen für die Behebung niemals gefunden; ein Eintrag, der in ein temporäres Verzeichnis geschrieben wird, geht mit dem Ende der Sitzung verloren.

Was überall identisch bleiben muss, ist nicht der Speicherort, sondern die Struktur: Das Schema, nicht der Speicherort, sorgt dafür, dass Einträge später aggregiert werden können. Das ist der zentrale Aspekt dieses Kapitels in Bezug auf die Teamarbeit: Vergleichbare Datensätze – über Personen, Agenten, Sitzungen und Tools hinweg – sind die Voraussetzung dafür, dass eine Aggregation auf Teamebene überhaupt möglich ist. Passen Sie den Speicherort frei an; bewahren Sie das Schema.

Wie geht es weiter?

Eine Ansammlung guter Aufzeichnungen ist Rohmaterial, keine Erkenntnis. Die folgenden Kapitel knüpfen daran an: die Wahl der Höhe jedes Positionspunkts (der Unterschied zwischen einer Notiz zur Erinnerung und der Neugestaltung, auf die die Reibung immer wieder hinweist); die Zusammenfassung der Einträge zu einer einseitigen Zusammenfassung, die das Team gemeinsam lesen kann; sowie die Zeremonie, bei der Menschen und das Protokoll aufeinandertreffen – die Retrospektive, bei der die Aufzeichnungen des Agenten als Input für die Teilnehmer dienen. Dieser Kreislauf ist ein Beispiel für das „Feedback-Flywheel“: Das Gelernte fließt zurück in die Artefakte, die den Kontext liefern (martinfowler.com). Und die Disziplin bei der Eintragung ist die Fehleranalyse, „die wichtigste Aktivität bei Evaluierungen“ (Husain & Shankar, Evaluierungs-FAQ), die auf den kostengünstigsten Zeitpunkt verlegt wird: solange die Sitzung, in der die Reibung aufgetreten ist, noch läuft.

All das oben Genannte funktioniert mit einer Textdatei und jedem kompatiblen Agenten. Falls Sie die Vorlage lieber nicht selbst erstellen möchten, implementiert die kostenlose ai-session-retroSkill diese Eingabeform von Anfang bis Ende; der Schnellstart-Beitrag führt Sie in etwa zehn Minuten durch die Installation.

Nächstes Kapitel: Wo sollte die Korrektur ansetzen? – das Höhenproblem und die Routingtabelle.