Claude Commerce Agents: Welchen Agenten sollten Händler zuerst bauen?

Ihr Entwicklungsteam kann jetzt schon vor dem ersten Architektur-Workshop einen funktionierenden Shopping-Agenten und einen Merchant-Agenten klonen. Das erleichtert die Demo. Was Ihr Unternehmen zuerst automatisieren sollte, entscheidet es nicht.

Claude Commerce Agents ist die Open-Source-Blaupause von Anthropic für zwei Arten von Agenten mit Claude: Shopping-Agenten für Kunden und Merchant-Agenten für das eigene Team. Sie enthält Referenzcode, Skills, Tool-Verträge, Sicherheitsgrenzen und Beispiele aus dem Handel. Die eigenen Commerce-Systeme anbinden, Berechtigungen festlegen, das Verhalten testen und entscheiden, wo eine menschliche Freigabe Pflicht bleibt: Das bleibt Aufgabe des Händlers.

Die sinnvolle Frage ist deshalb enger als „Können wir das bauen?“. Sie lautet: Welcher Agent verdient das erste Produktionsbudget, gemessen an dem Engpass, den Ihre Kunden oder Ihr Shop-Team heute schon spüren?

Zuerst: Was steckt in der Blaupause von Claude Commerce Agents?

Die Blaupause enthält zwei funktionierende Referenz-Agenten, gemeinsame Komponenten, Beispiel-Interfaces, Sicherheitsmuster und ein Claude-Code-Plugin, um das Setup anzupassen. Das beschleunigt die ersten Entwicklungsschritte. Ein angebundenes Handelsprodukt ist sie aber nicht. Authentifizierung, Geschäftsregeln, Systemintegrationen, Compliance und die Kontrolle im Live-Betrieb bleiben bei Ihrem Team.

Anthropic hat die Blaupause am 2. September 2026 veröffentlicht. Der Shopping-Agent für Kunden sucht und vergleicht Produkte, stellt Anfragen mit mehreren Artikeln zusammen, merkt sich Vorlieben, füllt einen Warenkorb, übergibt ihn an den Checkout und beantwortet Fragen zu Bestellungen und Richtlinien. Der interne Merchant-Agent analysiert Verkäufe, überwacht den Bestand, empfiehlt Preise oder Aktionen und bereitet Campaigns vor.

Der Unterschied zwischen Blaupause und Produkt ist entscheidend. Eine lauffähige Demo zeigt, dass Agent-Loop, Tools, Skills und Interface zusammenspielen können. Sie zeigt nicht, dass der Agent Ihre Produkttaxonomie versteht, Preise je Markt einhält, das richtige Kundenkonto erkennt oder eine Teilretoure in Ihrem Order-Management-System abwickelt.

Das Open-Source-Repository zieht diese Grenze selbst. Es wird keine echte Bestellung aufgegeben und keine Karte belastet. Änderungen des Merchant-Agenten bleiben vorgemerkt, bis ein Mensch sie freigibt. Außerdem heißt es dort, dass die Referenzimplementierung nicht gepflegt wird und keine Beiträge annimmt. Betrachten Sie sie als architektonischen Ausgangspunkt, dessen Muster Ihnen gehören, nicht als fertige Anwendung, die Sie nur einschalten müssen.

Damit unterscheidet sich die Blaupause auch von der Frage, ob Sie das Shopify AI Toolkit einsetzen sollten. Das eine liefert Entwurfsmuster für Agenten, das andere regelt den kontrollierten Zugriff auf einen Shopify-Shop. Eine Umsetzung im Live-Betrieb kann beides brauchen.

Zuerst den Shopping-Agenten, wenn Kunden nicht finden, was sie suchen

Bauen Sie zuerst den Shopping-Agenten, wenn Kunden ein Anliegen aus mehreren Teilen nur mühsam über Filter, Kategorieseiten und die Shopsuche ausdrücken können. Er hat Vorrang, wenn die kommerzielle Chance in Produktsuche, Vergleich, Bundles oder durchgängigem Service liegt. Der erste Pilot endet beim Warenkorb oder bei der Übergabe an den Checkout, nicht bei einer Zahlung, die der Agent selbst auslöst.

Nehmen Sie einen Händler für technische Outdoor-Ausrüstung. Ein Kunde, der nach „einer Campingausrüstung fürs Wochenende für zwei Erwachsene und zwei Kinder bei Regen“ fragt, sucht nicht nach einer einzelnen SKU. Er bittet den Shop, eine Situation in eine passende Produktauswahl zu übersetzen, mit Blick auf Größe, Wetterfestigkeit, Verfügbarkeit und Budget. Solche Anfragen kann ein Shopping-Agent besser ordnen als eine Folge einzelner Filter.

Laut Anthropic sehen Händler, die Shopping-Agenten mit Claude einsetzen, bis zu 35 % größere Warenkörbe, und Käufer schließen ihren Kauf mit 60 % höherer Wahrscheinlichkeit ab. Die Zahlen sind vielversprechend, aber die Ankündigung nennt weder Stichprobengröße noch Testdesign, Händlermix oder Attributionsmethode. Lesen Sie sie als Richtwert des Anbieters. Legen Sie für Ihren Pilot eine eigene Ausgangsbasis fest: abgeschlossene Produktsuchen, Qualität des Warenkorbs, Korrekturquote, Übergabe an den Checkout und Kundenzufriedenheit.

Ein Shopping-Agent ist der bessere Einstieg, wenn Folgendes zutrifft:

• Kunden kaufen häufig Sets, Bundles, Reiseplanungen oder Produkte, die zueinander passen müssen.

• Ihre Produktattribute sind vollständig genug, um diese Entscheidungen zu stützen.

• Verfügbarkeit und Preise je Markt lassen sich in Echtzeit abfragen.

• Ihr Team kann festlegen, wann der Agent nachfragen muss, statt eine Annahme zu treffen.

• Der Checkout übernimmt bereits die letzte Prüfung und die Zahlungskontrollen.

Der Katalog ist der eigentliche Engpass. Ein Agent kann nicht verlässlich über Wasserdichtigkeit, Gerätekompatibilität, Allergene, Lieferfenster oder B2B-Verpackungseinheiten urteilen, wenn diese Angaben in uneinheitlichen Produkttiteln, PDFs, dem Wissen der Mitarbeitenden und Freitexten verstreut sind. Arbeit an den Produktdaten kann im ersten Sprint deshalb mehr bringen als Arbeit an Prompts.

Zuerst den Merchant-Agenten, wenn der Shop-Betrieb bremst

Bauen Sie zuerst den Merchant-Agenten, wenn Ihr Team täglich Daten zusammensucht, bevor es routinemäßige kaufmännische Entscheidungen treffen kann. Er hat Vorrang, wenn Planer, Merchandiser und Marketer immer wieder von Hand Zahlen zu Verkauf, Bestand, Preisen und Campaigns zusammenführen. Beginnen Sie mit reinen Leseanalysen und vorgemerkten Empfehlungen. Die Freigabe bleibt bei der verantwortlichen Person.

Eine Bestandsbesprechung vor der neuen Saison zeigt das Muster. Die Merchandising-Leitung exportiert den Bestand je SKU, prüft die jüngsten Verkäufe in einem anderen System, geht den Aktionskalender durch und fragt das Marketing, für welche Produkte schon Campaign-Material vorliegt. Die eigentliche Entscheidung erfordert Urteilsvermögen. Ein Großteil der Arbeit davor ist aber Suchen, Abgleichen und Formatieren.

Die Merchant-Blaupause beantwortet Fragen zur Performance, meldet auffällige Bestände, empfiehlt Preise oder Aktionen und entwirft Campaigns. Es geht um denselben operativen Gedanken wie in Flatlines Artikel darüber, was Claude im E-Commerce-Betrieb großer Unternehmen verändert: Das Modell wird nützlich, sobald es das manuelle Übertragen von Informationen zwischen Systemen verringert, während Menschen das kaufmännische Urteil behalten.

Der stärkste erste Workflow hat einen klaren Verantwortlichen, eine wiederkehrende Entscheidung und wenige mögliche Aktionen. „Erstelle wöchentlich eine Liste der Produkte mit niedrigem Bestand, die von den Campaigns des nächsten Monats betroffen sind“ lässt sich leichter steuern als „Optimiere den Bestand“. Für die erste Anweisung lassen sich Datenquellen, Schwellenwerte, Prüfer und erwartetes Ergebnis benennen. Die zweite versteckt zu viele Entscheidungen in einem einzigen Auftrag.

Vergeben Sie im ersten Pilot keine Schreibrechte. Der Referenz-Merchant-Agent von Anthropic merkt Änderungen zur menschlichen Freigabe vor, auch Änderungen an Produktlistings, Bestand, Preisen und Campaigns. So kann Ihr Team die Empfehlung und den daraus folgenden Zustand prüfen, bevor ein Kunde etwas davon mitbekommt. Gleichzeitig entsteht ein nachvollziehbares Protokoll, aus dem Sie lernen, wo der Agent strengere Regeln braucht.

Wählen Sie zuerst den Merchant-Agenten, wenn:

• Teams jede Woche oder in jedem Campaign-Zyklus dieselbe systemübergreifende Analyse wiederholen.

• die Quellsysteme verlässliche Daten zu Verkauf, Bestand, Preisen und Campaigns liefern.

• eine Rolle die finale Entscheidung bereits verantwortet und Empfehlungen prüfen kann.

• sich das erste nützliche Ergebnis liefern lässt, ohne Live-Daten im Shop zu ändern.

• Ihr Team angenommene und abgelehnte Empfehlungen in Testfälle übersetzen kann.

Beide Agenten nur, wenn das Fundament beide trägt

Bauen Sie Shopping- und Merchant-Agent nur dann gemeinsam, wenn beide auf dieselben Definitionen für Produkte, Preise, Bestand, Kunden, Bestellungen und Richtlinien zugreifen. Zwei Agenten mit getrennter Datenlogik können sich widersprechen. Ein gemeinsames Commerce-Fundament gibt beiden dieselben Quellen, Berechtigungen und Regeln, während ihre Aktionen getrennt bleiben.

Beide Oberflächen gleichzeitig zu bauen wirkt effizient, kann aber doppelte Integrationsarbeit verdecken. Der Shopping-Agent liest die Verfügbarkeit vielleicht aus dem Onlineshop, der Merchant-Agent aus dem ERP. Der Kunde sieht einen Artikel als verfügbar, das Operations-Team sieht knappen Bestand, der für Großhandelsaufträge reserviert ist. Das Modell verursacht diesen Konflikt nicht. Die Umsetzung legt eine Definition offen, die im bestehenden Stack nie abgeglichen wurde.

Der Engineering-Leitfaden von Anthropic zu wirksamen Commerce-Agenten empfiehlt einen einzigen Agent-Loop mit Tools und Skills. Spezialisierte Unteragenten sind nur für eng umrissene, in sich geschlossene Aufgaben gedacht. Außerdem verlagert der Leitfaden die Sicherheitsregeln in den Harness, also den Code rund um das Modell, statt darauf zu setzen, dass sich das Modell an eine Richtlinie erinnert. Preisgrenzen, geschützte Felder, Freigabepflichten und die Reihenfolge von Schreibvorgängen gehören also in den Code um den Agenten.

Für Händler auf Shopify heißt es in der Ankündigung, dass Shopify einen Referenz-Shop baut, der Claude über Catalog, Universal Commerce Protocol und Shop sign-in anbindet. Das Repository selbst enthält keine Plattform-Connectoren. An seinen Backend-Schnittstellen bindet Ihr Team die maßgeblichen Systeme für Katalog, Warenkorb, Bestellungen, Analytics, Bestand, Preise und Campaigns an. Der Unterschied zwischen einer Referenzintegration und Ihrem tatsächlichen Stack muss im Projektumfang sichtbar bleiben.

Bevor Sie beide Agenten finanzieren, bringen Sie fünf Grundlagen in Einklang:

Unsicher? Beginnen Sie mit dem kleinsten sinnvollen Pilot ohne Schreibrechte

Die sicherste Standardwahl ist ein eng gefasster Workflow ohne Schreibrechte, der mit echten Daten arbeitet und ein Ergebnis liefert, das jemand bereits braucht. Für einen Merchant-Agenten kann das eine wöchentliche Übersicht zu Bestand und Campaigns sein. Für einen Shopping-Agenten eine geführte Produktsuche, die einen Warenkorb anlegt, Checkout, Zahlung und Kontoänderungen aber nicht berührt.

„Nur lesen“ muss trotzdem nützlich sein. Ein Chatbot, der Produktbeschreibungen wiederholt, beweist wenig. Der Pilot sollte mindestens eine relevante Systemgrenze überschreiten, etwa indem er Produktattribute mit Verfügbarkeit verbindet oder Bestandslagen mit dem Campaign-Kalender verknüpft. Genau dort zeigt sich, ob Daten, Berechtigungen und Tool-Verträge den Workflow tragen.

Gehen Sie bei der Entscheidung so vor:

1. Wählen Sie eine wiederkehrende Entscheidung oder Kundenaufgabe. Benennen Sie die verantwortliche Person und die Systeme, die sie heute nutzt.

2. Legen Sie die Endaktion fest. Der Agent kann Empfehlungen zeigen, einen Warenkorb anlegen oder eine Änderung vormerken. Er sollte nicht mehr Befugnisse haben, als nötig sind, um den Nutzen zu belegen.

3. Listen Sie die Zustände auf, die die Antwort verändern. Dazu gehören, wo relevant, Markt, Kundentyp, Bestandslage, Produkteinschränkungen, laufende Aktionen und Bestellstatus.

4. Bestimmen Sie die Übergaberegel. Halten Sie fest, wann der Agent nachfragt, an einen Menschen übergibt oder abbricht, weil die nötigen Daten fehlen.

5. Erfassen Sie angenommene, korrigierte und abgelehnte Ergebnisse. Machen Sie daraus Testfälle, bevor Sie eine weitere Fähigkeit hinzufügen.

Der kürzeste Weg von der Blaupause in die Produktion

Der kürzeste glaubwürdige Weg in die Produktion: den Workflow eingrenzen, maßgebliche Daten anbinden, Berechtigungen außerhalb des Modells durchsetzen, realistische Zustände testen und erst erweitern, wenn sich die erste Fähigkeit verlässlich verhält. Die Blaupause spart Einrichtungsaufwand. Produktionsreif wird das Ganze erst durch Integrationsdesign, Betriebsregeln, Testsuite und klare Verantwortlichkeiten beim Händler.

Eine praktische Reihenfolge sieht so aus:

1. Grenzen Sie den Use Case ein. Dokumentieren Sie die aktuelle Aufgabe, den Nutzer, den fachlich Verantwortlichen, die Systeme, die Entscheidungshäufigkeit und die Endaktion. Lässt sich die Aufgabe nicht ohne das Wort „optimieren“ beschreiben, grenzen Sie sie weiter ein.

2. Erfassen Sie die maßgeblichen Systeme. Klären Sie, wo Produktdaten, Verfügbarkeit, Kundenidentität, Bestellungen, Preise, Aktionen und Richtlinien liegen. Lösen Sie widersprüchliche Definitionen auf, bevor der Agent zwischen ihnen wählen muss.

3. Bauen Sie nur die nötigsten Tools. Binden Sie nur die Lesezugriffe und vorgemerkten Aktionen an, die der Pilot braucht. Das Repository unterstützt Feature-Schalter, sodass nicht verfügbare Fähigkeiten gar nicht erst in Tools und Prompts des Agenten auftauchen.

4. Setzen Sie die operative Grenze durch. Verankern Sie Authentifizierung, Autorisierung, Zustandsprüfung, Limits und Freigaben in der Anwendungsschicht. Behandeln Sie Texte Dritter, etwa Bewertungen, Listings und Nachrichten von Verkäufern, als nicht vertrauenswürdige Eingaben.

5. Testen Sie Zustände, keine polierten Demos. Prüfen Sie niedrigen Bestand, widersprüchliche Anweisungen, Teilbestellungen, eingeschränkte Produkte, ungewöhnliche Kundenpreise, fehlende Daten und ein langes Gespräch mit früheren Widersprüchen. Bewerten Sie den Endzustand und das Ergebnis, das der Kunde sieht.

6. Messen Sie die gewählte Aufgabe. Beim Shopping-Agenten zählen Aufgabenabschluss, Korrekturquote, Qualität des Warenkorbs, Übergabe an den Checkout und Zufriedenheit. Beim Merchant-Agenten zählen die Zeit bis zu einer prüfbaren Empfehlung, Korrekturquote, Nutzung im Team und die Arten von Urteil, die weiterhin einen Menschen brauchen.

7. Erweitern Sie immer nur eine Befugnisgrenze. Fügen Sie eine weitere Datenquelle, einen Workflow oder eine vorgemerkte Aktion erst hinzu, wenn das Team erklären kann, wie sich die aktuelle Fähigkeit verhält und wer dafür verantwortlich ist.

Das Wichtigste in Kürze

• Wählen Sie erst den Engpass, dann den Agenten. Mühsame Produktsuche spricht für den Shopping-Agenten. Wiederkehrende interne Analysen sprechen für den Merchant-Agenten.

• Behandeln Sie die Blaupause als Referenzarchitektur. Sie liefert funktionierende Muster, aber Live-Integrationen, Authentifizierung, kaufmännische Regeln, Compliance und laufende Wartung bleiben bei Ihrem Team.

• Halten Sie die erste Befugnisgrenze eng. Warenkörbe anlegen, reine Leseanalysen und vorgemerkte Empfehlungen liefern belastbare Erkenntnisse, ohne breite Schreibrechte zu vergeben.

• Klären Sie das Commerce-Fundament, bevor Sie beide bauen. Gemeinsame Definitionen für Produkte, Preise, Bestand, Identität, Bestellungen und Richtlinien verhindern, dass sich die beiden Agenten widersprechen.

• Machen Sie echte Grenzfälle zur Hürde vor dem Livegang. Ein poliertes Gespräch ist eine Demo. Ein getesteter Endzustand, durchgesetzte Berechtigungen und eine benannte Verantwortung im Betrieb machen den Workflow verlässlich.

Nutzen Sie diesen Entscheidungsbaum im ersten Projekt-Workshop. Kann sich das Team nicht auf Engpass, maßgebliche Datenquelle, Endaktion und verantwortliche Person einigen, ist der nächste Schritt nicht, den Agenten auszubauen. Dann klären Sie zuerst das Betriebsmodell.