Wo ein KI-Agent seinen Zustand halten sollte

Im ERP stand derselbe Lieferant zweimal. Ein Agent übernahm das Lieferanten-Onboarding: Er las die Unterlagen des Lieferanten, prüfte die Steuernummer, legte den Kreditor an, forderte die Bankdaten an und hinterlegte die Zahlungsbedingungen. Im Test lief er fehlerfrei. In der ersten Woche im Echtbetrieb startete ein planmäßiges Deployment den Dienst neu, während der Agent mitten in einem Vorgang steckte. Nach dem Neustart legte er den Lieferanten ein zweites Mal an.

Das Modell hatte beide Male richtig gefolgert. Das Problem war, wo der Agent festhielt, was er bereits erledigt hatte: in einem Tool-Aufruf und dessen Antwort, also im Gesprächsverlauf, den der Neustart gelöscht hatte. Das Bild, das der Agent von der Lage hatte, und die tatsächliche Lage stimmten nicht mehr überein, und nichts im Design hat es bemerkt.

Die meisten Agentenfehler, die wir im Produktivbetrieb untersuchen, folgen diesem Muster. Es sind Zustandsfehler, die wie Denkfehler des Modells aussehen, weil sich das Symptom in der Ausgabe des Agenten zeigt.

Drei Arten von Zustand, drei Zuständigkeiten

Ein Agent im operativen Geschäft hat mit drei Arten von Zustand zu tun. Viele Frameworks verwischen die Grenzen zwischen ihnen, und genau dort fangen die Probleme an.

Das führende System ist das ERP, das CRM, das Ticketsystem, die Bank. Es enthält die maßgeblichen Geschäftsdaten, setzt seine eigenen Validierungen und Berechtigungen durch und liegt in der Verantwortung der IT des Kunden. Der Agent ändert es nur über Schnittstellen, die es bereits gibt.

Die Vorgangsakte dokumentiert die Arbeit dauerhaft: welcher Vorgang, welche Schritte erledigt sind, was bei jedem Schritt entschieden wurde, die Belege und wer was freigegeben hat. Geschrieben wird sie vom Workflow, nicht vom Modell. Sie liegt neben dem führenden System in einem Speicher, der dem Kunden gehört. Nie in eigenen Tabellen oder freien Feldern des ERP, denn dort würde sie den Agenten an den Upgrade-Zyklus des ERP binden und Arbeitsnotizen mit maßgeblichen Geschäftsdaten vermischen.

Der Arbeitskontext ist das, was das Modell im aktuellen Schritt sieht: Anweisungen, die relevanten Belege, Fakten aus den beiden anderen Quellen. Er wird für einen Schritt aufgebaut und danach verworfen.

Daraus ergibt sich die Regel: Der Kontext ist eine Sicht, nie ein Speicher. Alles, was über einen Schritt hinaus Bestand haben muss, wird in die Vorgangsakte oder ins führende System geschrieben, bevor der Schritt als erledigt gilt. Bricht der Prozess an beliebiger Stelle ab, baut ein neuer den Kontext aus diesen beiden Quellen wieder auf und arbeitet weiter. Das testen wir ganz praktisch: Im Abnahmelauf beenden wir den Worker an zufälligen Stellen und prüfen, ob trotzdem jeder Vorgang genau einmal abgeschlossen wird.

Es gibt einen zweiten Grund, den Kontext neu aufzubauen, statt ihn anwachsen zu lassen. Die Engineers von Anthropic beschreiben, was sie Context Rot nennen („Effective context engineering for AI agents“, September 2025): Je größer ein Kontext wird, desto schlechter kann das Modell nutzen, was darin steht. Kontext ist also ein Budget mit abnehmendem Ertrag. Ein Kontext, der für einen Schritt neu aufgebaut wird, enthält nur, was dieser Schritt braucht. Das Design, das einen Agenten neu startbar macht, hält ihn auch am zweiten Tag eines Vorgangs präzise, wenn ein angesammelter Verlauf voller überholter Werte wäre.

So lässt sich auch jedes Agentendesign schnell prüfen, auch das eines Anbieters. Fragen Sie, wo jede der drei Arten von Zustand liegt. Lautet die Antwort bei zwei davon „im Gesprächsverlauf“, gibt es im Design in Wahrheit nur eine.

Erst die Absicht festhalten, dann handeln

Ob sich ein Vorgang nach einem Abbruch sauber fortsetzen lässt, hängt von der Reihenfolge der Schreibvorgänge ab. Bei jedem Schritt, der außerhalb etwas verändert, hält der Workflow die Absicht fest (Lieferant anlegen, für diesen Vorgang), bevor er die Änderung ausführt, und danach die Kennung, die das System zurückgegeben hat. Ein Neustart findet dann eine offene Absicht vor statt eines leeren Blatts, und nichts wird wiederholt, bevor diese Absicht geklärt ist.

Bei der Analyse des Onboardings hat allein diese Reihenfolge die Dubletten beseitigt, ohne dass am Prompt des Agenten etwas geändert werden musste. Keine Änderung am Prompt hätte das erreicht, denn der Prompt war nie die Ursache. Der Preis sind ein paar zusätzliche Schreibvorgänge und etwas mehr Latenz je Schritt. In Geschäftsprozessen ist das immer billiger als ein einziger doppelter Lieferant, ein doppelter Auftrag oder eine doppelte Zahlung.

Ein Plan veraltet, sobald er steht

Die meisten Agenten-Frameworks behandeln den Plan als das Wertvolle: einmal nachdenken, dann ausführen. Im operativen Geschäft ist es umgekehrt. Bei einem Vorgang, der zwei Tage dauert, ändert ein Einkäufer die Bestellung, das Kreditmanagement sperrt den Kunden und jemand korrigiert die Lieferadresse, während der Agent noch an einem Plan mit den alten Werten festhält.

Deshalb ist der Plan austauschbar, und das Wertvolle sind die Vorbedingungen. Jeder schreibende Schritt führt genau die Werte mit, auf denen seine Planung beruhte: die Version des Auftrags, den Kreditstatus, einen Hash der Adresse. Vor der Ausführung gleicht er sie mit dem aktuellen Datensatz ab. Nichts geändert: Er läuft weiter. Ein Feld geändert, das der Schritt nicht nutzt: Er läuft weiter und protokolliert die Abweichung. Ein Feld geändert, auf das er sich stützt: Er stoppt und gibt den Vorgang an die Planung zurück, wobei ein Mensch beide Versionen sieht.

Zwischen einer Prüfung und dem anschließenden Schreibvorgang bleibt trotzdem eine Lücke: Der Datensatz kann sich dazwischen ändern. Wo das System es unterstützt, trägt der Schreibvorgang die Bedingung selbst. Die Dataverse Web API hinter den Customer-Engagement-Apps von Dynamics 365 zum Beispiel liefert zu jedem Datensatz ein Versionskennzeichen und nimmt es beim Update wieder entgegen. Hat sich der Datensatz seit dem Lesen geändert, lehnt sie den Schreibvorgang ab. Die Vorbedingung gilt dann im Moment des Schreibens, nicht ein paar Sekunden davor.

In den Systemen, die wir untersucht haben, verursachen veraltete Pläne mehr fehlerhafte Schreibvorgänge als Denkfehler des Modells. Im Test fallen sie zudem nicht auf, weil sich Testdaten nie ändern, während der Agent nachdenkt.

Für Stammdaten gilt dasselbe. Ein Agent, der aus Geschwindigkeitsgründen eine eigene Kopie vorhält, wird früher oder später mit veralteten Daten arbeiten. Er liest die aktuellen Werte in genau dem Schritt, der sie braucht.

Den Kontext bei jedem Schritt neu aufzubauen kostet spürbar Zeit, wenn ein Vorgang lange Dokumente mitführt: einen Vertrag, eine Preisliste, eine hundertseitige Ausschreibung. Die Lösung: zwischenspeichern, was daraus abgeleitet wurde, etwa eine extrahierte Tabelle oder eine Zusammenfassung der Konditionen, und zwar mit der Version des Quelldokuments als Schlüssel, nie mit dem Gesprächsverlauf. Ändert sich die Quelle, ändert sich der Schlüssel, und der Cache greift nicht mehr. So kommt die Geschwindigkeit zurück, ohne dass der Kontext zum Speicher wird.

Gedächtnis, das Entscheidungen beeinflusst, ist eine Geschäftsregel

Agenten, die über lange Zeit laufen, bringen zunehmend ein Gedächtnis mit: Zusammenfassungen früherer Arbeit, abgelegt, um später darauf zurückzugreifen. Anthropic beschreibt in seinem Engineering-Beitrag zu Context Engineering (September 2025) strukturierte Notizen und Verdichtung für lange Aufgaben. Für Recherche- und Coding-Agenten ist das sinnvoll.

Im operativen Geschäft braucht die Verdichtung eine Grenze. Eine Zusammenfassung behält, was wichtig aussieht, und lässt den Rest weg. In einem Geschäftsvorgang ist dieser Rest oft die Ausnahme: die Gutschrift, die zu spät kam, die freigebende Person, die ein zweites Angebot verlangt hat. Deshalb gilt die Verdichtung nur für den Arbeitskontext. Die Vorgangsakte wird nie zusammengefasst. Das Modell darf eine Zusammenfassung davon lesen. Der Prüfpfad bleibt vollständig.

Bei geschäftlichen Entscheidungen braucht es eine klarere Grenze. Hat ein Agent gelernt, dass ein Lieferant immer pro Palette abrechnet, während in der Bestellung Kartons stehen, dann bestimmt diese Erkenntnis, wie künftige Rechnungen abgeglichen werden. Wie das Framework es auch nennt: Das ist eine Geschäftsregel. Deshalb wird sie als ausdrücklicher Eintrag gespeichert, mit dem Sachverhalt, dem Vorgang, aus dem er stammt, der Person, die ihn bestätigt hat, und einem Ablaufdatum. Eine Finanzanalystin kann den Eintrag lesen, korrigieren oder löschen. Ein Gedächtnis, das niemand einsehen kann, etwa Embeddings alter Gespräche, die das Verhalten auf eine Weise verschieben, die kein Wirtschaftsprüfer nachvollziehen könnte, hat bei geschäftlichen Entscheidungen nichts zu suchen.

Wo das Unternehmen sich erinnert

Den Zustand so sauber zu trennen kostet Designzeit, lange bevor der Agent etwas Beeindruckendes zeigt. Wenn eine Demo drängt, wird genau das als Erstes verschoben. Die Demo funktioniert trotzdem, denn Demos sind kurz, haben einen einzigen Nutzer und werden nie neu gestartet. Der Nutzen zeigt sich im Produktivbetrieb: Der Agent lässt sich an jeder Stelle anhalten, zwei Mitarbeitende, die denselben Vorgang ansehen, sehen dieselbe Historie, und wenn das Modell im nächsten Jahr ersetzt wird, bleibt der Zustand unberührt, weil nichts davon im Modell lag.

Im Kontext denkt der Agent. In der Vorgangsakte erinnert sich das Unternehmen.