KI Shopping Agent für E-Commerce: Bauplan, Kosten und Chancen

Mit Claude Commerce Agents lässt sich ein KI Shopping Agent aufsetzen, dessen Agentenschleife, Skills, Tool-Schnittstellen, Sicherheitsprüfungen und Oberflächenmuster bereits vorgegeben sind. Das Gerüst steht also. Die eigentliche Arbeit beginnt bei verlässlichen Katalogdaten: Jede Aktion muss dem richtigen Kundenkonto zugeordnet sein, Bestände müssen aktuell bleiben, und vor Zahlungen oder anderen unumkehrbaren Änderungen muss das Modell gestoppt werden.

Dieser Produktionsaufwand lohnt sich, denn der Nutzen ist messbar. Laut Anthropic verzeichnen Händler, die Shopping Agents mit Claude betreiben, bis zu 35% größere Warenkörbe; zugleich steigt die Wahrscheinlichkeit eines Kaufabschlusses um 60%. Das ist kein Versprechen für jeden Shop. Es ist aber ein guter Grund, den Agenten als Conversion-Produkt zu behandeln und nicht als Chat-Widget.

Was Claude Commerce Agents für einen KI Shopping Agent liefert

Claude Commerce Agents ist eine Referenzimplementierung unter Apache-2.0 für zwei Rollen. Der Shopping Agent arbeitet im direkten Kundenkontakt: Er kann Produkte suchen und vergleichen, mehrteilige Einkäufe planen, den Warenkorb befüllen, Fragen zu Richtlinien und Bestellungen beantworten und sich Präferenzen merken. Der Merchant Agent unterstützt den Shop im Hintergrund. Er analysiert die Performance, überwacht Bestände, schlägt Preisänderungen vor und entwirft Kampagnen.

Das Konzept für einen kundenorientierten KI Einkaufsassistenten ist bewusst übersichtlich: Ein Modell durchläuft eine Schleife, allgemeine Regeln stehen im System-Prompt, seltenere Abläufe stecken in fünf Skills, und Tools greifen auf die vorhandenen Commerce-Systeme zu. Das lässt sich mit einer geschulten Verkaufskraft an einem einzigen Beratungstresen vergleichen. Sie behält das gesamte Gespräch im Blick, muss für den Lagerbestand aber das Warenwirtschaftssystem, für die Identität das Kundensystem und für den Warenkorb die Kasse nutzen.

Dieselbe Definition kann über die Messages API, das Claude Agent SDK oder Claude Managed Agents ausgeführt werden. Diese Portabilität ist hilfreich, macht die Beispiele jedoch noch nicht produktionsreif. Anthropic weist ausdrücklich darauf hin, dass die Demos keine Authentifizierung enthalten. Das Repository löst weder Bestellungen aus noch belastet es eine Karte; auch Regeln zu Betrug, Berechtigungen, Bestand und Compliance muss der jeweilige Shop selbst bereitstellen.

Die Wirtschaftlichkeit beginnt nach der Demo

Das Grundgerüst senkt den Aufwand bis zu einem glaubwürdigen ersten Prototyp. Auf der Ankündigungsseite von Anthropic berichtet Wix von einem Prototyp, der nach 15 Minuten Prompts entgegennahm. Laut Fetch liefen beide Referenz-Agenten lokal in deutlich weniger als einer Stunde, und Zomato zufolge können die mitgelieferten Praktiken Teams Wochen an Versuch und Irrtum ersparen. Das sind Berichte von Partnern, keine Liefergarantien. Die Verschiebung im Budget wird trotzdem deutlich: Weniger Entwicklungszeit fließt in ein selbst entworfenes Agentengerüst, mehr in Katalogqualität, Berechtigungen, Evaluationen und den letzten Integrationsschritt bis zum Checkout.

Verglichen mit der Integration können die Modellkosten gering ausfallen. Claude Sonnet 5 kostet $2 pro Million neuer Eingabe-Token, $0.20 pro Million Token bei einem Cache-Treffer und $10 pro Million Ausgabe-Token. Für einen beispielhaften Turn mit 20,000 Eingabe-Token und 800 Ausgabe-Token ergeben sich $0.048, wenn sämtliche Eingabe-Token neu sind. Kommen 18,000 Eingabe-Token aus dem Cache und sind 2,000 neu, kostet dieselbe Rechnung $0.0156. Suche, Hosting, Observability, Support und alle Commerce-APIs rund um das Modell sind darin nicht enthalten.

Nach Angaben von Anthropic erreichen die stärksten Commerce-Implementierungen Cache-Trefferquoten von 90% bis 99%. Deshalb lautet die Budgetfrage im Produktivbetrieb nicht: „Was kostet ein LLM?“ Entscheidend ist vielmehr, jede abgeschlossene Einkaufsaufgabe korrekt, schnell, zurechenbar und sicher zu machen.

So wird der KI Shopping Agent produktionsreif

Die richtige Reihenfolge orientiert sich an Umsatz und Risiko. Am Anfang steht die konkrete Einkaufsaufgabe, danach folgen Daten und Identität, anschließend Aktionsrechte und erst zum Schluss die Geschwindigkeitsoptimierung. Ein elegantes Gespräch über veraltete Bestände bleibt ein kaputter Shop.

1. Eine Einkaufsaufgabe und eine Erfolgskennzahl wählen

„Alle Fragen zu unserem Sortiment beantworten“ ist kein sinnvoller Startpunkt. Besser ist eine klar begrenzte Aufgabe: die passende Matratzengröße finden, ein dreiteiliges Camping-Set innerhalb eines Budgets zusammenstellen oder einen lieferbaren Ersatz für einen vergriffenen Artikel auswählen.

Erfolg sollte als abgeschlossene Aufgabe definiert werden, nicht als freundlich formulierte Antwort. Geeignete Messgrößen sind eine durch Daten belegte Produktauswahl, eine angenommene Empfehlung, das Hinzufügen zum Warenkorb, die Übergabe an den Checkout, die Lösung ohne Support-Ticket und die Retourenquote bei unterstützten Bestellungen. Warenkorbgröße und Kaufabschluss gehören neben Latenz und Modellkosten. Selbst die billigste Antwort wird teuer, wenn sie die falsche Variante empfiehlt.

2. Vorhandene Suche und Rankings hinter das Katalog-Tool legen

Das Modell sollte nicht zur Suchmaschine des Shops werden. Im Muster von Anthropic liefert search_products bereits sortierte Ergebnisse. Claude entscheidet anschließend, welche davon die Anforderungen der Kundschaft erfüllen und wie viele angezeigt werden sollten.

Der Katalog braucht drei Formen: einzelne Produkte, Produktfamilien und tatsächlich kaufbare Varianten. Eine Hemdenfamilie kann Größen- und Farboptionen enthalten, während jede Variante ihren aktuellen Preis und Bestand besitzt. Die Suche darf die Familie zurückgeben; beim Schreiben in den Warenkorb muss dagegen die genaue Variante benannt werden. So kann ein wortgewandter Agent kein „blaues Hemd“ hinzufügen, ohne zu wissen, ob Größe M in Blau verfügbar ist.

Zurückgegeben werden nur Felder, die das Modell für seine Entscheidung benötigt. Produkt-ID, Titel, Preis, Verfügbarkeit, Optionswerte, wichtige Merkmale und der Zeitstempel der Quelle sind meist relevant. Wiederholte Bild-URLs und lange Werbetexte für jedes Ergebnis verbrauchen Kontext, ohne die Entscheidung zu verbessern.

Vorhandene Such- oder Empfehlungsdienste sollten ihre Geschäftslogik behalten. Gibt es keinen solchen Dienst, muss zuerst das Retrieval funktionieren, bevor der Prompt optimiert wird. Ein Katalog-Tool kann weder unvollständige Merkmale und doppelte SKUs noch ein Ranking ausgleichen, das die Anforderungen der Kundschaft ignoriert.

3. Die Identität binden, bevor das Modell ein Tool sieht

Die Authentifizierung gehört in die Host-Anwendung. Dort meldet sich die einkaufende Person an, wird einem Kunden- oder Gast-Prinzipal zugeordnet und erhält eine Sitzung. Backend-Methoden lesen diese Identität aus dem serverseitigen Sitzungsstatus. Weder die Kunden-ID als Tool-Argument noch die Zugangsdaten für den Shop gelangen zum Modell.

Auch Gäste sind vollwertige Identitäten, allerdings mit weniger Rechten. Fragt ein Gast nach der Bestellhistorie oder gespeicherten Adressen, muss das Backend eine Anmeldung verlangen. Nach der Anmeldung sollte eine neue authentifizierte Sitzung beginnen, statt mitten im Gespräch eine anonyme Identität umzuwandeln.

In einer Demo wird diese Trennung leicht übersehen; eine spätere Nachrüstung ist teuer. Sie trennt die Aussage „Der Agent hat das Bestell-Tool aufgerufen“ von der entscheidenden Frage: „Durfte diese authentifizierte Person genau diese Bestellung lesen?“

4. Den Bestand im Moment der Aktion verbindlich prüfen

Suchergebnisse dienen dem Agenten zum Schlussfolgern, doch die Wahrheit liegt im Backend. Bestand, Berechtigung, Preis, Bestelllimits, Annahmeschluss für die Abwicklung und Aktionsregeln müssen innerhalb der Warenkorboperation erneut geprüft werden. Das geschieht atomar, damit ein Bestand nicht unbemerkt zwischen Lesen und Schreiben verschwinden kann.

Ist die gewünschte Variante nicht verfügbar, sollte die Antwort deren ID und gültige Varianten derselben Familie enthalten. Der Agent erklärt den Zielkonflikt und bittet um eine Auswahl. Produkte dürfen nicht stillschweigend ausgetauscht werden. Bei Marktplätzen, kundenspezifischen Preisen, Reisedaten oder filialbezogener Abholung erhält das Backend den Kontext, den es zur Berechnung benötigt.

5. Jedes Tool als API mit Berechtigungen behandeln

Die Referenzimplementierung erstellt die sichtbare Tool-Liste aus der Bereitstellungskonfiguration. Nicht vorhandene Systeme werden deaktiviert, die übrigen Namen auf eine Positivliste gesetzt. Jeden Aufruf außerhalb dieser Liste lehnt der Code ab.

Danach folgen Herkunftsprüfungen. Eine Warenkorbänderung darf nur eine Produkt-ID akzeptieren, die der Server in dieser Sitzung zurückgegeben hat oder die bereits in diesem Warenkorb liegt. Das blockiert erfundene IDs, IDs aus einem anderen Konto und Anweisungen, die in Produktinhalte eingeschleust wurden. Dasselbe Prinzip gilt für Darstellungen: Der Agent kann eine zurückgegebene ID auswählen, die Produktkarte wird jedoch vom Server mit dem eigenen Datensatz befüllt.

Produktangebote, Rezensionen, Richtlinien, Händlernachrichten und gespeicherte Fakten sind nicht vertrauenswürdige Daten. Die Laufzeit von Anthropic bereinigt und kapselt Texte Dritter, bevor Claude sie liest. Prompt-Regeln helfen, doch Berechtigungen, Mengenobergrenzen, geschützte Felder und die Serialisierung von Schreibvorgängen müssen im Code verankert sein.

Wenn die Bereitstellung mehr Kontrolle über Laufzeit oder Gateway erfordert, erläutert der Leitfaden zu Managed-Agent-Tools die Infrastrukturentscheidungen für Agenten mit Tool-Zugriff.

6. Die Befugnisse des Agenten am Checkout beenden

Claude Commerce Agents zieht eine klare Grenze: Das Modell darf den Warenkorb aufbauen und darstellen, aber weder eine Bestellung auslösen noch eine Karte belasten. Das Checkout-Ziel wird erst nach dem Modellaufruf vom Host ergänzt. Die URL gelangt deshalb nie in den Modellkontext.

Für die Übergabe gibt es drei Varianten:

1. Checkout innerhalb der eigenen Anwendung öffnen.
2. Die gehostete Checkout-URL der Commerce-Plattform öffnen.
3. Auf einem Marktplatz je Händler einen eigenen Checkout-Link anzeigen.

Diese Grenze ist gutes Produktdesign, kein fehlendes Feature. So kann die Kundschaft Menge, Adresse, Versand, Rabatte und Gesamtpreis in jenem System prüfen, das Zahlung und Compliance bereits verantwortet.

Für Unklarheiten, die der Agent nicht selbst auffangen sollte, braucht es außerdem eine separate Übergabe an den menschlichen Support. Festgelegt werden müssen die Anliegen, die sie auslösen, die zuständige Warteschlange, die mitgesendete Gesprächszusammenfassung und die Freigaberechte der Supportkraft. „Mit einem Menschen sprechen“ ist ein Workflow mit Identitäts- und Service-Level-Regeln, kein bloßer Ausweichsatz.

7. Commerce-Oberflächen über typisierte Tools darstellen

Produktraster, Vergleichstabellen, Pläne, Warenkörbe und Bestellkarten sollten als typisierte Darstellungs-Tools umgesetzt werden. Claude ruft eine Komponente mit strukturierten Argumenten auf, der Server validiert und ergänzt sie, und der Client rendert das Ergebnis.

Damit wird die sichtbare Oberfläche Teil des Gesprächsverlaufs. Sagt jemand „das zweite“, bleibt die geordnete Produktliste in den Nachrichten erhalten. Zugleich muss das Modell kein fehleranfälliges eigenes Markup erfinden. Der Leitfaden zum Chatbot-Bau behandelt die weitergehenden Oberflächenentscheidungen für die umgebende Gesprächsanwendung.

8. Die Latenz über die gesamte Aufgabe planen

Gemessen wird die Zeit bis zur erledigten Aufgabe: Modell-Turns plus Tool-Laufzeit. Weniger Turns, schnellere Tools und eine schnellere Token-Ausgabe sind gleichermaßen wichtig.

Voraussichtlich benötigter Seitenkontext sollte vor dem ersten Modellaufruf geladen werden. Unabhängige Katalog- oder Richtlinienabfragen können parallel laufen. Jedes Tool wird gestartet, sobald seine Argumente vollständig gestreamt wurden. Produktkarten erscheinen fortlaufend, sobald ihre Felder eintreffen; während einer langsamen Abfrage informiert eine schlichte Statuszeile über den Fortschritt.

Anthropic zufolge umfasst eine gerenderte Commerce-Antwort häufig 500 bis 700 Ausgabe-Token. Ohne progressive Darstellung kann daraus ein leerer Spinner von fünf oder mehr Sekunden werden. Außerdem berichtet Anthropic, dass Eager Dispatch beobachtete Tool-Pausen von mehreren Sekunden auf wenige hundert Millisekunden senken konnte. Diese Optimierungen sollten vor einem Wechsel auf ein kleineres Modell erfolgen. Ein weniger leistungsfähiges Modell kann mehr Turns benötigen und pro abgeschlossener Aufgabe teurer werden.

9. Produktanforderungen in Evaluationen überführen

Eine Evaluation ist ein wiederholbarer Fall, der aus einem bekannten Ausgangszustand das Verhalten des Agenten prüft. Dafür werden relevante Nachrichten, Katalogdatensätze, Warenkorbzustände, Nutzerfakten und Fehler konstruiert; anschließend werden Endzustand und gerenderte Antwort bewertet.

Fünf Gruppen sollten abgedeckt sein: zentrale Einkaufsanfragen, kontextabhängige Turns, Sicherheits- und Markenfälle, Oberflächenverhalten sowie Nachrichten, die zwei Fähigkeiten verbinden. Zu jedem positiven Fall gehört ein negatives Gegenstück. Soll der Agent eine lieferbare Variante empfehlen, muss auch der Fall getestet werden, in dem sämtliche gültigen Varianten vergriffen sind. Weitere Fälle umfassen bösartige Texte in einem Angebot, die Bestell-ID eines anderen Nutzers, Zeitüberschreitungen, leere Suchergebnisse, wiederholtes Hinzufügen zum Warenkorb und Preisänderungen zwischen Suche und Warenkorb.

Anthropic empfiehlt als Ausgangspunkt 50 bis 100 Fälle pro Nutzerablauf. Diese Fälle entstehen gemeinsam mit Produkt-, Rechts-, Kundenservice- und Merchandising-Teams; reale Vorfälle werden anschließend zu dauerhaften Regressionstests. Canary-Releases sollten nur freigegeben werden, wenn faktenbasierte Genauigkeit, Aufgabenerfolg, Sicherheitsquote, p50- und p99-Latenz, Cache-Trefferquote sowie Kosten pro abgeschlossener Aufgabe stimmen.

Sieben Anwendungsfälle für KI im E-Commerce – nach Nutzen geordnet

Am meisten profitieren Shops, in denen Kundinnen und Kunden echte Einschränkungen berücksichtigen müssen und das Sortiment relevante Zielkonflikte enthält. Ein allgemeiner FAQ-Bot ist die schwächste Anwendung dieser Architektur.

1. Produktberatung für erklärungsbedürftige Käufe

Für wen: Shops für Matratzen, Haushaltsgeräte, Outdoor-Ausrüstung oder Elektronik, deren Produkte einen Vergleich erfordern.

Ablauf: Die Kundschaft nennt Ziel, Budget, Maße und Präferenzen. Der Agent fragt sortierte Katalogergebnisse ab, holt Details zu den stärksten Kandidaten, präsentiert einen strukturierten Vergleich, bestätigt die genaue Variante und bereitet den Warenkorb vor.

Warum es sich rechnet: Die Entscheidungshilfe findet direkt während des Kaufs statt. Dieser Anwendungsfall kommt den von Anthropic gemeldeten größeren Warenkörben und höheren Abschlussquoten am nächsten, weil der Agent Unsicherheit beseitigen kann, bevor die Kundschaft abspringt.

2. Bedarfsorientierte Produktpakete

Für wen: Shops mit Produkten, die zusammengehören – etwa Camping-Ausrüstung, Homeoffice-Technik, Hautpflegeroutinen oder eine erste Küchenausstattung.

Ablauf: Der Agent zerlegt ein Ziel in mehrere Produktbedarfe, führt unabhängige Suchen parallel aus, prüft das Gesamtbudget, erklärt Kompromisse und legt freigegebene Varianten in einen gemeinsamen Warenkorb.

Warum es sich rechnet: Der Warenkorb kann wachsen, weil der Agent eine komplette Aufgabe löst, statt lediglich einen weiteren Artikel zu bewerben. Zugleich muss die Kundschaft nicht mehrere Kategorieseiten öffnen und die Kompatibilität eigenständig abgleichen.

3. Varianten- und Passformberatung

Für wen: Händler für Mode, Kosmetik, Möbel und konfigurierbare Produkte mit hohem Retourenrisiko.

Ablauf: Die Kundschaft nennt Anforderungen an Passform, Farbton, Platz oder Kompatibilität. Der Agent liest die Optionen einer Produktfamilie, prüft den Bestand der genauen Variante, zeigt ausschließlich gültige Kombinationen und weigert sich, einen ungeklärten Familiendatensatz in den Warenkorb zu legen.

Warum es sich rechnet: Der Wert liegt in weniger Fehlentscheidungen, nicht in mehr Gespräch. Eine gültige Variante beim Checkout kann vermeidbare Stornierungen und Retouren reduzieren, ohne den Kaufprozess auszubremsen.

4. Produktsuche plus Betreuung nach dem Kauf

Für wen: Shops, deren Support regelmäßig Bestellstatus, Retouren, Garantien und Richtlinienfragen bearbeitet.

Ablauf: Dasselbe Gespräch wechselt von der Produktsuche zu einer angemeldeten Bestellabfrage oder Richtliniensuche. Der Agent liest ausschließlich die Datensätze der jeweiligen Kundschaft, stellt den Status dar und übergibt Ausnahmen mitsamt Kontext an einen Menschen.

Warum es sich rechnet: Eine Oberfläche kann sowohl Conversion als auch fallabschließenden Self-Service unterstützen. Produkt-, Bestell- und Richtlinienkontext müssen nicht gegenüber einem zweiten Bot wiederholt werden.

5. Kontobezogener B2B-Einkaufsassistent

Für wen: Distributoren und Abonnementanbieter mit Vertragspreisen, Berechtigungsregeln oder freigegebenen Sortimenten.

Ablauf: Der Host bindet Konto und Rolle des Einkäufers an die Sitzung. Backend-Tools liefern ausschließlich Preise, zulässige Produkte und Abwicklungsoptionen dieses Kontos. Der Agent erstellt ein Angebot oder eine Übergabe für die Bestellung, statt einen ungeeigneten Verbraucher-Checkout vorzutäuschen.

Warum es sich rechnet: Ein regelintensiver Einkauf wird verkürzt, ohne Berechtigungen zu verwässern. Das Modell erklärt die Auswahl, die Hoheit verbleibt beim Kontosystem.

6. Warenkorbkoordination für Marktplätze

Für wen: Marktplätze, auf denen mehrere Händler dieselbe Anfrage erfüllen können.

Ablauf: Der Verkäufer wird zur Suchdimension. Der Agent vergleicht Angebote und gruppiert Warenkorbpositionen nach Händler; falls erforderlich, zeigt der Host für jeden Händler einen eigenen Checkout-Link.

Warum es sich rechnet: Ein fragmentierter Einkauf wird zu einem einzigen Planungsgespräch, ohne die wirtschaftliche Realität zu verschleiern: Zahlung und Abwicklung liegen bei unterschiedlichen Händlern.

7. Copilot für Händlerbestand und Aktionen

Für wen: Merchandising-Teams, die Umsatz, Bestand, Preise und Kampagnen für zahlreiche SKUs koordinieren.

Ablauf: Der Merchant Agent liest Performance- und Bestandswarnungen, schlägt eine Nachbestellung oder Aktion vor, bereitet die Änderung vor und wartet auf die Genehmigung über eine echte Bedienoberfläche, bevor etwas wirksam wird.

Warum es sich rechnet: Analyse und Vorbereitung werden kürzer, während das bestehende Vier-Augen-Prinzip erhalten bleibt. Die Entscheidungshoheit über Preis, Budget und veröffentlichte Angebote bleibt beim Menschen.

Drei Produkte, deren Entwicklung sich lohnt

1. Ein branchenspezifisches Startpaket für Shopping Agents

Ein produktionsreifes Paket für eine erklärungsbedürftige Kategorie – etwa Outdoor-Ausrüstung, Möbel oder Beauty – lässt sich an Händler verkaufen, denen ein allgemeines Chat-Widget nicht mehr genügt.

Die Preisstaffel ist bereits sichtbar. Brambles listet Tarife für Shopping-Assistenten von $29 bis $499 pro Monat für 10,000 bis 500,000 Sitzungen. Rye verlangt monatlich $149 für Agentic-Commerce-Infrastruktur, zusätzlich $0.02 pro Produktabruf und $0.05 pro ausgelöster Bestellung. Diese Zahlen belegen sowohl die Zahlungsbereitschaft für Händlerabonnements als auch für nutzungsabhängige Infrastruktur.

Die kleinste verkaufbare Version unterstützt eine Commerce-Plattform und eine Kategorie. Sie bildet Familien und Varianten ab, bindet Gast- und angemeldete Sitzungen, implementiert Suche und Produktdetails, erstellt einen Warenkorb, übergibt an den gehosteten Checkout, streamt zwei oder drei typisierte Oberflächenkomponenten und enthält ein kategoriespezifisches Evaluationspaket samt Übergabeweg zum Menschen.

Der Haken ist der Preisdruck. Plattformen und günstige App-Store-Assistenten decken allgemeine Produktfragen bereits ab. Ein belastbarer Wettbewerbsvorteil entsteht erst durch Kategorienlogik, zuverlässige Katalogabbildung, Conversion-Zurechnung und Fälle aus echten Fehlern dieser Branche.

Das ist die stärkste Chance. Sie liegt am nächsten am Händlerumsatz, und das Grundgerüst entfernt genügend allgemeine Vorarbeit, damit sich ein kleines Team auf die kategoriespezifischen Leistungen konzentrieren kann, für die Kunden tatsächlich zahlen.

2. Katalogprüfung und Varianten-QA für Agenten

Ein solcher Dienst prüft, ob ein Katalog Agentenanfragen sicher beantworten kann, bevor ein Shopping Agent mit der Kundschaft interagiert.

Rund um dieses Problem existiert bereits relevante Infrastruktur. Nach Angaben von Channel3 umfasst die Produktschicht 100 Millionen Produkte von 25,000 Händlern und antwortet in weniger als einer Sekunde. Rye verlangt $0.02 pro Produktabruf. Google berechnet für AI Commerce Search $2.50 pro 1,000 Abfragen. Strukturierter, aktueller Abruf ist also bereits ein eigener Budgetposten.

Ein MVP importiert einen Feed, baut Beziehungen zwischen Produktfamilien und Varianten auf, prüft Pflichtmerkmale, vergleicht Preis- und Bestandszeitstempel, führt eine Bibliothek echter Einkaufsanforderungen aus und meldet je SKU fehlende oder widersprüchliche Antworten. Hinzu kommt ein Wiederholungstest: Dieselbe Abfrage darf beim Warenkorb nie ohne einen ausdrücklich vorgesehenen Wiederherstellungspfad eine nicht verfügbare Variante hervorbringen.

Der Haken ist die Anziehungskraft der Plattformen. Shopify und andere Commerce-Plattformen besitzen die maßgeblichen Katalogfeeds und können einfache Prüfungen selbst übernehmen. Das Produkt benötigt deshalb eine plattformübergreifende Normalisierung, eine nach verlorenen Einkaufsaufgaben priorisierte Fehlerliste und den Nachweis, dass Korrekturen falsche Empfehlungen reduzieren.

3. Commerce-spezifische Evaluationen und Release-Gates

Diese Testschicht entscheidet, ob Änderungen an Prompt, Modell, Tool oder Katalog sicher veröffentlicht werden können.

Für die Evaluation von Agenten stehen bereits Budgets bereit. Langfuse gibt an, dass mehr als 50,000 Unternehmen die Plattform nutzen; Produktionstarife kosten $29 beziehungsweise $199 pro Monat, Enterprise beginnt bei $2,499. Anthropic empfiehlt 50 bis 100 Evaluationsfälle für jeden Commerce-Ablauf. Die Lücke ist kein weiterer Trace-Viewer, sondern eine gepflegte Bibliothek aus Commerce-Zuständen, manipulierten Katalog-Fixtures, Warenkorb-Invarianten und Release-Regeln.

Das MVP importiert Transkripte, überführt Vorfälle in Snapshot-Fälle und enthält deterministische Grader für Produktherkunft, Preisbelegung, Variantenauswahl, Mengenobergrenzen, Checkout-Grenzen, Identitätslecks, den Umgang mit Zeitüberschreitungen und die Qualität von Übergaben. Modelle und Prompts sollten anhand von Aufgabenerfolg, p99-Latenz und Kosten pro abgeschlossener Aufgabe verglichen werden.

Der Haken ist der dicht besetzte horizontale Markt. Ein Burggraben kann nur durch Commerce-spezifische Fixtures, zuverlässige Grader, Plattform-Connectoren und Benchmark-Daten entstehen. Reine allgemeine Observability wird kopiert oder gebündelt.

Was Claude Commerce Agents nicht löst

Die nüchterne Einschätzung: Das Grundgerüst löst die Agentenstruktur besser als die Shop-Integration. Es ist ein ernst zu nehmender Ausgangspunkt, aber kein gehostetes Shopping-Produkt.

• Es authentifiziert weder Kundschaft noch Mitarbeitende und vergibt keine Berechtigungen. Dafür sind Host und Gateway zuständig.
• Es repariert weder mangelhafte Katalogdaten und Rankings noch verzögerte Bestände. Die Commerce-Systeme bleiben verantwortlich.
• Es löst keine Bestellungen aus, speichert keine Zahlungsdaten, belastet keine Karten und entscheidet keine Betrugsrichtlinien.
• Es legt weder Regeln für die Übergabe an Menschen noch Service-Warteschlangen oder Genehmigungsrollen fest.
• Es macht die von Anthropic gemeldeten Conversion-Zuwächse nicht auf jeden Katalog übertragbar. Dafür braucht es eigene kontrollierte Messungen.
• Es beseitigt nicht die Datenschutzfragen rund um den Speicher. Für gespeicherte Präferenzen müssen zulässige Datentypen, Aufbewahrung, Zugriff, Berichtigung und Löschung festgelegt werden.

Für einen winzigen Katalog, in dem Filter jeden Kauf mit einem Klick lösen, lohnt sich dieser Bau nicht. Ein Start mit veralteten Preisen und Beständen ist ebenso falsch wie Schreibzugriff allein aufgrund eines vorsichtig klingenden Prompts. Der Agent verdient seinen Platz, wenn ein Gespräch eine wirklich komplexe Einkaufsaufgabe löst und die Systeme aktuelle, berechtigungsgeschützte Fakten liefern können.

Der konkrete Schritt am Montag

In der kommenden Woche wird ein umsatzrelevanter Ablauf ausgewählt. Dafür dienen 50 echte Beispiele aus Website-Suche, Verkaufsgesprächen und Support-Transkripten. Zunächst werden ausschließlich Katalogsuche und Produktdetails angebunden; alle anderen Tools melden Nichtverfügbarkeit. Gemessen wird, ob der Agent durch Daten belegte, lieferbare Varianten auswählt und ob die Kundschaft die Empfehlung annimmt. Warenkorb und Checkout folgen erst, wenn der reine Leseweg seine Fälle besteht. Diese Reihenfolge macht aus Claude Commerce Agents eine kontrolliert veröffentlichte Commerce-Lösung statt einer beeindruckenden Demo.

Wie funktioniert ein KI Shopping Agent?

Ein Claude-Agent hält das Gespräch zusammen und ruft typisierte Tools für Katalogsuche, Produktdetails, Warenkorb, Richtlinien, Bestellungen, Speicher und Darstellung auf. Das Backend authentifiziert die Kundschaft, wendet Preis- und Bestandsregeln an und liefert strukturierte Fakten. Das Modell schlussfolgert auf dieser Grundlage, wird aber nicht selbst zur Quelle der Wahrheit.

Wie binde ich meinen Produktkatalog an?

Das Storefront-Backend des Grundgerüsts wird mit den vorhandenen Such- und Produktdiensten verbunden. Die Suche liefert bereits sortierte Familien, die Produktdetails liefern exakt kaufbare Varianten, und die maßgeblichen Systeme liefern aktuelle Preise und Verfügbarkeit. Zugangsdaten und Kundenidentität bleiben auf dem Server.

Wie funktionieren Nutzerberechtigungen in Sidekick?

Für einen eigenen Shopping- oder Merchant Agent zählt das zugrunde liegende Prinzip, nicht die konkrete Produktimplementierung von Sidekick. Nutzer und Rolle werden vor dem Agenten-Turn aufgelöst, nur zulässige Tools freigegeben, Zugangsdaten serverseitig gehalten und Berechtigungen in jeder Backend-Methode erneut geprüft. Sensible Änderungen durch Händler erfordern außerdem eine echte Genehmigung in der Host-Anwendung.

Kann ich so einen Agenten selbst mit Claude bauen?

Ja. Das Open-Source-Repository enthält ausführbare Beispiele und ein Claude Code Plugin, das ein Grundgerüst für das eigene Backend erzeugen kann. Dennoch bleibt erhebliche Eigenarbeit: Authentifizierung, Katalogabbildung, Live-Bestand, Warenkorb- und Checkout-Integration, Berechtigungen, Übergabe an Menschen, Monitoring und Evaluationen.

Wenn eines dieser Produkte rund um einen konkreten Katalog und dessen Betriebsregeln entstehen soll, bietet die Seite zur Entwicklung von KI-Agenten weitere Informationen.