Der Kontext eines Agenten ist kein Speicher

Im ERP stand derselbe Lieferant zweimal. Das interne Team eines Kunden hatte einen Agenten für das Lieferanten-Onboarding gebaut: 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.

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 zuerst die Absicht fest (Lieferant anlegen, mit diesem Geschäftsschlüssel). Dann fragt er das führende System, ob es unter diesem Schlüssel schon einen früheren Versuch gab. Nur wenn nicht, führt er die Änderung aus, und anschließend speichert er die Kennung, die das System zurückgibt. Ein Absturz zwischen zwei dieser Schreibvorgänge richtet keinen Schaden an.

Bei der Analyse des Onboardings hat allein diese Reihenfolge die Dubletten beseitigt, ohne dass am Prompt des Agenten etwas geändert werden musste. Das Team hatte zuvor eine Woche lang am Prompt gefeilt. 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.

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.

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. Teams, die unter Druck eine Demo liefern müssen, sparen sich das. 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.