Universal Commerce Protocol (UCP) to otwarty standard agentycznego handlu, ogłoszony przez Google w styczniu 2026 roku. Jego założenie jest proste: zamiast budować osobne integracje między każdym agentem AI a każdym sklepem internetowym, UCP wprowadza jeden wspólny język dla całej ścieżki zakupowej — od odnalezienia produktu po finalizację transakcji i obsługę po zakupie. Protokół powstał we współpracy z Shopify, Walmart, Target i innymi, a jako warstwę płatniczą wykorzystuje oddzielny Agent Payments Protocol (AP2). Co ważne — UCP to standard otwarty i nieproprietarny, co odróżnia go od zamkniętych rozwiązań wprowadzonych w tym samym czasie przez Microsoft i OpenAI.

W poprzednim tekście o UCP wspomniane było, czym UCP jest jako sygnał zmiany: że web zaczyna przygotowywać się nie tylko na użytkowników, ale też na agentów AI działających w ich imieniu. Że semantyka przestaje być warstwą opisową, a zaczyna być warstwą operacyjną.

Tym razem schodzimy poziom niżej — żeby pokazać, jak to naprawdę działa od środka.

Nie dlatego, że każdy właściciel sklepu musi znać szczegóły protokołu. Ale dlatego, że zrozumienie mechaniki zmienia sposób myślenia o tym, co teraz ma znaczenie w e-commerce i szerzej — w dostępności dla AI.

Problem, który UCP rozwiązuje

Zanim pojawił się 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 — potrzebna była niestandardowa integracja. ChatGPT chciał kupić z Shopify — inna integracja. Copilot, kolejny asystent, kolejna platforma — każdy merchant budował od nowa, każdy agent negocjował osobno.

To jest dokładnie ten sam problem, który na początku internetu dotyczył płatności, a później logowania. I za każdym razem rozwiązanie było to samo: wspólny protokół.

UCP jest takim protokołem dla agentycznego handlu. Jego cel jest prosty: jeden standard, który pozwala każdemu agentowi AI rozmawiać z każdym sklepem bez niestandardowych integracji. Zamiast dziesiątek osobnych połączeń — jeden wspólny język.

Cztery role w ekosystemie

Żeby zrozumieć UCP, trzeba najpierw zobaczyć, kto w tym ekosystemie w ogóle uczestniczy.

Standard wyróżnia cztery role. Pierwsza to Platforma — czyli powierzchnia konsumencka, na której działa agent. Może to być Google AI Mode w wyszukiwarce, aplikacja Gemini, ChatGPT, Copilot albo dowolny inny asystent AI. To właśnie platforma „trzyma” użytkownika i wykonuje zakup w jego imieniu.

Druga rola to Merchant — 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. To znaczy, że transakcja prawnie i operacyjnie nadal należy do sklepu, nie do agenta ani platformy. Agent jest pośrednikiem, nie podmiotem umowy.

Trzecia rola to Credential Provider — podmiot, który zarządza tożsamością kupującego. Dzięki mechanizmowi 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. To rozwiązanie problemu „agent kupuje anonimowo”.

Czwarta rola to Payment Provider — operator płatności. UCP współpracuje z oddzielnym protokołem AP2 (Agent Payments Protocol), który obsługuje bezpieczne płatności agentyczne. Warto zauważyć, że architektura płatności w UCP jest otwarta — protokół nie narzuca konkretnego operatora, a negocjuje dostępne opcje. Stripe, Google Pay, PayPal, Mastercard Agent Pay — każdy z nich może być obsługiwany przez ten sam protokół.

Profil merchant — gdzie zaczyna się rozmowa

Każda integracja UCP zaczyna się od jednego pliku — profilu merchanty opublikowanego pod adresem /.well-known/ucp na domenie sklepu.

To jest punkt wejścia dla agenta. 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ć. W praktyce wygląda to mniej więcej tak:

{
  "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. Jakie metody płatności są dostępne.

Równocześnie agent publikuje własny profil — deklarację swoich możliwości. System porównuje oba profile i negocjuje przecięcie: które funkcje są wspólnie obsługiwane, które metody płatności pasują do siebie. Dopiero na tej podstawie rozpoczyna się właściwa transakcja.

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 już wie, że sklep obsługuje UCP i że ich możliwości się pokrywają, zaczyna się właściwa ścieżka zakupowa. Składa się z czterech kroków.

Discover — agent przeszukuje katalog produktów sklepu 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 — agent widzi to samo co ludzki kupujący.

Create — agent tworzy sesję checkout. To formalny początek transakcji. W tej sesji określany jest produkt, wariant, ilość, adres dostawy oraz wybrana 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ć status requires_escalation — czyli sygnał, że potrzebna jest decyzja użytkownika. Na przykład gdy mebel wymaga wyboru konkretnego okna czasowego dostawy. W takim przypadku agent przekazuje sterowanie użytkownikowi razem z linkiem kontynuacji (continue_url), a transakcja nie ginie — użytkownik wraca dokładnie tam, gdzie agent skończył.

Complete — agent finalizuje zamówienie. Płatność zostaje przetworzona przez AP2 z kryptograficznym dowodem zgody użytkownika. Sklep tworzy zamówienie dokładnie tak samo jak przy zwykłym zakupie — ta sama logika podatkowa, te same reguły wysyłki, ten sam system fulfillmentu.

Po zakupie możliwa jest też interakcja z cyklem życia zamówienia: agent może sprawdzać status, śledzić dostawę, inicjować zwrot — wszystko przez te same ustrukturyzowane endpointy.

Ekosystem protokołów: UCP nie działa w izolacji

UCP nie jest samodzielną wyspą. Celowo został zaprojektowany jako część większego ekosystemu protokołów agentycznych, z którymi współpracuje.

MCP (Model Context Protocol) to protokół opracowany pierwotnie przez Anthropic, który definiuje sposób, w jaki modele AI korzystają z zewnętrznych narzędzi i źródeł danych. W kontekście UCP, MCP działa jako warstwa transportowa — jeden ze sposobów, w jaki agent może wywoływać endpointy sklepu. Zamiast czystego REST, agent może korzystać z MCP jako interfejsu do tych samych operacji.

A2A (Agent2Agent Protocol) to protokół komunikacji między agentami. W bardziej zaawansowanych scenariuszach zakupowych — na przykład gdy zakup wymaga koordynacji między agentami obsługującymi różne aspekty transakcji — A2A zapewnia standardowy sposób tej komunikacji.

AP2 (Agent Payments Protocol) to warstwa odpowiedzialna za bezpieczeństwo płatności agentycznych. Kluczowe założenie AP2 to kryptograficzny dowód zgody użytkownika na każdą transakcję. Agent nie może wydać pieniędzy użytkownika bez weryfikowalnego śladu autoryzacji. To odpowiedź na oczywiste pytanie: skąd merchant wie, że zakup jest autoryzowany?

Razem te protokoły tworzą to, co Google i Shopify opisują jako interoperacyjny ekosystem agentów — gdzie różne platformy, modele AI i sklepy mogą ze sobą współpracować bez bilateralnych umów i niestandardowych integracji.

Otwarty standard kontra zamknięte systemy

To jest być może najważniejsza decyzja architektoniczna w całej historii UCP.

W tym samym czasie, gdy Google i Shopify ogłosiły UCP jako otwarty standard, Microsoft uruchomił Copilot Checkout w partnerstwie z Shopify. OpenAI wprowadziło „Buy it in ChatGPT” kilka miesięcy wcześniej. Oba rozwiązania działają — ale są zamknięte i proprietary.

Różnica jest fundamentalna. Zamknięty system oznacza, że merchant integruje się z jednym agentem na raz. Jeśli chce sprzedawać przez Gemini, buduje integrację z Gemini. Jeśli chce sprzedawać przez ChatGPT, buduje osobno. Każdy nowy asystent AI to osobna integracja, osobna umowa, osobna dokumentacja.

UCP odwraca tę logikę. Merchant integruje się raz — z protokołem. Każdy agent, który protokół obsługuje, może od razu pracować ze sklepem. Jak ujął to Shopify w swojej dokumentacji: agenci i merchantzi deklarują swoje możliwości, a protokół negocjuje resztę. Bez spotkań integracyjnych.

Dla merchantów to oznacza jedno podłączenie do całego ekosystemu AI. Dla deweloperów agentów to oznacza, że nie muszą uczyć się każdego API z osobna. Dla całego rynku to oznacza, że żadna platforma nie ma monopolu na agentyczny handel.

To jest ta sama logika, która stała za HTTP, SSL czy OAuth. Otwarte standardy wygrywają, bo wszystkim opłaca się do nich dołączyć.

Co to oznacza dla myślenia o AI i e-commerce

Mechanika UCP pokazuje coś, co w ogólnych dyskusjach o AI często gubi się za mgłą abstrakcji.

Agent AI nie jest inteligentnym przeglądarką. Nie „czyta strony” tak jak człowiek i nie wyciąga sensu z layoutu. Żeby kupić produkt, potrzebuje danych w formacie, który może przetworzyć deterministycznie: ceny, stanu magazynowego, wariantów, polityki zwrotów, opcji wysyłki. W formie, która pozwala podjąć decyzję i wykonać akcję.

UCP to protokół, który sprawia, że sklep staje się dla agenta środowiskiem operowalnym, a nie tylko stroną do oglądania. I w tym sensie jest jednym z pierwszych konkretnych sygnałów, jak będzie wyglądał web w świecie, gdzie obok użytkowników działają agenci.

Jak wdrożyć UCP w sklepie WooCommerce — o tym w osobnym tekście w dziale Tworzenie stron.