13.03.2026 AI Engineering5 Minuten Lesezeit

Dual-State-Architekturen für Agenten

Chatverläufe protokollieren Äußerungen; als Datenbanken taugen sie nicht. Dieser Artikel beschreibt eine Dual-State-Architektur für KI-Agenten: Jede Prozessinstanz besitzt einen autoritativen, schemavalidierten Zustand, aus dessen konkreten Revisionen alle nutzerseitigen Sichten projiziert werden. Wir ordnen das Muster in Event Sourcing und CQRS ein und benennen seine Vorteile für Audit und Nebenläufigkeit ebenso klar wie seine 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.

In Demos wirkt dieses Design ausreichend; in Produktion bricht es auseinander. Korrekturen sammeln sich als zusätzliche Nachrichten, und zwei Leser — oder zwei Modellaufrufe — können aus demselben Verlauf unterschiedliche aktuelle Werte ableiten. Beim Bau von Agentensystemen für regulierte Branchen führt das regelmäßig zur selben architektonischen Antwort: ein autoritativer Prozesszustand, aus dem jede nutzerseitige Sicht berechnet wird. Im Folgenden beschreiben wir dieses Muster unabhängig von einem konkreten Framework.

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.

Trotzdem bleibt der Verlauf wertvoll. Er dokumentiert Intention, Ton und Mehrdeutigkeit — Informationen, die ein typisiertes Zustandsobjekt bewusst verwirft. Problematisch ist daher nicht seine Aufbewahrung, sondern seine Abfrage wie eine Datenbank. Das Protokoll des Gesagten liefert Eingaben für Zustandsänderungen; es ist 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 besteht aus zwei Hälften. Die erste ist ein einziges autoritatives Zustandsobjekt pro Prozessinstanz: typisiert, versioniert und außerhalb des Modells in einer Datenbank statt im Prompt gespeichert. Das Modell schlägt Änderungen vor; deterministischer Code prüft sie gegen Schema und Invarianten und wendet sie an. Jede akzeptierte Änderung erzeugt eine neue unveränderliche Revision. Der Chatverlauf bleibt erhalten, dient aber als Beleg der Intention und 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 machen auch das Debugging lokal. Verhält sich ein Agent falsch, lässt sich mechanisch beantworten, welche Revision den fehlerhaften Wert zuerst enthielt und wodurch sie ausgelöst wurde. Ohne Revisionen wird dieselbe Untersuchung zur Verlaufsarchäologie: Hunderte Turns müssen gelesen werden, um den fehlerhaften Modellaufruf zu erraten. Nach unserer Erfahrung ist der Diff zweier benachbarter Revisionen der präziseste Bug-Report, den ein Agentensystem liefern 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 Agentenprozesse werden, die Sitzungen oder Prüfer überspannen; innerhalb der nächsten zwei Jahre erwarten wir zudem dedizierte Agent-State-Stores als eigene Produktkategorie. Diese Richtung ist unglamourös, aber aus unserer Sicht richtig: Agenten übernehmen vier Jahrzehnte Datenbankdisziplin, während der Chatverlauf auf seine tatsächliche Rolle zurückfällt — ein Eingabestrom unter mehreren.