Ein Kunde sucht nicht mehr zwangsläufig über Kategorien und Filter nach einem Produkt. Die Anfrage kann inzwischen auch lauten: „Ich brauche wasserdichte Wanderschuhe unter 150 Euro, die spätestens Freitag geliefert werden können." Ein AI-Agent soll passende Produkte finden, Varianten vergleichen, die tatsächliche Verfügbarkeit prüfen und im nächsten Schritt vielleicht sogar den Kauf vorbereiten oder abschließen.
Die sichtbare Interaktion wirkt einfach. Hinter einer belastbaren Antwort liegen aber Produktkatalog, Preise, Promotions, Lagerbestände, Lieferoptionen, Kundendaten, Payment und Order Management. Sobald ein Agent mehr tun soll als Produkte vorzuschlagen, müssen diese Systeme in der richtigen Reihenfolge aktuelle und verbindliche Informationen liefern. Damit wird Agentic Commerce schnell zu einem Integrationsprojekt: Der Agent versteht die Kaufabsicht und steuert die Interaktion, die Geschäftssysteme entscheiden, was tatsächlich verkauft, zugesagt und gebucht werden kann.
Die Produktsuche wandert in neue Kanäle
Salesforce hat Agentforce Commerce 2026 deutlich ausgebaut. Shopper Agent, Buyer Agent und Merchant Agent sind allgemein verfügbar, Agentic Commerce Search ergänzt die Plattform um eine AI-native Produktsuche und Salesforce bindet Commerce stärker an externe AI-Kanäle wie ChatGPT sowie Google Search mit AI Mode und Gemini an. Damit wird Produktentdeckung zunehmend aus der klassischen Storefront herausgelöst und in dialogorientierte Oberflächen verlagert.
Für die Integrationsarchitektur ändert sich dadurch vor allem der Einstieg in den Kaufprozess. Früher navigierte der Kunde selbst durch Kategorien, Produktseiten, Filter und Checkout-Schritte. Ein Agent kann mehrere dieser Schritte aus einer natürlich formulierten Absicht ableiten. Für die Systeme dahinter wird damit wichtiger, dass Produktdaten, Preis, Bestand und Bestellung konsistent zusammenpassen.
| Frage des Kunden | Was dahinter funktionieren muss |
|---|---|
| Welches Produkt passt zu meiner Anfrage? | Produktkatalog, Search, PIM |
| Was kostet es für mich? | Pricing, Promotions, Commerce, ERP |
| Ist die Variante verfügbar? | Inventory, ERP, POS, WMS |
| Kommt sie bis Freitag an? | Bestand, Fulfillment, Order Management |
| Kann ich jetzt kaufen? | Cart, Tax, Payment, Fraud |
| Was passiert nach dem Kauf? | Order Management, ERP, Fulfillment, Service |
Eine überzeugende Produktempfehlung ist also nur der erste Schritt. Je näher ein Agent an den Kaufabschluss kommt, desto stärker hängt seine Antwort von bestehenden Integrationen und der Verlässlichkeit der Backend-Systeme ab.
Produktsuche braucht verlässliche Produktdaten
Conversational Search verändert, wie Kunden Anforderungen formulieren. Eine klassische Suche verarbeitet vielleicht „Wanderschuh Herren Größe 44". Ein Agent bekommt deutlich offenere Anforderungen: wasserdicht, für eine mehrtägige Tour geeignet, unter einem bestimmten Budget und möglichst bis Ende der Woche lieferbar. Agentic Commerce Search soll solche Absichten kontextbezogen verstehen und in passende Produktergebnisse übersetzen.
Die Qualität der Empfehlung hängt trotzdem davon ab, welche Produktinformationen darunter verfügbar sind. Varianten, Größen, Materialien, Kategorien, SKUs und weitere Attribute müssen eindeutig gepflegt sein. In größeren Commerce-Landschaften verteilen sich diese Informationen häufig auf PIM, Commerce-Plattform, ERP und weitere Systeme. Für einen menschlichen Nutzer lassen sich manche Inkonsistenzen noch über die Oberfläche abfangen. Ein Agent übernimmt dieselben Informationen direkt in seine Empfehlung und macht schlechte Stammdaten dadurch unmittelbar sichtbar.
Der Agent kann die Kaufabsicht verstehen. Verbindliche Produkt-, Preis- und Bestandsinformationen müssen weiterhin aus den dafür verantwortlichen Systemen kommen.
Verfügbarkeit ist mehr als eine Lagerzahl
Nach der Produktsuche wird Agentic Commerce operativ anspruchsvoller. Die Frage „Ist der Schuh verfügbar?" kann mehrere Systeme betreffen. Bestand liegt vielleicht im ERP, Filialbestände kommen aus dem POS, Reservierungen werden im Order Management berücksichtigt und ein Warehouse Management System kennt bereits Ware, die für andere Bestellungen eingeplant wurde.
Für einen Kauf reicht deshalb häufig ein einfacher stock = 4 Wert nicht aus. Entscheidend ist, wie viele Einheiten tatsächlich verkaufbar sind, an welchem Standort sie liegen, ob ein Teil bereits reserviert wurde und welche Fulfillment-Optionen für die konkrete Lieferadresse bestehen. Besonders deutlich wird das bei Lieferzusagen: Fragt ein Kunde am Donnerstagabend nach einer Lieferung am Freitag, braucht der Agent neben Bestand auch Fulfillment-Standort, Lieferregion, Cut-off-Zeit und Versandoptionen.
MuleSoft deckt solche Integrationsmuster unter anderem mit dem Accelerator for Retail ab. Zu den dokumentierten Use Cases gehören Product Sync, Sales Order Sync, POS Integration und Real-Time Inventory Management. Ziel ist, Produkt-, Bestands- und Auftragsinformationen aus verschiedenen Retail-Systemen über wiederverwendbare Integrationen bereitzustellen.
Was „verfügbar" im Kaufprozess bedeuten kann
| Ebene | Beispiel |
|---|---|
| Physischer Bestand | 4 Stück befinden sich im Lager |
| Verkaufbarer Bestand | 2 Stück sind noch nicht reserviert |
| Standort | Ware liegt im Lager Wien |
| Fulfillment | Lieferung nach Graz ist möglich |
| Zeit | Bestellung vor dem Cut-off kann Freitag eintreffen |
Damit bekommt Echtzeitfähigkeit einen klaren Business-Kontext. Eine Produktbeschreibung muss nicht in jeder Sekunde neu abgefragt werden. Bei Bestand oder einer Lieferzusage können wenige Minuten dagegen darüber entscheiden, ob ein Agent etwas anbietet, das für den Kunden tatsächlich nicht mehr verfügbar ist.
Die Anforderungen an Aktualität sollten deshalb nicht für alle Informationen gleich definiert werden. Für eine Produktempfehlung kann ein leicht verzögerter Datenstand akzeptabel sein, beim Checkout möglicherweise nicht. Architekturteams sollten festlegen, welche Information in welchem Prozessschritt wie aktuell sein muss und welches System dafür die verbindliche Antwort liefert.
Auch der Preis braucht einen Systemkontext
Beim Preis entsteht ein ähnliches Problem. Im einfachsten B2C-Fall gibt es einen Listenpreis und vielleicht eine aktuelle Promotion. In realen Commerce-Landschaften können Region, Währung, Kundengruppe, Loyalty-Status, Aktionszeitraum oder Produktkombinationen beeinflussen, welcher Preis für einen konkreten Kunden gilt. Im B2B-Commerce kommen zusätzlich Vertragskonditionen, Mengenstaffeln und kundenspezifische Kataloge hinzu. Salesforce verbindet mit Headless B2B Commerce beispielsweise Kataloge, Preise, Kundenkonten und den Buyer Agent über ein gemeinsames Backend.
Der Agent sollte den Preis deshalb nicht aus einer alten Produktbeschreibung oder einem zuvor generierten Kontext übernehmen. Vor einer verbindlichen Aussage muss die aktuelle Pricing-Logik greifen. Dasselbe gilt für Promotions, Versandkosten und Steuern. Je näher der Agent an die Transaktion kommt, desto weniger darf sich der Prozess auf Informationen verlassen, die nur wahrscheinlich aktuell sind.
Je näher ein Agent am Kaufabschluss arbeitet, desto weniger reicht „wahrscheinlich korrekt". Produktsuche kann interpretieren, Preis, Verfügbarkeit und Bestellung müssen verbindlich sein.
Der Kaufabschluss ist eine Prozesskette
Zwischen „Ich möchte dieses Produkt" und einer erfolgreichen Bestellung liegen mehrere Zustandsänderungen. Ein Warenkorb wird erstellt, Varianten und Mengen werden validiert, Versandmöglichkeiten berechnet, Steuern bestimmt und Zahlungsinformationen verarbeitet. Danach muss die Bestellung eindeutig angelegt und an Order Management, ERP oder Fulfillment weitergegeben werden.
Bei einem AI-Agenten wird ein Teil dieser Interaktion aus der klassischen Shop-Oberfläche herausgelöst. Die darunterliegende Commerce-Logik bleibt trotzdem bestehen. Zusätzlich werden klassische Integrationsthemen wie Idempotenz, Validierung und Fehlerbehandlung wichtiger: Wenn eine Anfrage wegen eines Timeouts wiederholt wird, darf daraus keine zweite Bestellung entstehen. Ändert sich während des Prozesses der Bestand oder eine Promotion läuft ab, muss der Checkout mit dem neuen Zustand umgehen können.
Der Prozess lässt sich vereinfacht so darstellen:
Kaufabsicht → Produkt & Variante validieren → Preis & Verfügbarkeit prüfen → Warenkorb & Versand → Zahlung → Bestellung → Fulfillment
Auch Rückfragen und Änderungen müssen sauber in diesen Ablauf passen. Wenn der Kunde nach der Produktempfehlung die Größe ändert, eine andere Lieferadresse nennt oder sich während des Checkouts ein Preis verändert, sollte der Agent den Dialog fortsetzen können, während die Backend-Systeme weiterhin mit klar definierten Zuständen arbeiten. Der Agent steuert damit die Interaktion, die verbindlichen Zustandsänderungen bleiben Aufgabe der Commerce-Systeme.
UCP und ACP standardisieren neue Commerce-Kanäle
Mit agentischen Shopping-Kanälen entsteht zusätzlich die Frage, wie AI-Plattformen mit den Commerce-Systemen eines Händlers kommunizieren. Google hat dafür 2026 das Universal Commerce Protocol (UCP) vorgestellt. UCP schafft eine gemeinsame Sprache zwischen Consumer-Oberflächen, Unternehmen und Payment-Providern und ist darauf ausgelegt, mit bestehender Retail-Infrastruktur zusammenzuarbeiten.
Daneben existiert das von Stripe und OpenAI entwickelte Agentic Commerce Protocol (ACP). Es standardisiert Commerce-Flows zwischen AI-Anwendungen und Händlern. Der Agent kann einen Checkout anstoßen, während der Händler weiterhin Kontrolle über Sortiment, Transaktionsverarbeitung, Payment und Fulfillment behält.
| UCP | ACP | |
|---|---|---|
| Initiatoren | Google mit Industriepartnern | Stripe und OpenAI |
| Schwerpunkt | Commerce von Discovery bis Checkout und Post-Purchase | agentische Kauf- und Checkout-Flows |
| Typische AI-Oberflächen | Google-Ökosystem und weitere kompatible Plattformen | unter anderem ChatGPT |
| Backend | bestehende Retail-Infrastruktur bleibt relevant | bestehende Commerce- und Payment-Systeme bleiben relevant |
Diese Standards ersetzen die Integrationsarbeit im Backend nicht. Sie vereinfachen vor allem die Kommunikation zwischen neuen AI-Kanälen und Händlern. Produktkatalog, Inventory, Pricing, Payment und Order Management müssen weiterhin verlässlich angebunden sein. Für Unternehmen wird deshalb wichtiger, Commerce-Funktionen so bereitzustellen, dass mehrere Kanäle auf dieselbe Geschäftslogik zugreifen können.
Die Integrationskette hinter dem Agenten
Für eine Enterprise-Architektur sollte möglichst wenig davon abhängen, ob der Kunde über Storefront, ChatGPT, Gemini oder einen eigenen Shopper Agent kommt. Produkt-, Preis-, Bestands- und Bestelllogik sollte nicht für jeden Kanal neu implementiert werden.
Eine mögliche Architektur:
Storefront / AI-Kanal → Commerce Experience → Search / Pricing / Availability / Checkout → APIs & Integrationsprozesse → PIM / ERP / WMS / OMS / Payment
Die mittlere Ebene ist dabei besonders wichtig. Ein Agent sollte nicht für jede Frage direkt auf ERP, Warehouse Management und Payment-System zugreifen müssen. Sinnvoller sind fachlich abgegrenzte Funktionen, die vorhandene Geschäftslogik bündeln. Ein Availability-Service kann beispielsweise bestimmen, ob die gewünschte Menge für einen Standort und Liefertermin verfügbar ist. Ein Pricing-Service führt Preis, Kundengruppe und Promotion zusammen, während ein Order-Prozess verhindert, dass wiederholte Anfragen doppelte Bestellungen auslösen.
MuleSoft kann solche Funktionen über APIs und Integrationsprozesse aus Commerce-, ERP-, PIM-, POS- und Order-Management-Systemen zusammenführen. Der Retail Accelerator zeigt dafür bereits wiederverwendbare Integrationsmuster rund um Produkte, Bestände und Bestellungen. Damit muss für Agentic Commerce keine zweite Integrationslandschaft neben dem bestehenden E-Commerce entstehen.
Ein Einkauf zeigt die gesamte Kette
Nehmen wir wieder den Händler für Outdoor-Ausrüstung. Ein Kunde fragt einen AI-Assistenten nach einem wasserdichten Wanderschuh in Größe 44 für maximal 150 Euro, der bis Freitag nach Graz geliefert werden kann. Aus Sicht des Kunden ist das eine einzige Anfrage, technisch entstehen daraus mehrere Abfragen und Entscheidungen.
Die Produktsuche findet passende Modelle, der Produktkatalog liefert Größen und Eigenschaften, Pricing prüft den gültigen Preis und Inventory bestätigt, welche Varianten tatsächlich verkaufbar sind. Fulfillment beziehungsweise Order Management bestimmt anschließend, welcher Bestand die gewünschte Lieferzusage erfüllen kann. Entscheidet sich der Kunde für ein Produkt, werden Versandoptionen und Gesamtsumme berechnet, die Zahlung autorisiert und die Bestellung angelegt.
Fällt ein Teil dieser Kette aus, kann die Customer Experience zunächst trotzdem überzeugend wirken. Der Agent empfiehlt vielleicht den richtigen Schuh, nennt aber einen veralteten Preis. Oder die richtige Größe wird gefunden, während die versprochene Lieferung aufgrund des Lagerstandorts nicht eingehalten werden kann. Agentic Commerce macht damit besonders sichtbar, dass eine gute AI-Antwort und eine verlässliche Commerce-Transaktion zwei unterschiedliche Qualitätsstufen sind.
Was Unternehmen vor Agentic Commerce prüfen sollten
Bevor Unternehmen Agenten enger mit Produktsuche und Kaufprozessen verbinden, lohnt sich ein Blick auf die bestehende Commerce-Architektur.
-
Sind Produktdaten eindeutig und maschinenlesbar? Varianten, Attribute, Kategorien und Identifikatoren müssen über PIM, Commerce und ERP hinweg zusammenpassen.
-
Welches System liefert Preis und Verfügbarkeit verbindlich? Für transaktionsnahe Informationen sollte klar sein, welches System die autoritative Antwort liefert und wie aktuell diese Information sein muss.
-
Ist wichtige Geschäftslogik bereits wiederverwendbar? Pricing, Availability, Cart und Order sollten möglichst nicht für jeden neuen AI-Kanal separat implementiert werden.
-
Welche Aktionen darf ein Agent tatsächlich auslösen? Eine Produktempfehlung hat andere Auswirkungen als eine Lieferzusage, eine Zahlung oder eine Bestellung. Für verbindliche Aktionen müssen Validierung und Zustimmung klar geregelt sein.
-
Bleibt der Prozess nach dem Checkout verbunden? Eine Bestellung aus einem AI-Kanal sollte in denselben Order-, Fulfillment-, Service- und Retourenprozessen weiterlaufen wie Bestellungen aus bestehenden Kanälen.
Agentic Commerce ist damit weniger eine einzelne neue Funktion als ein zusätzlicher Zugang zu bestehenden Commerce-Prozessen. Je besser Produktdaten, Geschäftslogik und Integrationen bereits über Systeme hinweg organisiert sind, desto leichter lassen sich weitere agentische Kanäle darauf aufbauen.
Was jetzt zählt
Agentic Commerce verändert, wie Kunden Produkte suchen und Käufe starten. Die Verlässlichkeit des Kaufprozesses hängt trotzdem weiterhin davon ab, ob Produktdaten, Pricing, Inventory, Checkout und Order Management im richtigen Moment konsistente Informationen liefern.
Für uns bei Ai11 ist deshalb vor allem die Integrationsarchitektur hinter diesen neuen Commerce-Erlebnissen interessant. Viele Unternehmen haben die notwendigen Systeme bereits im Einsatz. Entscheidend wird, ob deren Daten und Geschäftslogik so verbunden sind, dass auch neue agentische Kanäle zuverlässig darauf zugreifen können.
Agentic Commerce wird damit weniger zu einer Frage der Oberfläche als zu einem Test dafür, wie gut die bestehende Commerce-Landschaft bereits zusammenspielt.