Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
Google Gemini Enterprise für Customer Experience vs. backend-agnostischer Shopping-Agent: der Frontend-Vergleich
Eine kurze Korrektur vorab: Ein Produkt namens "Gemini Enterprise Conversational Commerce" gibt es nicht. Was Google am 11. Januar 2026 auf der NRF angekündigt hat, ist Gemini Enterprise for Customer Experience, eine Plattform, die AI Commerce Search mit vorgefertigten Commerce-Agenten bündelt, darunter ein Shopping-Agent, der Kundinnen und Kunden von der Produktsuche über den Warenkorb bis zum Checkout begleitet. "Conversational Commerce" ist der Branchenbegriff für das, was diese Agenten tun, nicht Googles Produktname. Der Unterschied ist wichtig, weil der tatsächliche Funktionsumfang enger und konkreter ist, als der Sammelbegriff vermuten lässt, und genau deshalb eine eigene Auseinandersetzung verdient.
Was Google tatsächlich veröffentlicht hat
Gemini Enterprise for Customer Experience ist ein Retail- und Service-spezifisches Angebot, aufgesetzt auf der breiteren Gemini-Enterprise-Agentenplattform. Die zwei commerce-relevanten Bausteine sind AI Commerce Search, das konversationelles Filtern, geführte Produktsuche und semantische Suche im Katalog übernimmt, und die Commerce-Agenten, die ein Chat- oder Voice-Frontend direkt mit Backend-Aktionen wie Produktsuche, Rabattlogik und Warenkorbaufbau verbinden. Macy's hat mit "Ask Macy's" laut Googles eigener Ankündigung einen konversationellen Shopping-Assistenten in vier Wochen auf diesem Stack gebaut. Das ist eine reale, ausgelieferte Funktion, und sie verdient eine sachliche Einordnung, weder kleingeredet noch zu etwas aufgeblasen, das sie nicht ist.
Was Googles eigene Unterlagen nicht behaupten, ist Backend-Unabhängigkeit. AI Commerce Search und die Commerce-Agenten sind so gebaut, dass sie im Google-Cloud-Retail-Stack laufen und über Googles Infrastruktur auf euren Produktkatalog zugreifen. Das ist kein Fehler. Es ist schlicht das, wofür das Produkt gemacht ist: ein schneller, gut integrierter Weg zu Conversational Commerce für Teams, die bereits auf Google Cloud als Retail-Daten- und KI-Schicht setzen oder dazu bereit sind.
Eine Cloud, ein Shopping-Agent
Hier ist die Architekturfrage, die sich stellt, bevor man einen Commerce-Agenten von einem Cloud-Anbieter übernimmt, Google oder jedem anderen: Was passiert mit dem Verhalten, dem Gedächtnis und der Konfiguration eures Shopping-Agenten, wenn sich Produktdaten, Rabatt-Engine oder Storefront einmal ändern müssen? Ein Commerce-Agent, der eng an den Retail-KI-Stack einer einzigen Cloud gekoppelt ist, erbt denselben Trade-off, den klassische monolithische Commerce-Plattformen immer mitgebracht haben: starke Integration im Tausch gegen einen einzigen Abhängigkeitspunkt. Liegt euer Katalog in der Retail-Infrastruktur dieser Cloud und liegt die Logik eures Shopping-Agenten ebenfalls dort, bedeutet ein Replatforming der Storefront gleichzeitig ein Neubauprojekt für die Agenten-Schicht, kein Umzug.
Das ist kein Google-spezifisches Problem. Jeder große Cloud-Anbieter, der heute Agentic Commerce baut, von Hyperscaler-Retail-KI-Suiten bis zu plattformspezifischen Shopping-Assistenten, steht vor derselben strukturellen Entscheidung: den Agenten als Teil des eigenen Stacks ausliefern oder als Schicht, die über mehrere Stacks hinweg funktioniert. Die meisten vendor-gebündelten Angebote wählen die erste Variante, weil sie schneller zu bauen und als eine kohärente SKU leichter zu verkaufen ist. Wir behaupten nicht, dass diese Wahl für jedes Team falsch ist. Wir behaupten, dass es eine Wahl ist, und eine, die bewusst getroffen werden sollte, statt sich per Default zu ergeben, nur weil ein Shopping-Agent bereits fertig verdrahtet in eurer bestehenden Infrastruktur mitgeliefert wurde.
Der andere Weg: ein Shopping-Agent unabhängig vom Commerce-Backend
Ein backend-agnostischer Shopping-Agent geht von einer anderen Annahme aus: Agenten-Schicht und Commerce-Backend sind bewusst trennbar. Der Agent liest Produktdaten, Preisregeln und Rabattlogik über eine definierte Schnittstelle, nicht über ein proprietäres Retail-KI-Datenmodell, das nur innerhalb einer Cloud überhaupt Sinn ergibt. Wechselt ihr heute von Shopware zu commercetools, oder fügt ihr in zwei Jahren eine zweite Marke auf einem völlig anderen Backend hinzu, müssen die Gesprächslogik des Shopping-Agenten, seine Warenkorbregeln und seine Brand-Voice-Vorgaben nicht neu gebaut werden. Sie ziehen mit eurer Composable Digital Experience Platform um, nicht mit dem Backend darunter.
Das ist dasselbe Decoupling-Argument, das wir generell für Storefronts machen, nur eine Ebene höher angewandt. Eine Storefront, die nur auf einem Commerce-Backend läuft, war schon vor den Agenten ein bekanntes Risiko. Ein Shopping-Agent, der nur mit dem Retail-Datenmodell einer einzigen Cloud funktioniert, ist dasselbe Risiko, nur schwerer zu erkennen, weil sich der Agent wie ein Feature anfühlt und nicht wie Infrastruktur, bis zu dem Tag, an dem ihr ihn umziehen müsst.
Wo das Frontend entscheidet, welches Modell passt
Am Frontend wird dieser Trade-off konkret statt theoretisch. Wenn die Aktionen eures Shopping-Agenten als Änderungen an Produktkacheln, Filtern, Warenkorbstatus und Checkout-Texten sichtbar werden, dann ist das Frontend die Schicht, die entweder einen konsistenten, backend-unabhängigen Vertrag für diese Aktionen durchsetzt, oder still zur Erweiterung des Retail-Stacks der jeweiligen Cloud wird. Unsere Agentic Frontend Management Platform ist genau auf die erste Option ausgelegt: Ein Shopping- oder Content-Agent arbeitet gegen definierte Komponenten und strukturierte Daten, unabhängig davon, welches Commerce-Backend oder welches Agenten-Framework dahintersteht.
Konkret kann unser Conversion Agent Warenkorb- und Checkout-Flow-Experimente genauso steuern, wie es ein Commerce-Agent tun würde, liest und schreibt dabei aber gegen eure Composability & Orchestration-Schicht statt gegen den proprietären Retail-Index einer einzelnen Cloud. Unser Content Agent erzeugt und variiert Produkttexte innerhalb eurer bestehenden Komponenten-Bibliothek und Brand-Voice-Vorgaben, sodass eine konversationelle Antwort auf "fällt diese Jacke groß aus" konsistent bleibt, egal ob sie über ein Chat-Widget, eine Composable Storefront oder ein Voice-Interface ausgespielt wird, das ihr noch gar nicht gebaut habt. Nichts davon verlangt, dass ihr Google Cloud oder eine andere Cloud verlasst, wenn dort eure Daten bereits liegen. Es verlangt nur, dass die Agenten-Schicht das Backend als ein System behandelt, mit dem sie spricht, nicht als eines, in das sie fest eingegossen ist.
Was wir nicht behaupten
Wir behaupten nicht, dass Googles Commerce-Agenten schlecht gebaut sind oder dass Gemini Enterprise for Customer Experience ein schlechtes Produkt für die Kundschaft ist, für die es gemacht wurde. Ein Händler, der sich voll auf Google Cloud als Retail-Datenplattform festgelegt hat und keinen Backend-Wechsel plant, bekommt einen wirklich schnellen Weg zu einer funktionierenden konversationellen Shopping-Erfahrung, und der Vier-Wochen-Build von Macy's ist dafür ein realer Beleg. Der Trade-off, den wir beschreiben, spielt nur dann eine Rolle, wenn euch Backend-Flexibilität wichtig ist, sei es weil ihr mehrere Marken auf unterschiedlichen Stacks betreibt, weil ihr mitten in einem Replatforming steckt, oder weil ihr schlicht nicht wollt, dass das Schicksal eurer Agenten-Schicht an eine Infrastrukturentscheidung von vor Jahren gekoppelt ist, die aus völlig anderen Gründen getroffen wurde.
Es gibt noch eine weitere Dimension, die in Cloud-gebundenen Commerce-Agenten oft mitläuft: Sichtbarkeit außerhalb des eigenen Chats. Wenn ein KI-Such-Assistent eines Drittanbieters oder eine Shopping-Antwort in einem großen Sprachmodell euer Produkt zitiert, muss die zugrunde liegende Produktseite dafür strukturiert und maschinenlesbar sein, unabhängig davon, welcher Agent gerade fragt. Unser SEO & GEO Agent pflegt genau diese Grundlage, Schema.org-Markup, konsistente Produktdaten, AI-Overview-taugliche Struktur, als Teil derselben Komponenten-Schicht, die auch den Shopping-Agenten bedient. Das ist ein Grund mehr, die Struktur der Produktdaten nicht an eine einzelne Cloud zu binden: Sie muss für mehr als einen Agenten funktionieren, den eigenen und die, die man nicht selbst betreibt.
Drei Fragen vor der Entscheidung
Erstens: Müsstet ihr euer Commerce-Backend im nächsten Jahr wechseln, würde die Gesprächslogik, würden die Warenkorbregeln und Produkttexte eures Shopping-Agenten mitziehen, oder müsstet ihr sie neu bauen? Lautet die ehrliche Antwort "neu bauen", habt ihr eine Abhängigkeit, die ihr vielleicht nicht eingepreist habt.
Zweitens: Liest euer Shopping-Agent Produktdaten über eine Schnittstelle, die ihr kontrolliert, oder über einen proprietären Retail-KI-Index, den nur euer aktueller Cloud-Anbieter abfragen kann? Die zweite Variante ist schneller aufgesetzt und schwerer wieder zu verlassen.
Drittens: Wem gehört der Komponenten-Vertrag, in den die Ausgaben des Agenten rendern? Lautet die Antwort "welcher Cloud-Anbieter auch immer den Agenten betreibt", ist euer Frontend still zur Erweiterung des Stacks dieses Anbieters geworden, nicht zu einer Schicht, die ihr selbst kontrolliert.
Unsere Einordnung
Cloud-Anbieter haben recht damit, dass Conversational Commerce eine schnelle, gut integrierte Agenten-Schicht braucht, und Gemini Enterprise for Customer Experience ist eine glaubwürdige Antwort auf diesen Bedarf für Teams, die um Google Cloud herum gebaut sind. Wo wir anders denken, ist die Frage, was "integriert" per Default bedeuten sollte. Wir glauben, ein Shopping-Agent sollte sich genauso frei bewegen können wie eure Storefront bereits kann, über Shopify, Shopware, commercetools und mehr als 50 weitere Backends hinweg, ohne dass jeder Backend-Wechsel automatisch ein separates Neubauprojekt für die Agenten-Schicht auslöst. Das ist die Wette hinter der Idee, das Frontend als Kontroll-Layer für Agentic Commerce zu behandeln, statt als eine weitere Fläche, auf die zufällig der Agent eines Cloud-Anbieters rendert.
Häufig gestellte Fragen
Gibt es "Gemini Enterprise Conversational Commerce" als echtes Google-Produkt? Unter diesem Namen nicht. Das tatsächliche Produkt heißt Gemini Enterprise for Customer Experience, angekündigt im Januar 2026, mit AI Commerce Search und vorgefertigten Commerce-Agenten wie dem Shopping-Agenten. "Conversational Commerce" beschreibt die Kategorie, nicht eine konkrete Google-SKU.
Bindet Gemini Enterprise for Customer Experience euch an Google Cloud? Googles eigene Dokumentation beschreibt das Produkt als aufgesetzt auf den Google-Cloud-Retail-Stack. Das ist für ein Cloud-Vendor-Produkt nichts Ungewöhnliches, bedeutet aber, dass die Commerce-Agenten so gebaut sind, dass sie mit euren Daten innerhalb dieses Stacks arbeiten, nicht als backend-unabhängige Schicht.
Kann ein backend-agnostischer Shopping-Agent dasselbe wie Googles Commerce-Agenten? Er kann dieselben kundenseitigen Verhaltensweisen abdecken, geführte Produktsuche, Warenkorbaufbau, Checkout-Unterstützung, wenn er gegen einen definierten Komponenten- und Datenvertrag gebaut ist statt gegen den Retail-Index einer einzelnen Cloud. Die funktionale Messlatte ist dieselbe, die architektonische Abhängigkeit ist eine andere.
Raten wir von Gemini Enterprise for Customer Experience ab? Nein. Für ein Team, das sich voll auf Google Cloud festgelegt hat und keinen Backend-Wechsel plant, ist es eine legitime, schnelle Option. Unsere Empfehlung ist, diese Abhängigkeit bewusst zu wählen, nicht als Default zu übernehmen.
Nächste Schritte
Wenn ihr abbilden wollt, wie euer aktueller oder geplanter Shopping-Agent von einem bestimmten Backend oder einer bestimmten Cloud abhängt, bucht ein 30-minütiges Gespräch. Wir gehen gemeinsam durch eure Storefront-Architektur und zeigen, wo eine backend-agnostische Agenten-Schicht euer Abhängigkeitsbild verändern würde, und wo nicht.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich damit, wie Commerce-Teams ihr Frontend und ihre Agenten-Schicht unabhängig von einem einzelnen Backend oder Cloud-Anbieter halten.