Agentic commerce
Hoe implementeren verkopers UCP en ACP tegelijkertijd?
Bijgewerkt op
Het is geen of-of-situatie, en het grootste deel van de implementatie wordt gedeeld. Beide vereisen dezelfde basis — een machineleesbare catalogus met productidentiteit, varianten, en prijs en beschikbaarheid die nauwkeurig zijn op het moment van lezen. UCP specificeert vervolgens de ontdekking en het samenstellen van de winkelwagen; ACP specificeert de checkout-sessie en gedelegeerde betaling binnen een AI-interface. Bouw de cataloguslaag één keer, en het resterende protocolspecifieke werk is het transactiepad, wat ook het deel is dat nog in beweging is.
De gedeelde basis is het meeste werk
Gepresenteerd als concurrerende standaarden, lijken ze een dure keuze. Opgebroken in verplichtingen, is de overlap groot en komen de verschillen pas laat.
Beide moeten weten wat je verkoopt, in een vorm die een machine kan parsen zonder een lay-out te interpreteren: productidentiteit, varianten, attributen, een stabiele identificatie, en prijs en beschikbaarheid die kloppen op het moment dat ze worden gelezen. Die vereiste is niet protocolspecifiek, het gaat niet verloren als een van beide standaarden verdwijnt, en het verbetert tegelijkertijd de klassieke zoekfunctie.
| Laag | UCP | ACP | Gedeeld? |
|---|---|---|---|
| Machineleesbare catalogus | Vereist | Vereist | Ja — één keer bouwen |
| Realtime prijs en voorraad | Vereist | Vereist | Ja |
| Productfeed-formaat | UCP-vorm | ACP feed-specificatie | Dezelfde brongegevens, verschillende serialisatie |
| Winkelwagen samenstellen | Gespecificeerd | Gespecificeerd | Grotendeels |
| Checkout-sessie | Winkelwagen-niveau | Volledige sessie-specificatie | Nee |
| Gedelegeerde betaling | Niet de focus | Gespecificeerd | Nee |
De volgorde die werk niet verloren laat gaan
Volgorde op basis van wat overblijft als een protocol het niet redt.
- 1. Eén catalogus als bron van waarheid met nauwkeurige prijs en beschikbaarheid. Dient beide, plus elke assistent die geen van beide implementeert.
- 2. Serialiseer naar elk feed-formaat vanuit die bron. Twee serialiseerders over één dataset is een kleine klus; twee datasets is voor altijd een reconciliatieprobleem.
- 3. Een programmatische offerte en winkelwagen die een bindend totaal inclusief verzending en belasting retourneert. Beide protocollen hebben het nodig en het verwijdert hoe dan ook browsersimulatie.
- 4. Afgebakende, gecontroleerde agent-referenties voordat iets kan schrijven. Geen van beide protocollen specificeert dit en beide gaan ervan uit.
- 5. Checkout en betalingsdelegatie als laatste, omdat dit de laag is die nog in beweging is.
De eis van actualiteit is de ware technische uitdaging
De meeste verkopers kunnen een gestructureerde catalogus produceren. Veel minder kunnen er een produceren waarvan de cijfers kloppen wanneer ze worden gelezen, en dat is waar implementaties van beide protocollen falen.
Een feed die 's nachts wordt ververst, zal vol vertrouwen voorraad adverteren die die ochtend al is verkocht, en een agent die hierop handelt, genereert een annulering in plaats van een bestelling. Voor abonnementsbedrijven is het nog scherper: aankomende verlengingen zijn gereserveerde voorraad, dus een voorraadtelling die hier geen rekening mee houdt, zal eenheden verkopen die al beloofd zijn.
Dit is een echt architectonisch voordeel waarbij voorraad, bestellingen en abonnementen één systeem delen in plaats van te synchroniseren over een integratiegrens — gereserveerde hoeveelheid wordt een eigenschap van de data in plaats van een nachtelijke reconciliatietaak.
Veelgestelde vragen
- Moet ik kiezen tussen UCP en ACP?
- Alleen als je ze ziet als producten om te kopen in plaats van verplichtingen om aan te voldoen. Opgesomd als verplichtingen, is de overlap het grootste deel van de kosten: identiteit, varianten, nauwkeurige prijs en voorraad worden door beide identiek geëist, en alleen het transactiepad verschilt. Een team dat dit definieert als "kies een standaard" eindigt met het plaatsen van de beslissing vóór het werk, terwijl het werk voor de eerste vier stappen hoe dan ook hetzelfde is.
- Welke moet ik eerst implementeren?
- Geen van beide, in de zin die ertoe doet: bouw eerst de cataloguslaag, omdat beide deze vereisen en het nuttig is voor assistenten die geen van beide implementeren. Protocolspecifiek werk moet beginnen bij de feed-serialisatie, wat een kleine taak is zodra de brongegevens correct zijn.
- Is de checkout-laag het al waard om te implementeren?
- Voor de meeste verkopers, nog niet. OpenAI sloot Instant Checkout in 2026 en herpositioneerde ACP richting ontdekking, en grote retailers adopteerden het aan de ontdekkingskant. De partij die het best gepositioneerd was om dit te weten, trok hun eigen in-chat checkout terug; de kosten van het twee keer bouwen van die integratie overtreffen de kosten van het één keer te laat zijn.
- Wat veronderstellen beide protocollen dat je al hebt?
- Afgebakende, gecontroleerde agent-toegang — en geen van beide specificeert het. Per-referentie permissies, idempotentie bij schrijfbewerkingen, een duurzaam audit-spoor en een menselijke poort voor onomkeerbare acties zijn de verantwoordelijkheid van het platform, en zij zijn het verschil tussen een agent-integratie en een incident.
Bronnen
- Agentic commerce standaarden: UCP vs ACP vs AP2 — gids voor verkopers — Digital Applied