Wo ein KI-Agent seinen Zustand halten sollte

Im ERP, dem zentralen Geschäftssystem des Unternehmens, stand derselbe Lieferant zweimal. Ein KI-Agent übernahm das Anlegen neuer Lieferanten: Er las die Unterlagen, prüfte die Steuernummer, legte den Lieferanten an, forderte die Bankdaten an und hinterlegte die Zahlungsbedingungen. Im Test lief er fehlerfrei. In der ersten Woche im Echtbetrieb startete ein planmäßiges Software-Update den Dienst mitten in einem Vorgang neu, und der Agent legte den Lieferanten ein zweites Mal an.

Das Modell hatte beide Male richtig gefolgert. Das Problem war, wo der Agent festhielt, was er schon erledigt hatte: in einem Aufruf an das ERP und dessen Antwort, im Gesprächsverlauf, den der Neustart löschte. Das Bild des Agenten von der Lage und die Lage selbst stimmten nicht mehr überein, und nichts im Design bemerkte es.

Die meisten Agentenfehler, die wir untersuchen, sehen so aus: Fehler in der Ablage von Information, die wie Denkfehler wirken, weil sich das Symptom in der Ausgabe zeigt.

Drei Arten von Information, drei Zuständigkeiten

Viele Agenten-Werkzeuge verwischen drei Arten von Information, und genau dort fangen die Probleme an.

Das führende System ist das Geschäftssystem mit den maßgeblichen Daten: das ERP, die Kundendatenbank, das Ticketsystem, die Bank. Es setzt eigene Prüfungen durch und gehört der IT des Kunden. Der Agent ändert es nur über bestehende Schnittstellen.

Die Vorgangsakte dokumentiert die Arbeit dauerhaft: erledigte Schritte, Entscheidungen, Belege, Freigaben. Sie wird vom Workflow geschrieben, nicht vom KI-Modell. Sie liegt neben dem Geschäftssystem in einem Speicher des Kunden, nie in freien Feldern des ERP, wo sie den Agenten an die Updates des ERP binden und Arbeitsnotizen mit maßgeblichen Daten vermischen würde.

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

Die Regel: Der Kontext ist eine Sicht, nie ein Speicher. Was einen Schritt überdauern muss, wird in die Vorgangsakte oder ins Geschäftssystem geschrieben, bevor der Schritt als erledigt gilt. Bricht der Prozess irgendwo ab, baut ein neuer den Kontext wieder auf und macht weiter. Das testen wir wörtlich: In der Abnahme beenden wir den Agenten an zufälligen Stellen und prüfen, ob jeder Vorgang trotzdem genau einmal abgeschlossen wird.

Es gibt einen zweiten Grund, neu aufzubauen statt anzuhäufen. Die Engineers von Anthropic beschreiben, was sie Context Rot nennen („Effective context engineering for AI agents“, September 2025): Je mehr ein Modell halten soll, desto schlechter nutzt es das, Kontext ist also ein Budget mit abnehmendem Ertrag. Ein Kontext, der pro Schritt neu entsteht, enthält nur, was dieser Schritt braucht, und der Agent bleibt auch am zweiten Tag eines Vorgangs präzise, wenn ein angehäufter Verlauf voller überholter Werte wäre.

So lässt sich auch jedes Agentendesign schnell prüfen, das eines Anbieters eingeschlossen: Fragen Sie, wo jede der drei Arten liegt. Lautet die Antwort bei zweien „im Gesprächsverlauf“, gibt es nur eine.

Erst die Absicht festhalten, dann handeln

Ein sicherer Neustart hängt von der Reihenfolge der Schreibvorgänge ab. Vor jedem Schritt, der außerhalb etwas verändert, hält der Workflow fest, was er gleich tut (diesen Lieferanten anlegen, für diesen Vorgang), und danach die Kennung, die das System zurückgab. Ein Neustart findet dann eine offene Absicht statt eines leeren Blatts, und nichts wird wiederholt, bevor sie geklärt ist.

Beim Onboarding beseitigte das die Dublette, ohne ein Wort an den Anweisungen des Agenten zu ändern, die nie die Ursache waren. Der Preis sind ein paar zusätzliche Schreibvorgänge und etwas Wartezeit je Schritt, immer billiger als ein doppelter Lieferant, Auftrag oder eine doppelte Zahlung.

Ein Plan veraltet, sobald er steht

Viele Agenten-Werkzeuge planen einmal und führen dann aus. Im operativen Geschäft ist das verkehrt herum. In einem zweitägigen Vorgang ändert ein Einkäufer die Bestellung, das Kreditmanagement sperrt den Kunden und jemand korrigiert die Adresse, während der Agent einen Plan mit den alten Werten hält.

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

Zwischen Prüfung und Schreiben bleibt eine Lücke. Wo das System es unterstützt, trägt der Schreibvorgang die Bedingung selbst. Die Dataverse Web API hinter den Kunden-Apps von Microsoft Dynamics 365 liefert zum Beispiel zu jedem Datensatz ein Versionskennzeichen und lehnt ein Update ab, wenn sich der Datensatz seit dem Lesen geändert hat. Die Prüfung gilt dann im Moment des Schreibens, nicht Sekunden davor.

In den Systemen, die wir untersucht haben, verursachen veraltete Pläne mehr falsche Änderungen als Denkfehler, und im Test fallen sie nicht auf, weil sich Testdaten nie ändern, während der Agent nachdenkt. Für Stammdaten wie Kunden- und Produktlisten gilt dasselbe: Ein Agent mit eigener Kopie für mehr Tempo arbeitet früher oder später mit einer veralteten, deshalb liest er aktuelle Werte in dem Schritt, der sie braucht.

Den Kontext jedes Mal neu aufzubauen kostet Zeit, wenn ein Vorgang lange Dokumente mitführt: einen Vertrag, eine Preisliste, eine hundertseitige Ausschreibung. Deshalb bewahren wir auf, was daraus gewonnen wurde, etwa eine extrahierte Tabelle oder eine Zusammenfassung der Konditionen, gekennzeichnet mit der Version der Quelle, nie mit dem Gespräch. Ändert sich die Quelle, wird der alte Auszug nicht mehr genutzt. Das Tempo kehrt zurück, ohne dass der Kontext zum Speicher wird.

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

Agenten bringen heute oft ein Gedächtnis mit: Zusammenfassungen früherer Arbeit, für später abgelegt. Derselbe Beitrag von Anthropic beschreibt Notizen und Zusammenfassungen für lange Aufgaben, was für Recherche- und Programmieragenten passt. Im operativen Geschäft braucht das Zusammenfassen eine Grenze. Eine Zusammenfassung behält, was wichtig aussieht, und der Rest ist in einem Geschäftsvorgang oft die Ausnahme: die Gutschrift, die zu spät kam, die freigebende Person, die ein zweites Angebot verlangte. Zusammengefasst wird deshalb nur der Arbeitskontext. Das Modell darf eine Zusammenfassung der Vorgangsakte lesen; die Akte selbst, der Prüfpfad, bleibt vollständig.

Bei Geschäftsentscheidungen braucht es eine klarere Grenze. Lernt ein Agent, dass ein Lieferant pro Palette abrechnet, während die Bestellung Kartons zählt, bestimmt das, wie künftige Rechnungen abgeglichen werden. Das ist eine Geschäftsregel und wird als solche gespeichert: der Sachverhalt, der Vorgang, aus dem er stammt, wer ihn bestätigt hat, wann er abläuft. Eine Finanzanalystin kann sie lesen, korrigieren oder löschen. Ein Gedächtnis, das niemand einsehen kann, etwa gespeicherte Spuren alter Gespräche, die das Verhalten auf eine Weise verschieben, die kein Wirtschaftsprüfer nachvollziehen könnte, hat bei Geschäftsentscheidungen nichts zu suchen.

Wo das Unternehmen sich erinnert

Diese Trennung kostet Designzeit, bevor der Agent etwas Beeindruckendes zeigt, also wird sie unter Demo-Druck verschoben, und die Demo funktioniert trotzdem: Demos sind kurz, haben einen Nutzer und werden nie neu gestartet. Es zahlt sich im Echtbetrieb aus: Der Agent lässt sich an jeder Stelle anhalten, zwei Mitarbeitende sehen bei einem Vorgang dieselbe Historie, und wird das Modell nächstes Jahr ersetzt, geht nichts verloren, weil nichts im Modell lag.

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