Ihre Commerce AI kann sich nicht erinnern, was sie vor 5 Sekunden getan hat. Eine neue Architektur kann das beheben.

TL;DR: Ihr Agent hat Amnesie

• Die meisten KI-Agenten sind heute zustandslos. Sie haben keine zuverlässige Erinnerung an vergangene Aktionen, was sie für kritische Handelsoperationen wie Bestandsverwaltung oder mehrstufige Kundenreisen ungeeignet macht. Dies ist kein Fehler; es ist ein grundlegender Mangel in ihrem Design, der zu unvorhersehbaren, nicht auditierbaren Fehlern führt.
• Ein neues Paper von arXiv dieser Woche, "ESAA: Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1), schlägt eine Lösung vor, indem es ein kampferprobtes Unternehmensmuster – Event Sourcing – für agentenbasierte Systeme adaptiert [5]. Es trennt die Intentionen eines Agenten (was er tun will) von seinen Effekten (was tatsächlich passiert).
• Dieser architektonische Wandel ermöglicht die Erstellung von auditierbaren, wiederholbaren und resilienten „agentic“ Workflows. Er ermöglicht es Marken, heterogene LLMs (wie GPT-5 und Claude Sonnet 4.6) zu verwenden, Anbieterabhängigkeit ("vendor lock-in") zu vermeiden und langfristige Agenten zu bauen, denen endlich missionskritische Aufgaben anvertraut werden können, ohne ihren eigenen Zustand zu halluzinieren [6].

Hier ist ein Szenario, das immer realistischer wird. Der CTO einer schnell wachsenden DTC-Marke – nennen wir sie "Melrose Active" – war in voller Panik. Ihr neuer autonomer Bestandsagent, ein System, das ihnen als Gipfel des "agentic commerce" verkauft worden war, hatte gerade versucht, 50.000 Einheiten einer langsam verkaufenden SKU zu bestellen. Der Auslöser? Ein Netzwerkfehler während einer Routinebestandsprüfung. Der Agent, der mitten im Betrieb seinen Kontext verloren hatte, führte seine ursprüngliche Logik erneut aus, interpretierte die Teildaten des fehlgeschlagenen ersten Versuchs falsch und kam zu dem Schluss, dass das Lager leer war. Es war ein Millionen-Dollar-Fehler, der nur durch eine "human-in-the-loop"-Warnung abgefangen wurde, die, offen gesagt, den ganzen Zweck des autonomen Systems zunichtemachte.

Das Szenario ist ein Beispiel, aber keineswegs weit hergeholt. Es ist die direkte Konsequenz des schmutzigen kleinen Geheimnisses des „agentic AI“-Booms: Die meisten dieser Systeme sind auf Sand gebaut. Sie sind zustandslos, amnesische Systeme, die in einer ewigen Gegenwart agieren. Sie können sich nicht zuverlässig daran erinnern, was sie vor einer Minute getan haben, geschweige denn gestern. Für einfache Frage-Antwort-Chatbots ist dies eine Kleinigkeit. Für die komplexen, zustandsbehafteten, langlebigen Prozesse, die den echten Handel definieren – Inventar, Logistik, Personalisierung, Kundenservice – ist es eine katastrophale Belastung.

Während der Rest der Welt von Demos von KI-Agenten fasziniert ist, die Flüge buchen oder Reisepläne "vibe researchen" [1], kämpfen wir in den Schützengräben des Aufbaus tatsächlicher Handelssysteme einen viel fundamentaleren Kampf: den Kampf um den Zustand (State). Und ein Paper, das diese Woche stillschweigend auf arXiv erschien, könnte eine der wichtigsten Entwicklungen in diesem Kampf sein.

Also, drei KI-Agenten gehen in eine Bar... und brennen sie nieder?

Das Problem mit dem Agenten von Melrose Active war nicht nur ein einzelner Fehlerpunkt. Es war ein Symptom eines viel tieferen, systemischen Problems bei Multi-Agenten-Systemen. Wenn Sie mehrere autonome Agenten einsetzen, die Ressourcen teilen – wie Inventardatenbanken, Preismaschinen oder API-Gateways – fallen sie nicht nur einzeln aus. Sie fallen oft synchronisiert und korreliert aus, was den Schaden verstärkt.

Ein faszinierendes arXiv-Paper, das erst diese Woche veröffentlicht wurde, "Three AI-agents walk into a bar … ‘Lord of the Flies’ tribalism", illustriert perfekt dieses Albtraumszenario [2]. Forscher versetzten autonome LLM-Agenten in ein klassisches Ressourcenkonfliktszenario (das El Farol Bar Problem) und beobachteten, was geschah. Anstatt als unabhängige, rationale Akteure zu handeln, bildeten die Agenten schnell "Stämme" basierend auf ihren zugrunde liegenden Denkmustern. Einige wurden "aggressiv" (27,3% der Population) und versuchten immer, auf die Ressource zuzugreifen. Andere waren "konservativ" (24,7%), und eine große Mehrheit wurde "opportunistisch" (48,1%).

Das erschreckende Ergebnis? Dieser aufkommende Tribalismus führte zu synchronisiertem Verhalten, was systemische Überlastungen und Ausfälle verursachte, die weit schlimmer waren, als eine einfache Zufallsverteilung sie bewirkt hätte. Wenn ein Agent beschließt, Ihre Bestands-API zu überfluten, ist es wahrscheinlich, dass Dutzende andere, die auf demselben grundlegenden Modell und derselben Logik aufgebaut sind, dasselbe tun werden. Dies ist die Gefahr, scheinbar autonome Systeme einzusetzen, denen es an echter Unabhängigkeit in ihren Fehlermodi mangelt. Ohne ein robustes architektonisches Rückgrat ist Ihre „agentic“ Belegschaft kein Team von Individuen; sie ist ein Mob, anfällig für Flash-Crashes und herdenartige Dummheit.

Deshalb ist die Besessenheit von Agenten-Fähigkeiten – was sie tun können – so fehl am Platz. Die wahre Herausforderung besteht darin, eine Commerce-KI-Architektur aufzubauen, die nicht nur den Ausfall eines Agenten, sondern Dutzende von ihnen im Einklang elegant bewältigen kann. Wir brauchen Systeme, die deterministisch, auditierbar und resilient gegenüber dem inhärenten Chaos der LLM-gesteuerten Logik sind. Wir müssen Fehler einplanen, nicht nur Erfolge bewundern.

Die Amnesie-Maschine: Warum Ihr aktueller KI-Agent im Handel versagt

Die Hauptursache dieser Zerbrechlichkeit ist etwas, das Ingenieure "State Management" nennen. Oder, in diesem Fall, ein völliger Mangel daran. Die meisten „agentic“ Frameworks behandeln heute, wie die beliebten ReAct (Reason+Act) Schleifen, jede Interaktion als ein weitgehend unabhängiges Ereignis. Das "Gedächtnis" des Agenten ist oft nur die Konversationshistorie, die in das Kontextfenster eines LLM-Aufrufs gestopft wird. Das ist kein Gedächtnis; es ist ein Haftnotiz, und ein sehr kleiner dazu.

Ein Paper von Anfang dieser Woche zur Bewertung des Langzeitspeichers für „agentic“ Anwendungen bestätigte, was viele von uns in der Praxis gesehen haben: Dieser Ansatz verschlechtert sich im Laufe der Zeit katastrophal [7]. Wenn die Aufgabe komplexer wird und die Anzahl der Durchläufe zunimmt, füllt sich das Kontextfenster, kritische Informationen gehen verloren, und der Agent beginnt abzudriften. Er vergisst seine anfänglichen Anweisungen, seine früheren Aktionen und den Zustand der Welt, die er manipulieren soll.

Dies hat tiefgreifende, spürbare Konsequenzen für jeden ernsthaften Anwendungsfall im Handel:

1. Fehlende Auditierbarkeit: Wenn die Aktionen eines Agenten nur transiente API-Aufrufe sind, die von einem probabilistischen LLM gesteuert werden, was ist die "Source of Truth"? Wenn Ihre Finanzabteilung fragt, warum Ihr dynamischer Preisagent den Preis eines Flagship-Produkts mitten in der Nacht um 90% gesenkt hat, lautet Ihre einzige Antwort "das LLM hat es entschieden". Es gibt kein unveränderliches Protokoll der Entscheidungen, der Daten, die sie informierten, oder der Abfolge der Ereignisse. Dies ist ein "Non-Starter" für jeden regulierten oder missionskritischen Prozess.

2. Keine Idempotenz: In verteilten Systemen ist Idempotenz König. Sie ist die Garantie, dass die mehrfache Ausführung derselben Anforderung dasselbe Ergebnis liefert wie die einmalige Ausführung. Als der Melrose Active-Agent nach einem Netzwerkfehler seine Bestandsprüfung wiederholte, hätte dies eine harmlose, idempotente Operation sein sollen. Stattdessen wurde die Wiederholung, weil ihr Zustand verloren ging, zu einer neuen, unabhängigen Aktion mit einem katastrophalen Ergebnis. Die meisten Agenten-Frameworks erzwingen oder berücksichtigen nicht einmal Idempotenz, was sie angesichts der unvermeidlichen Netzwerkfehler der realen Welt brüchig macht.

3. Unfähigkeit zur Wiederholung und Fehlerbehebung: Wenn das System ausfällt, wie debuggen Sie es? Mit einem zustandslosen Agenten können Sie das nicht. Sie können die genaue Abfolge der Ereignisse und Zustände, die zum Fehler führten, nicht wiedergeben. Sie starren auf undurchsichtige Protokolle des LLM-Anbieters und versuchen, eine probabilistische Black Box rückzuentwickeln. Es ist, als würde man versuchen, ein komplexes Finanzmodell zu debuggen, indem man eine Nachrichtensendung im Kabelfernsehen verfolgt.

Das sind keine Randfälle. Dies ist das Standardverhalten der Mehrheit der heute angebotenen „agentic commerce“-Systeme. Sie sind grundsätzlich unzuverlässig, nicht auditierbar und für Produktionsumgebungen, in denen echtes Geld und echtes Inventar auf dem Spiel stehen, ungeeignet. Sie sind eine architektonische Belastung, die darauf wartet, ausgelöst zu werden.

Ist Event Sourcing die unsexy, überfällige Lösung für „agentic commerce“?

Das bringt mich zu dem Paper, das diese Woche mit dem entschieden unsexy Titel landete: "ESAA: Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1) [5]. Es schlägt eine Lösung vor, die weder cleveres Prompting noch ein größeres Modell ist. Es ist ein architektonisches Muster, das aus der Welt der hochriskanten, groß angelegten Unternehmenssysteme entlehnt wurde: Event Sourcing.

Event Sourcing ist nicht neu. Es ist ein Kernmuster in Architekturen wie CQRS (Command Query Responsibility Segregation), die seit Jahren in der Fintech-, Banken- und Logistikbranche eingesetzt werden – überall dort, wo Auditierbarkeit und Zuverlässigkeit nicht verhandelbar sind. Die Kernidee ist einfach: Anstatt den aktuellen Zustand eines Systems zu speichern, speichern Sie ein rein angehängtes Protokoll aller Ereignisse, die jemals stattgefunden haben. Der aktuelle Zustand wird dann durch die Wiedergabe dieser Ereignisse abgeleitet.

Das ESAA-Paper schlägt vor, genau dieses Muster auf KI-Agenten anzuwenden. Anstatt einem LLM zu erlauben, Tools direkt aufzurufen und den Zustand der Welt zu ändern, besteht die einzige Aufgabe des Agenten darin, ein JSON-Objekt zu emittieren, das seine Intention beschreibt. Das ist alles. Diese Intention wird als Ereignis behandelt. Ein separates, deterministisches System – der Orchestrator – ist dann dafür verantwortlich, dieses Ereignis zu validieren, es in einem unveränderlichen Protokoll zu speichern und erst dann seine Effekte anzuwenden (z.B. eine Shopify-API aufzurufen oder eine Datenbank zu aktualisieren).

Diese Trennung ist der Schlüssel. Der probabilistische, unvorhersehbare, kreative Teil des Systems (das LLM) ist vom deterministischen, zuverlässigen, zustandsändernden Teil des Systems (dem Orchestrator) abgeschottet.

Wie ESAA funktioniert: Intentionen, nicht Aktionen

Der Datenfluss in einem ESAA-basierten System bietet die Leitplanken, die die heutigen Agenten so dringend benötigen. Er erzwingt ein Maß an Disziplin, das die Art von Fehlern verhindert, die wir bei Melrose Active gesehen haben.

Der Prozess sieht wie folgt aus:

Dies ist nicht nur ein theoretisches Diagramm. Das ESAA-Paper demonstriert diese Architektur, die mit heterogenen Modellen wie OpenAIs GPT-5 und Anthropic

• agentic commerce
• commerce ai architecture
• event sourcing
• llm
• ai