13.03.2026 AI Engineering 5 Minuten Lesezeit

Dual-State-Architekturen für Agenten

Chatverläufe sind Logs von Äußerungen, keine Datenbanken. Dieser Artikel beschreibt eine Dual-State-Architektur für KI-Agenten: ein autoritativer, schemavalidierter Prozesszustand pro Instanz, aus dem jede nutzerseitige Sicht als Projektion einer konkreten Revision berechnet wird. Wir behandeln die Wurzeln des Musters in Event Sourcing und CQRS, seine Audit- und Nebenläufigkeitsvorteile und seine ehrlichen Grenzen.

Das Problem mit konversationalem Zustand

Ein Agent, der einen Geschäftsprozess ausführt — eine Bestellannahme, eine Compliance-Prüfung, ein Deployment — akkumuliert Zustand: erfasste Werte, getroffene Entscheidungen, abgeschlossene Schritte. Viele frühe Agentensysteme der Jahre 2023 bis 2025 hielten diesen Zustand an genau einer Stelle: im Chatverlauf. Der aktuelle Prozesszustand war das, was das Modell im nächsten Turn aus der Nachrichtenliste rekonstruieren konnte.

Dieses Design funktioniert in Demos und scheitert in Produktion. Korrekturen häufen sich als zusätzliche Nachrichten. Zwei Leser — oder zwei Modellaufrufe — können aus demselben Verlauf unterschiedliche aktuelle Werte extrahieren. Wir bauen Agentensysteme für regulierte Branchen, und dieselbe architektonische Antwort taucht immer wieder auf: ein autoritativer Prozesszustand, aus dem jede nutzerseitige Sicht berechnet wird. Dieser Artikel beschreibt das Muster in allgemeiner Form.

Zwei Peers — jeder mit eigenem Zustand und privatem Graph. 1/4

Chatverlauf ist keine Datenbank

Ein Chatverlauf ist ein Append-only-Log von Äußerungen. Er hat kein Schema, keine Constraints, keine transaktionalen Updates und keinen definierten aktuellen Wert. Ändert ein Nutzer eine Liefermenge dreimal, enthält der Verlauf vier Mengen; welche gilt, ist Interpretationssache. Kontextfenster verschärfen das Problem: Kontext ist eine endliche Ressource mit begrenztem Attention-Budget, wie Anthropics Context-Engineering-Leitfaden vom September 2025 formuliert, und die Zusammenfassung älterer Turns ist konstruktionsbedingt verlustbehaftet.

Der Verlauf bleibt trotzdem wichtig. Er dokumentiert Intention, Ton und Mehrdeutigkeit — Informationen, die ein typisiertes Zustandsobjekt bewusst verwirft. Der Fehler ist nicht, den Verlauf zu behalten. Der Fehler ist, ihn wie eine Datenbank abzufragen. Ein Protokoll des Gesagten ist Eingabe für Zustandsänderungen, nicht der Zustand selbst.

Eigenschaft	Chatverlauf	Autoritativer Zustand mit Projektionen
Aktueller Wert	Implizit in der Nachrichtenreihenfolge	Explizites Feld der letzten Revision
Korrektur	Weitere angehängte Nachricht	Validiertes Update mit neuer Revision
Validierung	Keine	Schema und Invarianten im Code
Abfrage	Log nachlesen oder Modell fragen	Direkter typisierter Zugriff
Historie	Mit Dialog verschränkt	Geordnete diffbare Revisionen
Sicht reproduzieren	Nicht definiert	project(state, revision)

Ein autoritativer Prozesszustand

Das Muster hat zwei Hälften. Erstens: ein einziges autoritatives Zustandsobjekt pro Prozessinstanz — typisiert, versioniert, außerhalb des Modells gespeichert, in einer Datenbank statt im Prompt. Das Modell schlägt Änderungen vor; deterministischer Code validiert sie gegen Schema und Invarianten und wendet sie an. Jede akzeptierte Änderung erzeugt eine neue unveränderliche Revision. Der Chatverlauf bleibt erhalten, aber als Beleg der Intention, nicht als Akte.

Nichts davon ist neue Maschinerie. Event Sourcing beschreibt Zustand seit Martin Fowlers Text von 2005 als Ableitung aus einem geordneten Änderungslog. Pat Hellands "Immutability Changes Everything" (ACM Queue, Januar 2016) begründet den generellen Fall für Append-only-Wahrheit. Anthropics "Building Effective Agents" (Dezember 2024) plädierte für einfache, inspizierbare Schleifen — ein explizites Zustandsobjekt ist die inspizierbarste Schleifenvariable überhaupt. Und die Speicherhälfte ist in Frameworks angekommen: LangGraph 1.0 (Oktober 2025) liefert Durable Execution und Checkpointing als Kernfunktionen.

Sichten als Projektionen pro Revision

Die zweite Hälfte: Nutzersichten sind Projektionen. Eine Chat-Antwort, ein Formular, eine Dashboard-Kachel und ein generiertes PDF sind reine Funktionen von einer Zustandsrevision zu einer Darstellung: view = project(state, revision). Das ist CQRS auf Agenten angewandt — Greg Young trennte 2010 das Schreibmodell von beliebigen Lesemodellen. Eine Projektion enthält keine Logik, die Zustand ändert; sie stellt ihn nur dar.

Projektionen pro Revision erkaufen Reproduzierbarkeit und Nebenläufigkeitskontrolle. Jeder Bildschirm, den ein Nutzer gesehen hat, lässt sich exakt regenerieren, weil er die Revision benennt, aus der er berechnet wurde. Bearbeitet der Nutzer ein projiziertes Formular, trägt die Änderung diese Revisionsnummer; ist der autoritative Zustand inzwischen weitergezogen, erkennt das System den Konflikt, statt still zu überschreiben — klassische optimistische Nebenläufigkeit.

Revisionen ermöglichen Audit und Replay

Geordnete Revisionen sind zugleich die Audit- und Kontrollfläche. Jede Revision protokolliert ihre Ursache: einen Modellvorschlag, eine Nutzeränderung, ein externes Ereignis. Zwei Revisionen lassen sich diffen. Rollback ist eine neue Revision, die frühere Werte wiederherstellt — Historie wird nie umgeschrieben. Und Human-in-the-Loop-Freigaben erhalten ein präzises Objekt: Eine Person genehmigt Revision 23, nicht "den bisherigen Gesprächsverlauf". In regulierten Prozessen ist diese Präzision nicht optional.

Revisionen lokalisieren außerdem das Debugging. Verhält sich ein Agent falsch, hat die Frage "welche Revision enthielt den fehlerhaften Wert zuerst und was hat ihn verursacht" eine mechanische Antwort. Ohne Revisionen wird dieselbe Frage zur Verlaufsarchäologie: Hunderte Turns nachlesen und raten, welcher Modellaufruf danebenlag. Nach unserer Erfahrung ist das Diff zweier benachbarter Revisionen der schnellste Bug-Report, den ein Agentensystem produzieren kann.

Was das Muster nicht löst

Das Muster hat klare Nicht-Ziele. Es macht Modellausgaben nicht korrekt: Eine schemakonforme falsche Menge bleibt falsch. Es ersetzt kein Context Engineering: Der relevante Zustandsausschnitt muss weiterhin in jedem Turn in den Prompt serialisiert werden, und diesen Ausschnitt zu wählen ist echte Arbeit. Das Muster verschiebt die Autorität, nicht das Token-Budget.

Es hat außerdem Kosten. Schemata langlebiger Prozesse brauchen Migrationen. Ein Projektionsfehler zeigt Nutzern falsche Daten, selbst wenn der Zustand korrekt ist. Zwei Repräsentationen — Verlauf und Zustandsspeicher — verlangen Synchronisationsdisziplin. Für Einmalaufgaben ohne Korrekturen, Freigaben oder Audits ist eine einfache Chat-Schleife schlicht ausreichend. Das Muster verdient seine Komplexität erst, wenn ein Prozess eine einzelne Sitzung überlebt.

Ausblick im März 2026

Stand März 2026 ist die Speicherhälfte kommoditisiert: Persistenter Agentenzustand und Checkpointing sind Standard-Framework-Funktionen. Die Projektionshälfte ist es nicht — Sichten pro Revision werden weiterhin überwiegend von Hand gebaut, und wenige Teams behandeln das Zustandsschema als gleichrangiges Artefakt neben dem Prompt.

Wir erwarten, dass sich das ändert. Typisierter Prozesszustand mit revisionierten Projektionen dürfte zur Standardarchitektur für jeden Agentenprozess werden, der Sitzungen oder Prüfer überspannt, und wir erwarten dedizierte Agent-State-Stores als Produktkategorie innerhalb der nächsten zwei Jahre. Die Richtung ist unglamourös und aus unserer Sicht richtig: Agenten konvergieren auf vier Jahrzehnte Datenbankdisziplin, und der Chatverlauf wird zu dem degradiert, was er immer war — ein Eingabestrom unter mehreren.