BDI Agents für Shopware: Wenn Multi-Agent Systeme zu Chatbots werden

Fünf Agenten. Zehn Container. Und immer noch ein Chatbot.

Wir haben kürzlich die Multi-Agent-Shopping-Blueprint von NVIDIA an einen Shopware-6-Shop angeschlossen. Fünf Agenten, zehn Container, ein Vektor-Index und ein deutsches LLM, das überwiegend kooperierte. Das System antwortete auf Produktfragen, zog Lagerbestände live, hielt den Konversationsverlauf. Es funktionierte.

Und trotzdem: Eine Multi-Agent-Pipeline kann sich genau so verhalten wie ein sehr teurer Chatbot. Jede Anfrage kommt rein, die Agenten wachen auf, sie reagieren, sie antworten, sie vergessen. Die nächste Anfrage wird behandelt, als hätte die letzte nie stattgefunden — abgesehen von dem, was wir explizit in den Konversationsspeicher geschrieben haben. Das ist reaktiv, nicht agentisch.

Der Unterschied ist nicht akademisch. Ein reaktives System behandelt jeden neuen Input als frisches Problem. Ein agentisches System hat etwas, das verdächtig nach Persistenz der Absicht aussieht — es weiss, was es vor der Unterbrechung erreichen wollte, und es weiss, ob die neue Information diese Absicht verändert.

Diese Unterscheidung ist nicht neu. KI-Forscher haben sie 1991 formalisiert. Das Modell heisst BDI — Belief, Desire, Intention. Es kostet weniger, BDI bewusst zu adoptieren, als es unter Produktionsdruck wieder neu zu erfinden.

---

Was reaktive Agenten falsch machen

Ein typisches Szenario aus einer Shopware-Integration. Eine wiederkehrende Kundin startet einen Chat: "Ich suche Trail-Running-Schuhe, Grösse 43, rund 220 Franken." Der Retrieval-Agent findet drei passende Modelle. Der Chatter-Agent präsentiert sie. Die Kundin sagt: "Das zweite sieht gut aus." Der Cart-Manager legt es in den Warenkorb.

Bis hier: Standardablauf. Jetzt fragt die Kundin: "Übrigens — was kostet bei euch der wasserdichte Wanderschuh, den ich letzte Woche angeschaut habe?"

Ein reaktiver Agent behandelt das als neue Anfrage. Er sucht im Katalog. Er findet den Wanderschuh. Er meldet den aktuellen Preis. Fertig.

Was ist passiert? Der Agent hat den Faden verloren. Die Kundin war in einer Kaufabsicht ("Ich kaufe heute einen Trail-Runner um 220 Franken") und hat kurz mit einem Kandidaten aus einer angrenzenden Kategorie verglichen. Ein reaktives System interpretiert den Vergleich als Reset. Ein agentisches System würde ihn als Signal lesen: Die Kundin steckt immer noch in derselben Kaufentscheidung, und die Frage zum Wanderschuh ist entweder ein letzter kategorienübergreifender Vergleich vor dem Abschluss — oder ein Hinweis darauf, dass die ursprüngliche Absicht (heute Trail-Runner kaufen) überdacht werden sollte.

Reaktive Agenten haben kein Vokabular für diese Unterscheidung. BDI hat es.

---

BDI in einem Absatz

Das BDI-Modell wurde von Rao und Georgeff in einem Paper mit dem Titel "BDI Agents: From Theory to Practice" formalisiert, präsentiert auf der ICMAS-95. Die Grundidee ist rund zehn Jahre älter, verwurzelt in Michael Bratmans philosophischer Arbeit über praktisches Schliessen. Die ingenieurtechnische Einsicht ist einfach: Ein Agent, der sich in einer veränderlichen Umgebung rational verhalten soll, braucht drei explizite Zustands-Komponenten — nicht einen grossen Sack Kontext.

• Beliefs (B): was der Agent aktuell als wahr über die Welt annimmt
• Desires (D): die Ziele, die der Agent angesichts seiner Beliefs verfolgen könnte
• Intentions (I): die Pläne, zu denen sich der Agent gerade tatsächlich verpflichtet hat

Drei Mengen, drei Update-Funktionen, eine Wahl, wie aggressiv die letzte Menge bei einer Belief-Änderung neu beurteilt wird. Das ist das ganze Framework. Es ist im Verhältnis zur Wirkung erstaunlich einfach.

Eine Notation am Rande: Rao und Georgeff schreiben die Update-Funktionen in englischem Pseudocode (option-generator, deliberate, update-intentions). Wir verwenden im Folgenden eine kürzere Schreibweise — τ für Belief Update, δ für Desire Selection, ρ für Intention Reconsideration — weil drei griechische Buchstaben in einer Tabellenzeile besser aussehen als drei verbindungsgekoppelte Funktionsnamen. Die drei Funktionen sind dieselben.

---

Die drei Funktionen — τ, δ, ρ

Belief Update: τ(B, p) → B'

$B_{t+1} = \tau(B_t,\, p_t)$

Wenn eine neue Wahrnehmung $p_t$ eintrifft (eine Preisänderung, eine User-Nachricht, ein Lager-Update), entscheidet die Belief-Update-Funktion, wie sich das Weltmodell des Agenten ändern soll. Das ist nicht dasselbe wie "Nachricht loggen und weitermachen". Es ist eine explizite Entscheidung: Überschreibt diese Beobachtung etwas, ergänzt sie etwas, oder wird sie ignoriert, weil sie einer höher gewichteten Annahme widerspricht?

In einem Multi-Agent-System auf Shopware ist genau das die Aufgabe Ihres Retriever-Agenten. Nicht nur "Daten holen". Sondern: den neuen Abruf mit dem abgleichen, was bereits im Glaubenszustand steht. Wenn der Cache der letzten Woche für einen Trail-Runner CHF 219 hielt und der Live-Feed jetzt CHF 199 zeigt — aktualisieren. Wenn der Feed flackert und null zurückgibt: nicht überschreiben. Eine Null als gültigen Belief zu akzeptieren ist ein Belief-Revisions-Bug, der den ganzen Downstream-Zustand korrumpiert.

Desire Selection: δ(B) → D

$D = \delta(B)$

Welche Ziele sind angesichts der aktuellen Beliefs aktiv? Das ist eine Prioritätsfunktion, keine Ziel-Deklaration. Jeder Retail-Agent hat einen stehenden Pool an Wünschen — Konversion maximieren, Marge oberhalb einer Schwelle halten (etwa 22% auf einer Premium-Trail-Running-Linie), Bounce-Rate senken, Upselling, wo es passt, Stock-Outs vermeiden. Diese Ziele sind meistens kompatibel, aber nicht immer. Desire Selection ist der Moment, in dem das System entscheidet, welche davon in der aktuellen Lage dominieren.

Grösse 43 des Flagship-Trail-Runners fällt auf vier Paar Lager: "Konversion auf dieser SKU maximieren" wird zurückgestuft, "auf alternatives Modell in dieser Grösse upsellen" hochgestuft. Wettbewerber senkt das vergleichbare Modell um 15%: "Marktanteil verteidigen" überholt "Marge schützen". Der Planner-Agent in einer Multi-Agent-Architektur ist genau die Komponente, die das implementieren sollte. Kein switch-Statement. Eine Funktion über Beliefs.

Intention Reconsideration: ρ(I, B') → I'

$I_{t+1} = \rho(I_t,\, B_{t+1})$

Diese Funktion ist die schwierigste — und die wichtigste. Eine Intention ist ein Plan, zu dem sich der Agent verpflichtet hat: "Ich fahre eine 10-tägige Rabattaktion auf der Trail-Runner-2026-Linie, gekoppelt an Newsletter-Anmeldung." Die Reconsideration-Funktion entscheidet bei jedem Belief-Update, ob dieser Plan beibehalten oder aufgegeben wird.

Der naive Ansatz ist, jeden Plan auf jedem Tick neu zu beurteilen. Das ist anstrengend, teuer und im Verhalten instabil — der Agent oszilliert und schliesst keinen Plan ab. Der andere naive Ansatz: nie neu beurteilen, bis ein Plan abgeschlossen ist. Das ist starr — die Welt hat sich bewegt, der Agent führt noch die Strategie der letzten Woche aus.

Gute ρ-Funktionen haben ein Kostenmodell. Reconsideration wird nur ausgelöst, wenn das Delta in den Beliefs gross genug ist, um die aktive Intention wahrscheinlich zu verändern. Rao und Georgeff fassen das als Wahl einer Commitment-Strategie: Ein blindly committed Agent beurteilt nicht neu, bis der Plan gelingt oder unmöglich wird; ein single-minded Agent verwirft Intentions nur, wenn die Beliefs sie unerreichbar machen; ein open-minded Agent beurteilt neu, sobald sich Desires verschieben. Die Autoren schreiben keine Strategie als richtig vor — die richtige Wahl hängt davon ab, wie schnell sich die Umgebung verändert. Produktive Multi-Agent-Systeme, die diese Wahl überspringen, erfinden sie typischerweise schlecht neu — als Timer oder heuristische Schwelle, die jemand in den Planner gepatcht hat.

---

Ein durchgerechnetes Beispiel

Ein konkretes Pricing-Szenario, wie es auf Shopware-Shops tatsächlich vorkommt. Mid-Premium-Trail-Runner, rund 220 Franken — der Bereich, in dem DACH-Running-Shops im Band 200–250 CHF listen.

Drei Dinge sind hier wichtig. Erstens: Der Belief-Zustand hat sich explizit geändert — nicht als Log-Eintrag, sondern als strukturiertes Update, mit dem der Rest des Systems argumentieren kann. Zweitens: Desire Selection hat die Priorität verschoben als Reaktion auf den neuen Belief; sie hat kein neues Ziel erfunden. Drittens: Die Intention wurde neu beurteilt und ersetzt — aber nur, weil das Belief-Delta eine Schwelle überschritten hat, die eine Neubeurteilung rechtfertigt. Eine Unterbietung um CHF 3 hätte ρ nicht ausgelöst; CHF 30 schon.

So weit, so zahm. Eine Rules-Engine mit guten Schwellen kommt zur ähnlichen Antwort. Der eigentliche Gewinn zeigt sich im nächsten Szenario, dort, wo Rules-Engines typischerweise scheitern.

Wo Rules-Engines scheitern

Derselbe Trail-Runner. Der Wettbewerber senkt diesmal auf CHF 153 (-30%). Aber das Lager der Grösse 43 ist bei vier Paar, Grösse 44 bei sechs. Ein Rules-Engine-Trigger auf "Wettbewerber-Unterbietung ≥ 20%" feuert die Rabattaktion. Was tatsächlich passiert: Der verbleibende Bestand brennt mit schlechterer Marge ab, Kunden in anderen Grössen klicken auf das Rabatt-Banner und springen ab, wenn ihre Grösse mitten im Checkout out-of-stock geht — und der Q2-Lagerumschlagsplan für diese SKU ist verloren.

Das BDI-System kommt zu einer anderen Antwort. Vor der Wettbewerber-Wahrnehmung gab es bereits eine aktive Intention aus dem Lagerstand-Signal: Käufer der Grösse 43 auf ein alternatives Modell upsellen. Diese Intention wurde gestern committed, als das Lager der Grösse 43 unter Schwelle fiel.

Jetzt trifft die Wettbewerber-Senkung ein. $B_1$ registriert sie. δ fragt, ob sich die aktive Desire-Menge ändert — "Stock-Out auf Flagship-Grössen vermeiden" schlägt immer noch "Marktanteil auf dieser spezifischen SKU verteidigen", die Priorität flippt also nicht. ρ schaut dann auf die aktuelle Intention zusammen mit den neuen Beliefs: Eine Rabattaktion auf diesem Produkt würde der aktiven Upsell-Intention direkt widersprechen. Statt sich zur Rabattaktion zu committen, committed sich das System zu einem anderen Plan — Rabatt auf das benachbarte Trail-Runner-Modell, das im selben Grössen-Bereich Bestand hat.

Rules-Engines behandeln jede Preis-Unterbietung als unabhängiges Ereignis. BDI behandelt sie als Kontext, der mit bereits aktiven Intentions interagiert. Das ist der eigentliche Gewinn: Intentionen tragen Kontext über Signale hinweg. Eine Regel ist eine Reaktion; eine Intention ist eine Haltung, die der Agent beibehält, bis neue Beliefs oder neue Desires sie zur Aufgabe zwingen. Erklärbarkeit ist ein netter Nebeneffekt — sie ist nicht der Grund, das so zu tun.

---

Mapping auf eine Multi-Agent Shopware Architektur

Die NVIDIA-Shopping-Blueprint, die wir an Shopware angeschlossen haben, hat fünf benannte Agenten: Planner, Retriever, Cart Manager, Chatter, Summarizer. BDI mappt sauber auf diese Topologie.

Die interessante Beobachtung ist die Aufteilung von ρ. Intention Reconsideration in einem Shopping-Assistenten lebt auf zwei Ebenen: auf der Sitzungs-Ebene (steckt die Kundin noch im Trail-Runner-Kaufflow oder ist sie tatsächlich auf Wanderschuhe gewechselt?) und auf der Strategie-Ebene (ist die 10-tägige Rabattaktion angesichts des Wettbewerbsverhaltens noch gerechtfertigt?). Diese beiden zu trennen, ist das, was einen Shopping-Agenten davor bewahrt, das zu tun, was Chatbots so gerne tun — den Faden mitten im Warenkorb verlieren.

Der Chatter-Agent ist im Gegensatz dazu reine Ausführung. Er argumentiert nicht über Intentions. Er serialisiert das, was der Planner entschieden hat, in eine natürlichsprachliche Antwort. Das ist die richtige Trennung: Argumentation passiert im BDI-Kern, Kommunikation am Rand.

---

Schweizer Kontext: Beliefs jenseits des Kontext-Windows

Eine Beobachtung, die in der englischsprachigen Diskussion oft fehlt: Für DACH-Shops mit Datenschutz-Anforderungen oder lokal gehostetem LLM lebt der Belief-Zustand nicht im Kontext-Window des Modells, sondern muss explizit nach aussen verlagert werden. Konkret heisst das: Beliefs in Redis halten, nicht in der Konversationshistorie. Sonst hängt das ganze BDI-Modell vom Kontext-Fenster des Modells ab — und schrumpft, sobald die Konversation lang wird oder das Modell beim Kunden on-prem läuft.

Das hat einen praktischen Nebeneffekt: Der Belief-Zustand wird auditierbar. Was der Agent zu welchem Zeitpunkt geglaubt hat, lässt sich aus der Redis-Datenstruktur rekonstruieren — nicht aus einem ephemeren LLM-Kontext, der mit dem nächsten Request weg ist. Für Schweizer Audits unter nDSG ist das kein Luxus, sondern Voraussetzung.

---

Drei praktische Konsequenzen für Shopware-Bauer

Drei Konsequenzen, wenn Sie BDI ernst nehmen, während Sie ein Multi-Agent-System für E-Commerce designen.

Erstens: Ihr Retriever ist nicht nur eine Suchfunktion. Er ist die einzige Komponente, die Beliefs aktualisieren darf. Jeder andere Agent liest aus dem Belief-Zustand, schreibt in den Desire- oder Intention-Zustand — aber halluziniert keine neuen Fakten über die Welt. Wenn Ihr Retriever locker ist mit dem, was er emittiert (z. B. "die Kundin will X" auf Basis eines Fuzzy-Match), haben Sie gerade die Belief-Basis für jeden Downstream-Agenten vergiftet. Behandeln Sie ihn wie einen Datenbank-Write-Pfad, nicht wie einen Best-Effort-Hinweis.

Zweitens: Ihr Planner braucht ein explizites ρ. In den meisten Produktions-Agenten, die wir gesehen haben, fehlt das — und wird implizit als "auf jedem User-Turn neu planen" implementiert. Das ist teuer und brüchig. Ein explizites ρ, selbst eine simple schwellwert-basierte Variante, lässt Sie Reaktionsschnelligkeit gegen Commitment austarieren. Für eine Einkaufs-Sitzung wollen Sie wahrscheinlich höheres Commitment (nicht den Funnel bei jedem Vergleich neu starten). Für eine Pricing-Strategie wollen Sie mehr Sensitivität (eine echte Marktbewegung soll schnell zu einer Neubeurteilung führen).

Drittens: Intentions verdienen es, First-Class-Daten zu sein. In den meisten Agent-Codebases, die wir gesehen haben, leben Intentions als impliziter Zustand in der Konversationshistorie oder im lokalen Speicher des Planners. Holen Sie sie raus. Machen Sie sie zu benannten Objekten mit explizitem Lifecycle:

Jetzt hat ρ etwas Konkretes, das es abfragen kann — keine freie Form von Mental-State, der irgendwo in Logs vergraben ist. Und Ihre Observability kann endlich die Frage beantworten "wie viele committed Intentions wurden in dieser Woche mitten in der Ausführung verworfen, aufgeschlüsselt nach Grund?" — was sich als eines der besseren Health-Signale für ein Multi-Agent-System herausstellt.

Das sind keine akademischen Spitzfindigkeiten. Das ist der Unterschied zwischen einem Multi-Agent-System, das sich über eine ganze Kaufsitzung hinweg kohärent verhält — und einem, das sich anfühlt wie fünf Agenten, die sich verhalten wie ein einzelner, sehr teurer Chatbot.

---

Modellrechnung: BDI als Health-KPI

BDI lässt sich nicht direkt in CHF beziffern wie ein PageSpeed-Score. Aber es lässt sich in einem operativen Health-KPI ausdrücken, der über die Zeit messbar ist: abandoned-intentions-per-1k-sessions. Also: Wie viele committed Intentions pro 1'000 Kaufsitzungen werden mitten in der Ausführung verworfen?

Hinweis: Die folgende Rechnung ist eine Modellrechnung, keine Messung aus einem konkreten Kunden-Setup. Die Zahlen sind illustrativ und basieren auf typischen Beobachtungen aus reaktiven Multi-Agent-Stacks im Vergleich mit BDI-strukturierten Implementierungen. Individuelle Werte variieren stark je nach Sortiment, Conversion-Funnel und Modellqualität.

Konservativ gerechnet: Bei einem Shop mit 50'000 Sessions/Monat im Multi-Agent-Modus bedeutet die Differenz 750 zusätzliche kohärent geführte Sitzungen pro Monat. Wenn nur 8% davon zur Konversion führen, die nicht stattgefunden hätte — und der durchschnittliche Warenkorbwert bei CHF 180 liegt — sind das CHF 10'800 zusätzlicher Umsatz pro Monat aus der reinen Strukturierung des Agenten-Zustands.

Diese Zahl ist absichtlich vorsichtig. Wir kennen Setups, in denen die Differenz grösser ist, und Setups, in denen sie kleiner ist. Wichtiger als die Höhe ist die Tatsache, dass die Metrik überhaupt messbar ist — was bei einem reaktiven System ohne explizite Intentions schon strukturell scheitert. Was Sie nicht als Datentyp im System haben, können Sie nicht zählen.

---

Nächste Schritte

Drei Pfade, wenn Sie das Thema selbst weitertragen wollen.

Für Teams, die parallel an Shopware-Performance arbeiten:

Eine BDI-Architektur baut auf einem performanten Backend auf. Wer beim Retriever auf 800 ms TTFB sitzt, kann sich Belief-Update-Latenz sparen — das System ist langsamer als die Realität, die es modelliert. Die methodische Vorarbeit zu diesem Thema steht in Shopware-Performance systematisch verbessern — inklusive 4-Phasen-Methodik und ROI-Modellrechnung.

Für die operative Umsetzung von Multi-Agent Systemen:

Das Companion-Buch Agentic AI in E-Commerce: A Practitioner's Guide geht in Kapitel 2 auf BDI als konzeptionelles Rückgrat ein und zeigt in den folgenden Kapiteln die Implementierung mit konkretem Toolchain (Claude und Ollama für Inferenz, uv, Pydantic, structlog, Milvus als Vektor-Datenbank in den Beispiel-Implementierungen). Leanpub Early Access ab 23. Mai 2026.

Für Shops, die bereits Multi-Agent-Probleme in Produktion haben:

Eine kostenlose Bedarfsanalyse dauert 30 bis 60 Minuten. Wir schauen gemeinsam, ob die Inkohärenz zwischen den Agenten ein Architekturproblem ist (BDI fehlt) oder ein Implementierungsproblem (BDI ist da, aber ρ wird auf jedem Tick ausgelöst). Keine Verkaufsgespräche. Nur Zahlen, Fakten und Erfahrung aus aktiven Shopware-Builds.

---

Quellen

[1] Rao, Anand S. und Georgeff, Michael P.: "BDI Agents: From Theory to Practice". Proceedings of the First International Conference on Multi-Agent Systems (ICMAS-95), San Francisco, 1995, S. 312–319.

[2] Rao, Anand S. und Georgeff, Michael P.: Modeling Rational Agents within a BDI-Architecture. Proceedings of the Second International Conference on Principles of Knowledge Representation and Reasoning (KR-91), Cambridge, MA, 1991, S. 473–484. Erste formale Publikation des BDI-Modells.

[3] NVIDIA: "AI Blueprint: Retail Shopping Assistant" — Referenzarchitektur mit fünf Agenten (Planner, Retriever, Cart Manager, Chatter, Summarizer). Basis für die Shopware-Integration in diesem Artikel.

[4] Gökçe, Mehmet: Agentic AI in E-Commerce: A Practitioner's Guide — Leanpub Early Access ab 23. Mai 2026. Kapitel 2 vertieft das BDI-Modell und die Mathematik dahinter; die folgenden Kapitel zeigen die operative Implementierung.

---

Über den Autor

Mehmet Gökçe ist Software & Data Engineer und führt MEMOTECH mit Sitz in St. Gallen. IT-Expertise seit 1998, Schwerpunkt Multi-Agent Systeme und E-Commerce-Plattformen. Autor von [Shop-Performance in 30 Tagen] (https://memotech.ch/buch/shop-performance-in-30-tagen) (Leanpub, 2025) und Agentic AI in E-Commerce: A Practitioner's Guide (Leanpub Early Access ab 23. Mai 2026).

GitHub | LinkedIn