ActiveGraph: Wenn das Event-Log den Agentenzustand trägt

Ein Agent arbeitet stundenlang, wird neu gestartet und soll später erklären, wie sein Ergebnis entstanden ist. Wer dann nur einen aktuellen Zustand, lose Logs und einige Modellantworten besitzt, kann den Lauf kaum zuverlässig rekonstruieren. ActiveGraph setzt deshalb das Ereignisprotokoll ins Zentrum: Der Arbeitsgraph wird daraus berechnet und kann jederzeit neu aufgebaut werden.

Das im Mai 2026 veröffentlichte Paper „The Log is the Agent“ beschreibt ActiveGraph als ereignisbasierte Graph-Runtime für langlebige Agenten. Der Ansatz verspricht keine klügere Planung. Er soll Wiederaufnahme, Variantenbildung und Prüfung zu Eigenschaften der Architektur machen.

Der Graph ist nur die aktuelle Ansicht

Bei ActiveGraph ist das unveränderliche Event-Log die maßgebliche Quelle für den Zustand. Neue Ereignisse werden angehängt, bestehende Einträge nicht nachträglich überschrieben. Der Arbeitsgraph entsteht als deterministische Projektion dieser Folge.

So bleiben Ergebnis und Entstehungsweg sichtbar. Speichert ein System ausschließlich den aktuellen Graphen, können frühere Zustandsänderungen verschwinden. Ein Ereignisprotokoll hält dagegen fest, welche Übergänge zu welchem Zeitpunkt erfolgt sind. Bei einer Fehleranalyse muss das Team den Ablauf nicht aus dem Endzustand und verstreuten Textlogs erraten.

Die Autoren fassen die daraus entstehenden Fähigkeiten als „resumable, forkable, and diff-able“ zusammen. Dahinter stecken drei unterschiedliche Betriebsaufgaben: einen unterbrochenen Lauf fortsetzen, an einem bestimmten Ereignis eine Variante abzweigen und die späteren Abweichungen beider Verläufe vergleichen.

Replay reproduziert den Verlauf, nicht das Modell

Deterministisches Replay bedeutet hier, dass bereits gespeicherte Schritte nicht erneut vom Modell erzeugt werden müssen. Das Event-Log liefert die Zustandsübergänge, aus denen der historische Lauf rekonstruiert wird.

Bei Sprachmodellen ist diese Abgrenzung entscheidend. Ein erneuter Modellaufruf muss trotz gleicher Eingabe nicht dieselbe Antwort liefern. Reproduzierbar ist der aufgezeichnete Verlauf – nicht automatisch jede neue Ausführung unter scheinbar gleichen Bedingungen.

Für mich ist das der wichtigste Prüfpunkt des gesamten Ansatzes: Teams müssen sauber zwischen der Rekonstruktion eines historischen Laufs und einem neuen Durchlauf mit denselben Startdaten unterscheiden. Das vollständige Event-Log kann die Rekonstruktion tragen. Der neue Durchlauf bleibt von Modell, Anbieter und Laufzeitbedingungen abhängig. Wer beides als deterministisch bezeichnet, verspricht im Betrieb zu viel.

Forks sparen den gemeinsamen Vorlauf

Ein Fork kann laut den Autoren an einem beliebigen Ereignis abzweigen, ohne den gemeinsamen Anfang erneut auszuführen. Die Variante übernimmt den bisherigen Verlauf und beginnt erst am gewählten Punkt mit neuen Ereignissen.

Das wird bei langen Läufen praktisch. Ein Rechercheagent könnte zunächst Quellen sammeln und bewerten, bevor zwei unterschiedliche Berichte entstehen. Liegt der Verzweigungspunkt hinter der Quellenprüfung, müssen beide Varianten die gemeinsame Recherche nicht wiederholen. Der Vergleich beginnt an einem benannten Ereignis, während die gemeinsame Herkunft erhalten bleibt.

Die durchgängige Lineage markiert den letzten gemeinsamen Zustand zweier abweichender Ergebnisse. Damit bleibt sichtbar, bis zu welchem Ereignis beide Verläufe identisch waren und wo ihre Zustände auseinanderliefen. Bei Agentenaktionen mit realen Folgen ist das aussagekräftiger als ein Vergleich zweier Endausgaben mit ähnlichen Zeitstempeln.

Beobachtbarkeit ist kein Qualitätsbeweis

Die Autoren berichten ausdrücklich keinen Genauigkeitsvorteil gegenüber Baselines. ActiveGraph soll Aufgaben demnach nicht nachweislich besser lösen. Der Nutzen liegt in den Garantien für Replay, Forks und Herkunft. Diese Grenze ist wichtig: Bessere Nachvollziehbarkeit macht einen Agenten noch nicht intelligenter oder zuverlässiger.

Auch ein vollständig protokollierter Agent kann eine ungeeignete Quelle wählen, einen falschen Schluss ziehen oder das falsche Werkzeug aufrufen. Das Ereignisprotokoll verhindert solche Fehler nicht. Es verändert jedoch ihre Untersuchung: Ein Team kann den gespeicherten Verlauf prüfen und an einer ausgewählten Stelle eine Alternative starten, statt den gesamten Lauf unter veränderten Bedingungen nachzustellen.

Für einen Einstieg stehen aufgezeichnete Fixtures bereit, die laut Projektbeschreibung ohne API-Schlüssel oder zusätzliche Konfiguration auskommen und byte-identische Ausgaben erzeugen sollen. Damit lassen sich Replay und Zustandsprojektion zunächst ohne variable Modellantworten prüfen.

Für dauerhafte Installationen werden optionale Anbindungen an SQLite und Postgres sowie Prometheus und OpenTelemetry genannt. So bleibt die Ereignislogik von den Entscheidungen über Persistenz und Beobachtbarkeit getrennt.

Ein Prüfpfad für Betreiber

ActiveGraph stellt eine konkrete Architekturfrage: Kann eine Plattform einen Lauf wiederherstellen, an einem bekannten Ereignis verzweigen und die Herkunft jedes daraus entstandenen Zustands zeigen? Bei kurzen Demos lässt sich eine schwache Antwort leicht übersehen. Sobald Agenten über Stunden arbeiten, Neustarts überstehen oder folgenreiche Werkzeuge bedienen, wird sie zum Betriebsrisiko.

Ich würde den Ansatz deshalb mit einer kleinen Störprobe bewerten: einen Lauf nach mehreren Ereignissen abbrechen, die Runtime neu starten und den Zustand aus dem Log rekonstruieren. Anschließend sollte ein Fork am letzten bestätigten Ereignis entstehen. Der Vergleich muss zeigen, welche Zustände beide Verläufe teilen und wo sie auseinanderlaufen.

Noch wichtiger ist die Grenze des Tests. Replay darf gespeicherte externe Aktionen nicht versehentlich erneut auslösen. Ein rekonstruierter Werkzeugaufruf ist etwas anderes als eine wiederholte Zahlung, Nachricht oder Löschaktion. Ob ActiveGraph diese Nebenwirkungsgrenze für einen konkreten Einsatz ausreichend absichert, muss das betreibende Team mit dem verwendeten Werkzeugadapter selbst prüfen; aus der Architektur allein folgt diese Garantie nicht.

Fazit: Der aktuelle Zustand reicht nicht

Der Ansatz ersetzt weder Evaluationen noch Sicherheitskontrollen und belegt keine höhere Erfolgsquote. Sein engeres Versprechen ist trotzdem relevant: Zustandsänderungen sollen nicht im jeweils aktuellen Graphen verschwinden.

Meine Mindestregel für langlebige Agenten lautet deshalb: Ein produktives System braucht eine überprüfbare Ereignisgeschichte. Es muss außerdem eindeutig sagen können, ob es gerade einen gespeicherten Lauf rekonstruiert oder ein nichtdeterministisches Modell erneut entscheiden lässt. Bleibt diese Antwort offen, ist Wiederaufnahme kein Komfortproblem, sondern ein Betriebsrisiko.