UCP (Universeel Handelsprotocol)

UCP is een overladen acroniem

Drie letters, meerdere eigenaren. In de telecommunicatie en enterprise IT wordt dezelfde afkorting meestal gelezen als een unified communications platform, en het duikt op in niet-gerelateerde product- en control-plane namen in de hele sector. Iedereen die zoekt op het kale acroniem komt een mix daarvan tegen.

In de handel betekent het het Universeel Handelsprotocol, de open standaard van Google en Shopify waarmee AI-agents catalogi van verkopers kunnen lezen, live prijzen en voorraden kunnen ophalen, winkelwagentjes kunnen beheren en aankopen kunnen voltooien. Dat is degene die hier wordt beschreven.

Het probleem dat het wil oplossen is combinatorisch

Zonder een gedeelde standaard moet elke assistent die transacties wil uitvoeren, integreren met elke retailer waarmee het transacties wil uitvoeren. Dat is een vermenigvuldiging, en vermenigvuldigingen worden snel onbetaalbaar.

Neem een illustratieve markt van 6 assistent-interfaces en 500 retailers die de moeite waard zijn om mee te integreren. Bilaterale integratie betekent 6 × 500 = 3,000 afzonderlijke overeenkomsten en implementaties, waarvan elk door iemand wordt gebouwd en vervolgens onderhouden. Onder één gedeelde standaard implementeert elke partij het één keer: 6 + 500 = 506. Het verschil wordt groter naarmate de markt groeit — bij 10 interfaces en 2,000 retailers is het 20,000 tegen 2,010.

Het gevolg voor een middelgroot merk is het deel dat ertoe doet. Bilaterale integraties worden alleen onderhandeld met de grootste catalogi, omdat daar het rendement de investering rechtvaardigt. Een standaard maakt het werk dat een verkoper één keer doet leesbaar voor elke conforme agent, wat het verschil is tussen deelnemen aan door agents gegenereerde vraag en er structureel van uitgesloten zijn.

Wat een conforme catalogus moet bevatten

De verplichting is minder exotisch dan de formulering doet vermoeden, en het is op te delen in drie dingen die een agent nodig heeft voordat het überhaupt actie kan ondernemen met uw producten.

Alleen het eerste is een data-modelleringsopdracht. Het tweede is een architectuurvraag over waar de voorraad zich bevindt en hoeveel systemen het eens moeten zijn voordat een voorraadnummer waar is, en het is waar implementaties daadwerkelijk falen in plaats van waar ze moeilijk te starten zijn.

• Identiteit. Stabiele product- en variantidentificatoren, idealiter inclusief een GTIN, zodat het artikel dat een agent op de ene plek heeft gevonden, kan worden gekoppeld aan het artikel dat het op een andere plek koopt. Zonder dit vergelijkt de vergelijking stilletjes de verkeerde dingen.
• Waarheid op het moment van lezen. Prijs en beschikbaarheid correct op het moment dat ze worden gelezen, niet op het moment dat een nachtelijke feed werd gegenereerd. Een feed die een paar uur oud is, zal vol vertrouwen voorraad adverteren die vanochtend is verkocht, en een agent die daarop handelt, produceert een annulering in plaats van een bestelling.
• Een winkelwagen die een agent kan aansturen. Programmatische winkelwagenconstructie die een totaal retourneert waarop de agent kan vertrouwen, inclusief verzendkosten en belasting voor de bestemming, want een agent die geen bindend bedrag kan verkrijgen, heeft niets om te vergelijken.

Wat conformiteit u niet oplevert

Twee beweringen worden gekoppeld aan protocolondersteuning die het niet ondersteunt, en beide zijn het waard om te weigeren voordat een project eromheen wordt afgebakend.

Het eerste is zichtbaarheid. Het implementeren van een standaard maakt u leesbaar; het maakt u niet aanbevolen. Welke producten een assistent toont, is een rangschikkingsbeslissing gebaseerd op relevantie, consistente merkinformatie en autoriteit van derden, zoals recensies en berichtgeving. Een conforme catalogus is de voorwaarde om in overweging te worden genomen, niet een reden om gekozen te worden.

Het tweede is veiligheid. UCP beschrijft het lezen van een catalogus en het samenstellen van een winkelwagen. Het bevat geen permissiemodel, geen idempotentievereiste en geen audit trail, en het zegt niets over betalingsautorisatie — dat is het terrein van AP2, en het is de laag die nog in beweging is. Elke interface via welke een agent kan handelen op live systemen heeft scopes, replay-bescherming en een log nodig, ongeacht welk protocol het daar heeft gebracht.

Hoe UCP en ACP zich verhouden

Ze worden meestal gepresenteerd als rivalen en kunnen beter worden gezien als buren die elkaar op één grens ontmoeten. UCP richt zich op catalogusontdekking en winkelwagenconstructie; ACP, van OpenAI en Stripe, richt zich op de uitvoering van de checkout en betalingsdelegatie binnen een assistent. Beide hebben hetzelfde nodig van een verkoper daaronder.

Die gedeelde vereiste is het praktische antwoord op de vraag welke te ondersteunen. Een machineleesbare catalogus met actuele prijzen en beschikbaarheid is door beide vereist, nuttig voor assistenten die geen van beide implementeren, en verbetert tegelijkertijd de klassieke zoekfunctie. Het is het enige deel van deze stack dat geen gok is.

De lagen daarboven zijn gokken, en het bewijs tot nu toe pleit voor geduld. De grootste retailers die in deze ruimte integreren, concentreerden zich op vindbaar zijn in plaats van transacties te kunnen uitvoeren binnen een assistent, en de partij die het best gepositioneerd was om dit te weten, sloot zijn eigen in-chat checkout in 2026.