Styczeń 2026. Google ogłasza Universal Commerce Protocol razem z Shopify, Walmart, Target, Etsy i Wayfair. Komunikat jest techniczny, ale teza za nim jest radykalna: internet zaczyna przygotowywać się nie tylko na użytkowników, ale na agentów AI którzy będą w nim działać w imieniu tych użytkowników.
UCP to nie jest kolejna wtyczka do sklepu. To propozycja wspólnego języka dla całego ekosystemu agentowego handlu — od momentu gdy agent szuka produktu, przez finalizację transakcji, po obsługę po zakupie. Jeden standard który pozwala każdemu agentowi AI rozmawiać z każdym sklepem bez budowania osobnych integracji.
Żeby zrozumieć dlaczego to ma znaczenie, wystarczy spojrzeć na świat bez UCP.
Problem który UCP rozwiązuje
Przed UCP każda platforma AI chcąca obsługiwać zakupy musiała budować osobne integracje z każdym sklepem. Gemini chciał kupić produkt z WooCommerce — niestandardowa integracja. ChatGPT chciał kupić z Shopify — inna integracja. Copilot, kolejny asystent, kolejna platforma — każdy merchant negocjował osobno, każdy agent uczył się od nowa.
To jest dokładnie ten sam problem który na początku internetu dotyczył płatności — każdy sklep budował własny system — a później logowania — każda platforma wymagała osobnego konta. Za każdym razem rozwiązaniem był wspólny protokół: karty kredytowe, OAuth. UCP jest takim protokołem dla agentycznego handlu.
Cztery role w ekosystemie
UCP wyróżnia cztery role które współpracują przy każdej transakcji.
Platforma to powierzchnia konsumencka na której działa agent — Google AI Mode, Gemini, ChatGPT, Copilot albo dowolny inny asystent AI. Platforma trzyma użytkownika i wykonuje zakup w jego imieniu.
Merchant to sklep który wystawia produkty i realizuje zamówienia. Kluczowe zastrzeżenie które Google wyraźnie podkreśla: merchant zawsze pozostaje Merchant of Record. Transakcja prawnie i operacyjnie nadal należy do sklepu, nie do agenta ani platformy.
Credential Provider zarządza tożsamością kupującego. Przez mechanizm Identity Linking kupujący zalogowany na danej platformie może uzyskiwać te same rabaty lojalnościowe co gdyby był zalogowany bezpośrednio na stronie sklepu — rozwiązuje to problem anonimowych zakupów agentowych który był jedną z głównych bolączek ACP.
Payment Provider obsługuje płatności przez osobny protokół AP2 (Agent Payments Protocol). Architektura płatności w UCP jest otwarta — protokół negocjuje dostępne opcje, nie narzuca konkretnego operatora. Stripe, Google Pay, PayPal, Mastercard Agent Pay — każdy może być obsługiwany tym samym protokołem.
Jak to działa technicznie — profil merchantu i negocjacja możliwości
Każda integracja UCP zaczyna się od jednego pliku — profilu merchantu opublikowanego pod adresem /.well-known/ucp na domenie sklepu. To jest punkt wejścia dla agenta, podobnie jak llms.txt jest punktem wejścia dla modeli językowych.
Zanim cokolwiek się wydarzy agent wysyła zapytanie GET pod ten adres i dostaje z powrotem JSON opisujący co sklep potrafi obsłużyć:
{
"ucp.version": "2026-01-11",
"capabilities": ["checkout", "fulfillment", "discount"],
"payment.handlers": ["google_pay", "stripe", "paypal"]
}Na tej podstawie agent wie czy może przeprowadzić pełny checkout autonomicznie, czy potrzebna będzie asysta użytkownika. Czy sklep obsługuje kody rabatowe, subskrypcje, programy lojalnościowe. Równocześnie agent publikuje własny profil — deklarację swoich możliwości. System porównuje oba profile i negocjuje przecięcie.
Ten mechanizm negocjacji przypomina to co HTTP robi przy każdym żądaniu z nagłówkami Accept i Content-Type — tyle że tutaj negocjowane są zdolności handlowe, nie formaty danych.
Cykl życia transakcji — cztery kroki
Gdy agent wie że sklep obsługuje UCP i że ich możliwości się pokrywają, zaczyna się właściwa ścieżka zakupowa.
Discover — agent przeszukuje katalog produktów w formacie czytelnym maszynowo. Nie parsuje HTML. Otrzymuje ustrukturyzowane dane: identyfikatory produktów, warianty, atrybuty, aktualny stan magazynowy, cenę w czasie rzeczywistym. Każda zmiana w sklepie jest natychmiast widoczna — to kluczowa przewaga nad modelem feedów z ACPgdzie dane mogły być nieaktualne o kilkanaście godzin.
Create — agent tworzy sesję checkout. Formalny początek transakcji. Określany jest produkt, wariant, ilość, adres dostawy i metoda płatności.
Update — sesja może być modyfikowana. Agent może dodać kod rabatowy, wybrać inną opcję dostawy, zaktualizować adres. To też etap na którym sklep może zwrócić dostępne opcje i warunki.
Confirm — finalizacja transakcji. Agent potwierdza zakup, sklep zwraca numer zamówienia i szczegóły realizacji.
Cały ten przepływ odbywa się maszynowo, przez API, bez renderowania UI, bez klikania przez formularze zaprojektowane dla człowieka. To jest właśnie operacyjność — zdolność strony do bycia obsługiwanej przez agenta bez imitowania ludzkich interakcji.
Czym UCP różni się od ACP — dwa modele, dwa zakłady na przyszłość
Różnica między UCP a ACP sprowadza się do jednej fundamentalnej decyzji architektonicznej: skąd agent bierze dane o produktach.
ACP postawiło na feed produktowy — plik CSV lub JSON przesyłany raz dziennie, niski próg wejścia dla merchantów, ale dane które mogą być nieaktualne przy finalizacji transakcji. UCP postawiło na połączenie real-time z endpointem sklepu — wyższa złożoność wdrożenia, ale dane zawsze świeże.
To są dwa różne zakłady na to jak powinien wyglądać agentyczny handel. ACP wybrało prostotę i szybkość wejścia na rynek. UCP wybrało architektoniczną poprawność. Który zakład okaże się trafniejszy — pokaże adopcja w ciągu najbliższych 12-18 miesięcy. Pełne porównanie obu podejść wraz z konsekwencjami dla merchantów znajdziesz w artykule UCP vs ACP na webflux.pl.
UCP jako sygnał większej zmiany
Warto zobaczyć UCP szerzej niż tylko jako standard e-commerce. Jak opisuje artykuł Universal Commerce Protocol to dopiero początek, logika UCP — discovery, wybór wariantów, decyzja, finalizacja działania, obsługa po akcji — nie dotyczy tylko zakupów. Dotyczy każdej sytuacji w której agent ma coś zrobić w imieniu użytkownika: zarezerwować wizytę, umówić termin, złożyć zapytanie.
Google łączy UCP z innymi protokołami agentowymi — A2A, AP2, MCP — co sugeruje budowę większego interoperacyjnego ekosystemu. W tym sensie UCP może być pierwszą dobrze widoczną wersją agentic web — internetu który jest środowiskiem działania agentów, nie tylko surfowania ludzi.
Semantyka w tym kontekście przestaje być tylko warstwą opisową. Jeśli agent ma kupić produkt musi rozumieć czym ten produkt jest, jakie ma warianty, czy jest dostępny, jaka jest polityka dostawy, jakie są warunki zwrotu. Dane strukturalne i JSON-LD przestają być opcją — stają się warunkiem bycia zrozumianym przez agenta który ma działać, nie tylko czytać.
Co to oznacza dla właściciela sklepu
Jeśli prowadzisz sklep na WooCommerce lub Shopify i zastanawiasz się czy UCP wymaga działania teraz — praktyczny przewodnik wdrożeniowy znajdziesz w artykule UCP w WooCommerce — jak działa, jak wdrożyć i na co uważać.
Jedna rzecz jest pewna niezależnie od tempa adopcji UCP: sklepy których strony są dziś czytelne dla agentów, mają dane strukturalne i jasno opisaną ofertę — są lepiej przygotowane na każdy protokół który przyjdzie. UCP wymaga solidnych fundamentów semantycznych. I te fundamenty mają wartość niezależnie od tego który standard wygra.
Pojęcia powiązane w słowniku: ACP, Agentic commerce, MCP, Agent discovery, Dane strukturalne, Operacyjność, Tożsamość agenta
Powiązane artykuły: UCP vs ACP — dwa protokoły agentycznego handlu, Jak agent AI robi zakupy — mechanika UCP, UCP to dopiero początek, UCP w WooCommerce