Was ein Agent getan hat, muss rekonstruierbar bleiben

Ein Agent ist nicht deshalb kontrollierbar, weil er am Ende einen überzeugenden Bericht schreibt. Kontrollierbar wird er, wenn sein tatsächlicher Weg durch Quellen, Entscheidungen, Werkzeuge und Zustandsänderungen überprüfbar bleibt.

Am Ende einer langen agentischen Sitzung steht oft eine beruhigende Zusammenfassung: Recherche abgeschlossen, Dateien aktualisiert, Tests bestanden, nächste Schritte vorbereitet. Solche Statusberichte sind hilfreich. Sie sind aber Selbstauskünfte des Systems. Wenn eine Datei fehlt, eine Quelle falsch interpretiert oder ein Tool mit unerwarteter Nebenwirkung ausgeführt wurde, kann derselbe Agent dennoch eine glatte Erfolgsgeschichte formulieren.

Verantwortbare Agentenarbeit braucht deshalb mehr als Erinnerung und Abschlussprosa. Sie braucht eine rekonstruierbare Spur: Was war der Ausgangszustand? Welcher Auftrag galt? Welche Quellen wurden tatsächlich gelesen? Welches Tool erhielt welche Parameter? Was änderte sich? Welche Prüfung lief? Wer bestätigte den nächsten Schritt? Nur wenn diese Fragen später beantwortet werden können, wird aus einem Chatverlauf ein steuerbarer Prozess.

Status ist eine Momentaufnahme, kein Beweis

Eine Projekttabelle mit offenen, erledigten und blockierten Aufgaben kann lange Sitzungen stabilisieren. Sie verdichtet den gültigen Zustand und erleichtert Übergaben. Doch sie zeigt meist nur, was das System über den Zustand behauptet. Sie erklärt nicht automatisch, wie dieser Zustand entstanden ist.

Ein Task kann als erledigt markiert sein, obwohl nur ein Entwurf existiert. Eine Quelle kann als geprüft gelten, obwohl lediglich eine Zusammenfassung gelesen wurde. Ein Test kann „bestanden" heißen, obwohl er mit alten Daten lief. Der Status bleibt wertvoll, muss aber mit Ereignissen und Artefakten verbunden werden.

Die stärkere Formulierung lautet daher nicht „Aufgabe 17 ist fertig", sondern: „Artefakt Version 4 wurde aus den Quellen A und B erzeugt, Testset C lief gegen Commit D, zwei Prüfkriterien bestanden, eines wurde mit dokumentierter Ausnahme akzeptiert, Freigabe erteilte Rolle E." Damit wird der Status verifizierbar.

Observability, Audit Trail und Provenienz lösen verschiedene Fragen

Observability macht sichtbar, was während der Laufzeit geschieht. Traces zeigen zusammenhängende Vorgänge, Logs einzelne Ereignisse, Metriken aggregierte Größen wie Latenz, Fehlerquote oder Verbrauch. Audit Trails konzentrieren sich auf kontrollrelevante Handlungen: Freigaben, Zugriffe, Änderungen, Veröffentlichungen und Ausnahmen. Provenienz erklärt Entstehung und Ableitung: Aus welchen Eingaben, Aktivitäten und verantwortlichen Instanzen ging ein Ergebnis hervor?

Diese Ebenen ergänzen sich. Ein Trace kann zeigen, dass ein Agent eine Suchabfrage, drei Toolaufrufe und eine Dateischreibung ausführte. Der Audit Trail hält fest, dass die Schreibung autorisiert war. Die Provenienz verbindet die neue Datei mit den gelesenen Quellen und der Transformation.

Nicht jedes Debug-Detail gehört dauerhaft in den Audit Trail. Nicht jedes Audit-Ereignis braucht vollständigen Promptinhalt. Eine saubere Architektur trennt die Signale, definiert gemeinsame Identifikatoren und erlaubt dennoch Korrelation.

Ein agentischer Trace braucht mehr als einen Modellnamen

Ein nützlicher Trace beginnt mit einer stabilen Run-ID und zerlegt die Arbeit in Spans. Ein Span kann Planung, Retrieval, Toolausführung, Evaluation oder menschliche Freigabe repräsentieren. Parent-Child-Beziehungen zeigen, welcher Schritt welchen Unterprozess ausgelöst hat.

Zu einem Ereignis gehören mindestens Zeitpunkt, Akteur, Aufgabe, Operation, Inputreferenzen, Outputreferenzen, Status, Dauer und Fehler. Bei Toolaufrufen kommen Toolversion, validierte Parameter, Berechtigungsentscheidung und Nebenwirkung hinzu. Bei Retrieval sind Query, Datenquellen-ID, ausgewählte Dokumente und relevante Versionen wichtig. Bei Evaluation werden Metrik, Testversion, Ergebnis und Begründung festgehalten.

OpenTelemetry entwickelt für generative KI gemeinsame semantische Attribute. Solche Konventionen lösen nicht jedes Governance-Problem, schaffen aber eine gemeinsame Sprache über Bibliotheken und Plattformen hinweg. Eigene Felder sollten dieselbe Disziplin besitzen: klare Bedeutung, stabiler Datentyp, dokumentierter Geltungsbereich und Versionierung.

Behauptung, Ereignis und Artefakt müssen getrennt werden

Agenten formulieren häufig Sätze wie „Ich habe die Datei validiert". Dieser Satz ist eine Behauptung. Das Validierungsereignis ist die tatsächlich ausgeführte Operation. Das Prüfprotokoll ist das resultierende Artefakt. Erst die Verbindung aller drei Elemente erzeugt belastbare Nachvollziehbarkeit.

Die Trennung verhindert, dass Sprache technische Realität ersetzt. Ein Modell kann „gespeichert" schreiben, obwohl der Schreibvorgang fehlschlug. Das System darf den Status erst aktualisieren, wenn der Host den neuen Zustand beobachtet und ein Artefakt oder Event bestätigt.

Für wichtige Aussagen gilt dasselbe. Eine Empfehlung verweist auf Evidenzkarten. Jede Evidenzkarte enthält Quelle, Ausschnitt oder Datensatzreferenz, Zeitpunkt, Geltungsbereich und Prüfergebnis. Der Artikel oder Bericht referenziert die Karten, nicht bloß eine unsichtbare Erinnerung des Modells.

Zustandsänderungen brauchen Vorher und Nachher

Ein lesender Agent hinterlässt andere Risiken als ein schreibender. Sobald Dateien, Datenbankeinträge, Berechtigungen oder externe Systeme verändert werden, muss der Audit Trail die Mutation erfassen. Dazu gehören Zielobjekt, alter Zustand oder Version, beabsichtigte Änderung, tatsächliches Ergebnis und Rücknahmeweg.

Bei großen oder sensiblen Objekten muss nicht der gesamte Inhalt dupliziert werden. Version, Hash, Diff, Speicherort und geschützte Metadaten können genügen. Entscheidend ist, dass später festgestellt werden kann, welche Änderung mit welcher Autorität geschah.

Reversible Schritte werden anders behandelt als irreversible. Ein Entwurf kann in einem isolierten Ordner erzeugt werden. Eine Veröffentlichung, Löschung oder Transaktion benötigt einen Checkpoint. Das Freigabeereignis wird mit Scope und Ablaufzeit verknüpft; eine Bestätigung für Objekt A darf nicht stillschweigend Objekt B autorisieren.

Kosten und Zeit sind Teil des Verhaltens

Agentenqualität wird häufig nur am Endergebnis gemessen. Ein System kann jedoch dasselbe Ergebnis mit zehn oder zehntausend Aufrufen erzeugen. Unbegrenzte Schleifen, wiederholtes Retrieval und erfolglose Tool-Retries sind operative Fehler, selbst wenn am Ende ein brauchbarer Text entsteht.

Deshalb erfasst Observability auch Latenz, Modell- und Toolaufrufe, Input- und Outputmengen, Cache-Nutzung, Retry-Zahl und geschätzte Kosten. Diese Werte werden pro Schritt, Aufgabe und Gesamt-Run betrachtet. Budgets sind nicht nur Berichtsfelder, sondern Steuergrenzen. Überschreitet ein Run ein Zeit-, Kosten- oder Schrittlimit, pausiert oder eskaliert er.

Aggregierte Metriken zeigen Muster: Welche Rolle verursacht Wiederholungen? Wo entstehen lange Wartezeiten? Welches Tool liefert die meisten Fehler? Einzelne Traces erklären anschließend konkrete Ausreißer.