Claude Commerce Agents: welke agent bouw je als retailer eerst?

Je ontwikkelteam kan nu al vóór de eerste architectuursessie een werkende shopping agent en merchant agent klonen. Dat maakt de demo makkelijker. Welk deel van je winkel je als eerste automatiseert, beslist het niet.

Claude Commerce Agents is de open-source blauwdruk van Anthropic voor twee soorten agents met Claude: shopping agents die klanten helpen en merchant agents voor je eigen team. Je krijgt referentiecode, skills, tool-contracten, veiligheidsgrenzen en voorbeelden uit de retail. Je eigen commercesystemen koppelen, rechten vastleggen, gedrag testen en bepalen waar een mens altijd moet goedkeuren: dat blijft werk voor de retailer zelf.

De nuttige vraag is dus niet “kunnen we dit bouwen?”. Die is smaller: welke agent verdient als eerste productiebudget, gegeven het knelpunt waar je klanten of je winkelteam nu al tegenaan lopen?

Eerst dit: wat zit er in de blauwdruk van Claude Commerce Agents?

De blauwdruk bevat twee werkende referentie-agents, gedeelde componenten, voorbeeldinterfaces, veiligheidspatronen en een Claude Code-plugin om de opzet aan te passen. Daarmee ben je sneller door het eerste ontwikkelwerk. Een gekoppeld retailproduct is het niet. Authenticatie, bedrijfsregels, systeemkoppelingen, compliance en de controle op de live operatie blijven bij je eigen team.

Anthropic bracht de blauwdruk uit op 2 september 2026. De shopping agent voor klanten zoekt en vergelijkt producten, stelt verzoeken met meerdere artikelen samen, onthoudt voorkeuren, vult een winkelwagen, geeft die door aan de checkout en beantwoordt vragen over bestellingen en voorwaarden. De interne merchant agent analyseert verkopen, houdt de voorraad in de gaten, doet voorstellen voor prijzen en acties en bereidt campaigns voor.

Het verschil tussen blauwdruk en product doet ertoe. Een demo die draait, laat zien dat de agent-loop, tools, skills en interface kunnen samenwerken. Hij laat niet zien dat de agent jouw productindeling begrijpt, prijzen per markt respecteert, het juiste klantaccount herkent of een gedeeltelijke retour afhandelt in je orderbeheersysteem.

De open-source repository trekt die grens zelf. Er wordt geen echte bestelling geplaatst en er wordt niets afgeschreven. Wijzigingen van de merchant agent blijven klaarstaan tot iemand ze goedkeurt. De repository vermeldt ook dat de referentie-implementatie niet wordt onderhouden en geen bijdragen accepteert. Zie hem als architectonisch vertrekpunt waarvan jij de patronen beheert, niet als kant-en-klare applicatie die je alleen hoeft aan te zetten.

Dat maakt de blauwdruk ook iets anders dan de vraag of je de Shopify AI Toolkit moet inzetten. Het ene levert ontwerppatronen voor agents, het andere gaat over gecontroleerde toegang tot een Shopify-winkel. Een implementatie in productie kan ze allebei nodig hebben.

Begin met de shopping agent als klanten niet vinden wat ze zoeken

Bouw eerst de shopping agent als klanten een vraag die uit meerdere delen bestaat niet kwijt kunnen in filters, categoriepagina’s en de zoekfunctie. Hij gaat voor als de commerciële kans ligt in producten vinden, vergelijken, bundelen of klanten blijven bedienen na de aankoop. De eerste pilot eindigt bij een winkelwagen of de overdracht naar de checkout, niet bij een betaling die de agent zelf afrondt.

Neem een retailer in technische outdooruitrusting. Een klant die vraagt om “een kampeeruitrusting voor een weekend met twee volwassenen en twee kinderen, en het gaat regenen” zoekt niet naar één SKU. Hij vraagt de winkel om een situatie te vertalen naar producten die bij elkaar passen, met oog voor maat, waterdichtheid, beschikbaarheid en budget. Zo’n verzoek kan een shopping agent beter ordenen dan een reeks losse filters.

Volgens Anthropic zien retailers die Claude shopping agents gebruiken tot 35% grotere winkelwagens, en gaan shoppers 60% vaker over tot aankoop. Dat zijn veelbelovende cijfers, maar de aankondiging vermeldt geen steekproefgrootte, testopzet, mix van retailers of attributiemethode. Lees ze als indicatie van de leverancier. Bouw voor je pilot een eigen nulmeting op: afgeronde zoektochten naar producten, de kwaliteit van de winkelwagen, hoe vaak er gecorrigeerd moet worden, de overdracht naar de checkout en klanttevredenheid.

Een shopping agent is de betere eerste keuze als dit klopt:

• Klanten kopen vaak sets, bundels, reisschema’s of producten die met elkaar compatibel moeten zijn.

• Je productkenmerken zijn volledig genoeg om die keuzes te onderbouwen.

• Beschikbaarheid en prijzen per markt zijn realtime op te vragen.

• Je team kan vastleggen wanneer de agent een verduidelijkende vraag stelt in plaats van iets aan te nemen.

• De checkout regelt de laatste controle en de betaling al.

De catalogus bepaalt hoe ver je komt. Een agent kan niet betrouwbaar redeneren over waterdichtheid, compatibiliteit tussen apparaten, allergenen, levertijden of verpakkingseenheden voor B2B als die gegevens verspreid zitten over inconsistente producttitels, pdf’s, de kennis van medewerkers en vrije teksten. Werk aan productdata kan in de eerste sprint daarom meer opleveren dan werk aan prompts.

Begin met de merchant agent als je winkelteam vastloopt in de operatie

Bouw eerst de merchant agent als je winkelteam elke dag gegevens bij elkaar zoekt voordat het routinematige commerciële beslissingen kan nemen. Hij gaat voor als planners, merchandisers en marketeers steeds weer met de hand cijfers over verkoop, voorraad, prijzen en campaigns combineren. Begin met analyse waarbij de agent alleen leest, en met voorstellen die klaarstaan voor goedkeuring. De beslissing blijft bij de verantwoordelijke medewerker.

Een voorraadoverleg voor het nieuwe seizoen laat het patroon zien. De merchandising lead exporteert de voorraad per SKU, zoekt de recente verkopen op in een ander systeem, loopt de actiekalender na en vraagt marketing voor welke producten er al beeld en tekst voor een campaign klaarliggen. De uiteindelijke beslissing vraagt om oordeel. Het meeste werk daarvoor is opzoeken, gegevens op elkaar laten aansluiten en opmaken.

De merchant-blauwdruk beantwoordt vragen over prestaties, signaleert voorraadproblemen, doet voorstellen voor prijzen en acties en schrijft concepten voor campaigns. Dat bouwt voort op het operationele idee uit het artikel van Flatline over wat Claude verandert aan de eCommerce-operatie van grote organisaties: het model wordt nuttig zodra het minder handwerk betekent bij het overzetten van informatie tussen systemen, terwijl mensen het commerciële oordeel houden.

De sterkste eerste workflow heeft een duidelijke eigenaar, een beslissing die steeds terugkomt en weinig mogelijke acties. “Maak elke week een lijst van producten met weinig voorraad die geraakt worden door de campaigns van volgende maand” is makkelijker te bewaken dan “optimaliseer de voorraad”. Bij de eerste kun je de databronnen, drempels, beoordelaar en verwachte uitkomst benoemen. De tweede verstopt te veel beslissingen in één opdracht.

Geef de agent in de eerste pilot geen schrijfrechten. De referentie-merchant agent van Anthropic zet wijzigingen klaar voor menselijke goedkeuring, ook wijzigingen aan productvermeldingen, voorraad, prijzen en campaigns. Zo kan je team het voorstel beoordelen, en de situatie die het zou opleveren, voordat een klant er iets van merkt. Je bouwt er ook een logboek mee op waaruit je leert waar de agent strakkere regels nodig heeft.

Kies eerst voor de merchant agent als:

• Teams elke week of bij elke campaign dezelfde analyse over meerdere systemen heen herhalen.

• De bronsystemen betrouwbare gegevens over verkoop, voorraad, prijzen en campaigns leveren.

• Eén rol al eigenaar is van de uiteindelijke beslissing en voorstellen kan beoordelen.

• De eerste bruikbare uitkomst te leveren is zonder live winkeldata aan te passen.

• Je team goedgekeurde en afgewezen voorstellen kan omzetten in testcases.

Bouw beide agents pas als de basis ze allebei kan dragen

Bouw een shopping agent en een merchant agent alleen tegelijk als ze dezelfde definities gebruiken voor producten, prijzen, voorraad, klanten, bestellingen en voorwaarden. Twee agents die elk hun eigen datalogica hebben, kunnen elkaar tegenspreken. Een gedeelde commercebasis geeft beide agents dezelfde bronnen, rechten en regels, terwijl hun acties gescheiden blijven.

Beide kanten tegelijk bouwen lijkt efficiënt, maar kan dubbel integratiewerk verbergen. De shopping agent leest de beschikbaarheid misschien uit de webshop, terwijl de merchant agent haar uit het ERP haalt. De klant ziet een artikel als leverbaar, terwijl het operationele team ziet dat die voorraad is gereserveerd voor groothandelsorders. Het model veroorzaakt dat conflict niet. De implementatie legt een definitie bloot die in de bestaande systemen nooit was rechtgetrokken.

De technische gids van Anthropic over effectieve commerce agents raadt één agent-loop aan, ondersteund door tools en skills. Aparte subagents zijn er alleen voor smal, afgebakend werk. De gids legt de veiligheidsregels ook in de code rond het model (de harness), in plaats van erop te vertrouwen dat het model een beleid onthoudt. Prijsgrenzen, beschermde velden, goedkeuringseisen en de volgorde van schrijfacties horen dus in code rond de agent.

Voor retailers op Shopify meldt de aankondiging dat Shopify een referentiewinkel bouwt die Claude koppelt via Catalog, Universal Commerce Protocol en Shop sign-in. De repository zelf bevat geen platformkoppelingen. In de backend-interfaces koppelt je team de systemen die leidend zijn voor catalogus, winkelwagen, bestellingen, analytics, voorraad, prijzen en campaigns. Het verschil tussen een referentie-integratie en je eigen systemen moet zichtbaar blijven in de projectscope.

Breng vijf onderdelen van die basis op één lijn voordat je budget vrijmaakt voor beide agents:

Twijfel je? Begin met de kleinste nuttige pilot waarin de agent alleen leest

De veiligste standaardkeuze is een smalle workflow waarin de agent alleen leest, met echte data, en die iets oplevert wat iemand nu al nodig heeft. Voor een merchant agent kan dat een wekelijks overzicht van voorraad en campaigns zijn. Voor een shopping agent kan het productadvies zijn dat een winkelwagen vult, terwijl checkout, betaling en accountwijzigingen buiten schot blijven.

“Alleen lezen” moet nog steeds iets opleveren. Een chatbot die productteksten herhaalt, bewijst weinig. De pilot moet minstens één betekenisvolle systeemgrens over, bijvoorbeeld door productkenmerken te combineren met beschikbaarheid, of voorraadsituaties te koppelen aan de campaignkalender. Daar leer je of de onderliggende data, rechten en tool-contracten de workflow aankunnen.

Volg deze route om te beslissen:

1. Kies één terugkerende beslissing of klanttaak. Noem de persoon die er eigenaar van is en de systemen die die persoon nu raadpleegt.

2. Leg de eindactie vast. De agent kan voorstellen doen, een winkelwagen vullen of een wijziging klaarzetten. Hij krijgt niet meer bevoegdheid dan nodig is om de waarde te bewijzen.

3. Som de situaties op waarin het antwoord verandert. Denk aan markt, type klant, voorraadpositie, productbeperkingen, lopende acties en orderstatus, waar dat relevant is.

4. Bepaal wanneer de agent overdraagt. Spreek af wanneer de agent om verduidelijking vraagt, doorverwijst naar een medewerker of stopt omdat de benodigde data ontbreekt.

5. Houd bij welke uitkomsten worden goedgekeurd, gecorrigeerd of afgewezen. Maak van die voorbeelden testcases voordat je een nieuwe functie toevoegt.

De kortste route van blauwdruk naar productie

De kortste geloofwaardige route naar productie gaat zo: maak de workflow smal, koppel de leidende databronnen, dwing rechten af buiten het model, test realistische situaties en breid pas uit als de eerste functie zich consequent gedraagt. De blauwdruk scheelt opzetwerk. Klaar voor productie ben je pas door je eigen integratieontwerp, werkregels, testset en duidelijk eigenaarschap.

In de praktijk ziet de volgorde er zo uit:

1. Baken de use case af. Beschrijf de huidige taak, de gebruiker, de verantwoordelijke in de business, de systemen, hoe vaak de beslissing valt en de eindactie. Kun je de taak niet beschrijven zonder het woord “optimaliseren”, maak hem dan nog smaller.

2. Breng de leidende systemen in kaart. Zoek uit waar productdata, beschikbaarheid, klantidentiteit, bestellingen, prijzen, acties en voorwaarden staan. Los tegenstrijdige definities op voordat de agent ertussen moet kiezen.

3. Bouw zo min mogelijk tools. Koppel alleen de leesacties en klaargezette acties die de pilot nodig heeft. De repository ondersteunt feature switches, dus functies die niet beschikbaar zijn, blijven buiten de tools en prompts van de agent.

4. Dwing de operationele grens af. Leg authenticatie, autorisatie, controle van de toestand, limieten en goedkeuringen in de applicatielaag. Behandel tekst van derden, zoals reviews, productvermeldingen en berichten van verkopers, als onbetrouwbare invoer.

5. Test situaties, geen gepolijste demo’s. Probeer het uit met weinig voorraad, tegenstrijdige instructies, gedeeltelijke bestellingen, producten met beperkingen, afwijkende accountprijzen, ontbrekende data en een lang gesprek waarin de klant zichzelf eerder tegensprak. Beoordeel de eindtoestand en wat de klant te zien krijgt.

6. Meet de taak die je hebt gekozen. Kijk bij de shopping agent naar afgeronde taken, hoe vaak er gecorrigeerd wordt, de kwaliteit van de winkelwagen, de overdracht naar de checkout en tevredenheid. Kijk bij de merchant agent naar de tijd tot een voorstel dat beoordeeld kan worden, hoe vaak er gecorrigeerd wordt, of het team ermee werkt en welk soort oordeel nog altijd een mens vraagt.

7. Verleg één bevoegdheidsgrens tegelijk. Voeg pas een nieuwe databron, workflow of klaargezette actie toe als het team kan uitleggen hoe de huidige functie zich gedraagt en wie er eigenaar van is.

Belangrijkste punten

• Kies eerst het knelpunt, dan de agent. Vinden klanten moeilijk wat ze zoeken, dan wijst dat naar de shopping agent. Herhaalt je team steeds dezelfde interne analyse, dan wijst dat naar de merchant agent.

• Zie de blauwdruk als referentiearchitectuur. Hij levert werkende patronen, maar live koppelingen, authenticatie, commerciële regels, compliance en doorlopend onderhoud blijven bij je eigen team.

• Houd de eerste bevoegdheidsgrens smal. Een winkelwagen vullen, analyse waarbij de agent alleen leest en voorstellen die klaarstaan voor goedkeuring leveren bruikbaar bewijs op, zonder brede schrijfrechten.

• Leg de commercebasis vast voordat je allebei bouwt. Gedeelde definities voor producten, prijzen, voorraad, identiteit, bestellingen en voorwaarden voorkomen dat de twee agents elkaar tegenspreken.

• Maak echte randgevallen de toets voor productie. Een gepolijst gesprek is een demo. Een geteste eindtoestand, afgedwongen rechten en een benoemde eigenaar in de operatie maken de workflow betrouwbaar.

Gebruik deze beslisboom in de eerste projectsessie. Kan het team het niet eens worden over het knelpunt, de leidende databron, de eindactie en de verantwoordelijke medewerker, dan is de volgende stap niet de agent uitbreiden. Dan maak je eerst duidelijk hoe de operatie werkt.