UCP od Google dokłada cztery nagłówki do każdej płatności. Trzy istnieją na potrzeby późniejszego sporu

11 stycznia 2026 roku Google opublikowało Universal Commerce Protocol — otwarty standard pozwalający agentom AI kupować, stworzony wspólnie z Shopify i poparty przez ponad 20 partnerów, w tym Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa i Zalando.

Relacje, które potem nastąpiły, dotyczyły zakupów. Agenci przeglądający za ciebie, agenci płacący za ciebie, koniec koszyka i tak dalej.

Potem czyta się specyfikację i okazuje się, że zakupy są w niej rzeczą najmniej ciekawą. To, co UCP standaryzuje z niezwykłą starannością, to nie zakup. To dowód, że zakup przebiegł tak, jak twierdzą obie strony.

W skrócie:

• Każde żądanie UCP zmieniające stan niesie cztery nagłówki, a trzy z nich — request-signature, idempotency-key, request-id — nie robią dla samej transakcji nic. Istnieją po to, żeby później ktoś mógł udowodnić, o co poproszono, że poproszono dokładnie raz, i żeby dało się to odnaleźć.
• Niezaprzeczalność ma tu własną nazwę. W opcjonalnym rozszerzeniu mandatów AP2 (dev.ucp.shopping.ap2_mandate) sprzedawca kryptograficznie podpisuje warunki płatności, a platforma dostarcza kryptograficzne mandaty dowodzące, że użytkownik je autoryzował. Deklarowany w specyfikacji cel: „znacząco ograniczyć ryzyko manipulacji i sporów".
• Liczba popierających to nie liczba wdrożeń. „Ponad 20 globalnych partnerów" to sformułowanie opublikowane przez Google i opisuje ono poparcie. Na moment pisania nie znaleźliśmy żadnego źródła pierwotnego podającego liczbę sprzedawców działających na UCP produkcyjnie.

Zestaw nagłówków pochodzi z samouczka opublikowanego przez Google w dniu premiery. Źródła na końcu.

Czym jest UCP w możliwie najmniejszej liczbie słów, które nadal są prawdą

Zanim przejdziemy do argumentu — fakty, które można sprawdzić. Pochodzą ze specyfikacji opublikowanej na ucp.dev oraz z bloga Google dla programistów; oba pobrane 5 września 2026 roku.

Przy dwóch wierszach tej tabeli warto się zatrzymać, bo większość omówień pomija oba.

Pierwszy to wiersz transportów. UCP nie jest sprawą MCP ani sprawą REST. Te same zadeklarowane dane są udostępniane po REST, MCP, A2A i przez osadzone wiązanie, a wybiera sprzedawca. To celowa odmowa obstawiania, która hydraulika agentowa wygra.

Drugi to wersjonowanie datą. 2026-04-08 nie jest wersją semantyczną, tylko dniem. Specyfikacja tłumaczy to porządkiem chronologicznym i jednoznacznym porównaniem, ale praktyczny skutek jest inny: każda wynegocjowana sesja zapisuje datę reguł, pod którymi się odbyła. To decyzja archiwalna przebrana za decyzję o wersjonowaniu — i nadaje ton całej reszcie dokumentu.

Wąskie gardło, które ma zlikwidować

Ujęcie Google to problem N×N. Każda firma, która chce pojawić się w powierzchni konwersacyjnej, musi zbudować osobne połączenie dla każdej z nich; każda powierzchnia musi osobno wdrożyć każdą firmę; w efekcie nikt niczego nie wypuszcza.

Wpis inżynierski Shopify, opublikowany tego samego dnia przez distinguished engineera Ilyę Grigorika, podchodzi do tego samego problemu od spodu. Po ponad 20 latach, miliardach transakcji i milionach sprzedawców wniosek brzmi: handel odmawia normalizacji. „Opcje i reguły płatności różnią się w zależności od właściwości koszyka, kupującego i rynku; rabaty mają reguły łączenia i kumulacji rywalizujące z kodeksem podatkowym; opcje realizacji zamówienia wybuchają niekontrolowanymi permutacjami". A potem pada zdanie, które warto zachować: „Ta złożoność nie jest błędem, jest własnością emergentną różnorodności detalistów".

Ta jedna linijka wyjaśnia całą architekturę. Jeśli przyjmiemy, że sprzedawcy są nieredukowalnie różni, nie da się ustandaryzować zachowania. Da się ustandaryzować tylko to, jak sprzedawca deklaruje swoje zachowanie, i to, jak agent dowiaduje się, na co właśnie przystał.

Struktura, którą firma publikuje pod /.well-known/ucp. Źródło: specyfikacja UCP 2026-04-08, Overview.

Odkrywanie dzieje się, zanim zacznie się rozmowa

Oto przebieg, tak jak opisują go specyfikacja i samouczek Google. Warto prześledzić go dosłownie, bo to właśnie kolejność jest argumentem.

1. Firma publikuje profil pod /.well-known/ucp. Deklaruje w nim wersję protokołu, jedną lub więcej usług (dev.ucp.shopping), zawarte w nich capability, transporty i punkty końcowe, dostępne procedury obsługi płatności oraz — to okaże się ważne później — swoje publiczne signing_keys.
2. Agent podaje własny profil w każdym żądaniu, przez nagłówek UCP-Agent w składni słownikowej RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Na transporcie MCP ta sama informacja jedzie w obiekcie meta.
3. Firma liczy część wspólną. Ze swoich capability zostawia te, które zadeklarowała także platforma; dla każdej ocalałej wybiera najwyższą wersję obecną w obu tablicach; jeśli wspólnej wersji nie ma, capability wypada w całości.
4. Osierocone rozszerzenia zostają przycięte. Rozszerzenie deklarujące extends: "dev.ucp.shopping.checkout" znika, jeśli checkout nie przetrwał. Przycinanie powtarza się, aż nic więcej nie odpada, co obsługuje łańcuchy przechodnie.
5. Wybiera firma. UCP stosuje architekturę, w której wybiera serwer: o tym, co jest aktywne w sesji, decyduje sprzedawca, a nie agent, i odsyła rejestr aktywnych capability w odpowiedzi.

Nazewnictwo nie jest konwencją, tylko przedmiotem zarządzania. Każda capability zapisywana jest jako {odwrócona-domena}.{usługa}.{capability} — dev.ucp.shopping.checkout dla standardowej, com.example.payments.installments dla własnej sprzedawcy. Detalista może wymyślić capability, której nie ma nikt inny, bez pytania o zgodę i bez kolizji z kimkolwiek, bo to odwrócona domena jest źródłem uprawnień.

Awarie też mają własną taksonomię, a ten podział wiele mówi. Specyfikacja oddziela awarie odkrywania (błędy transportu: invalid_profile_url zwraca 400, profile_unreachable zwraca 424, profile_malformed zwraca 422) od awarii negocjacji, które są wynikiem biznesowym i wracają jako zwykłe 200 z capabilities_incompatible w treści. „Nie mogłem cię dosięgnąć" i „nie mamy nic wspólnego" to różne zdarzenia, a UCP odmawia zlania ich w jedno 400.

Cztery nagłówki jadą na każdym żądaniu zmieniającym stan

Spójrzmy na prawdziwe wywołanie. To własny przykład Google z dnia premiery: utworzenie sesji płatności w przykładowej kwiaciarni.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Cztery nagłówki. Zapytaj, po co jest każdy z nich, a wyłoni się wzór.

Trzy z czterech nie służą transakcji. Służą sporowi o transakcję.

To nie przypadkowy efekt higieny API. Klucze idempotencji i identyfikatory żądań to zwykła dobra praktyka w płatnościach, owszem — ale specyfikacja idzie znacznie dalej, a im dalej idzie, tym wyraźniejszy staje się zamysł.

Niezaprzeczalność to cel projektowy, a nie doklejka zgodności

UCP wymienia cztery mechanizmy uwierzytelniania, które firma może akceptować: klucze API, OAuth 2.0, mTLS oraz podpisy wiadomości HTTP wg RFC 9421. Trzy z nich są zwyczajne. Czwarty robi coś konkretnego.

Przy podpisach wiadomości obie strony publikują klucze publiczne w tablicy signing_keys dokładnie tego samego dokumentu profilu, który deklaruje ich capability. Weryfikator wyciąga keyid z nagłówka Signature-Input, dopasowuje go do kid w opublikowanym zbiorze kluczy podpisującego i sprawdza podpis. Bez współdzielonego sekretu, bez rejestracji, bez konta. Specyfikacja nazywa ten wynik wdrożeniem bez pozwolenia: „każda platforma z odnajdywalnym profilem może wejść w interakcję z dowolną firmą bez uprzedniej rejestracji".

Oczywistą lukę zamyka powiązanie tożsamości. Niezależnie od mechanizmu weryfikatorzy muszą potwierdzić, że uwierzytelniony podmiot rzeczywiście ma prawo działać w imieniu profilu wskazanego w UCP-Agent, i odrzucić żądanie, gdy jedno kłóci się z drugim. Nie da się uwierzytelnić jako ty sam, a potem twierdzić, że jest się cudzym agentem.

A webhooki idące od firmy do platformy muszą być podpisane. Nie „powinny" — muszą. Aktualizacje cyklu życia zamówienia — wysyłka, dostawa, zwroty — to jedyne miejsce w protokole, gdzie wymóg jest bezwzględny, bo to wiadomości docierające już po ruchu pieniędzy, których nikt nie ogląda na bieżąco.

Źródło: specyfikacja UCP 2026-04-08, sekcje Identity & Authentication oraz Transaction Integrity.

A potem jest szczyt drabiny. Dla autonomicznych agentów i transakcji o wysokiej wartości UCP definiuje opcjonalne rozszerzenie dev.ucp.shopping.ap2_mandate. Gdy obie strony je wynegocjują:

• firma dostarcza kryptograficzny podpis na warunkach płatności, a
• platforma dostarcza kryptograficzne mandaty dowodzące zgody użytkownika.

Agent podpisuje obiekty mandatu prywatnym kluczem użytkownika na powierzchni nieagentowej — czyli człowiek autoryzuje na ekranie, który kontroluje, a nie wewnątrz pętli agenta, która zaraz wyda jego pieniądze. Deklarację celu z samej specyfikacji warto zacytować dosłownie, bo to nie jest formułka o bezpieczeństwie: mechanizm „zapewnia silne, kompleksowe gwarancje kryptograficzne co do szczegółów transakcji i zgody uczestników, znacząco ograniczając ryzyko manipulacji i sporów".

I tu jest sedno. Protokół zaprojektowany wyłącznie po to, by agenci robili zakupy, nie potrzebowałby nic z tego. Podpisane warunki po stronie sprzedawcy i podpisane mandaty po stronie użytkownika nie są funkcjami kupowania. Są funkcjami kłócenia się o zakup, sześć tygodni później, przed kimś, kto musi rozstrzygnąć, kto miał rację.

Gdzie narracja wyprzedza dowody

O UCP powtarzane są trzy rzeczy, których źródła pierwotne w tej postaci nie potwierdzają.

„Ponad 20 partnerów" to liczba popierających. Sformułowanie Google mówi, że UCP został „współtworzony i poparty przez ponad 20 partnerów". Poparcie to publiczna deklaracja wsparcia. To nie jest dostarczona integracja, a tym bardziej działający sprzedawca. Szukaliśmy źródła pierwotnego z liczbą sprzedawców realizujących transakcje przez UCP i nie znaleźliśmy.

„Otwarty standard" i „standard Google" są prawdziwe jednocześnie, a napięcie między nimi jest realne. Specyfikacja jest otwarta, repozytorium na GitHubie przyjmuje pull requesty, a konwencja nazewnicza celowo pozwala każdemu zająć własną przestrzeń nazw. Jednocześnie pierwszą implementację referencyjną zbudowało Google, a żeby wziąć udział właśnie w niej, firma potrzebuje aktywnego konta Google Merchant Center z produktami kwalifikującymi się do płatności. Neutralny protokół, pierwsza scena z bramką.

UCP nie usuwa sprzedawcy. To bywa przekręcane wystarczająco często, by powiedzieć wprost: w UCP firma zachowuje własną logikę biznesową i pozostaje Merchant of Record. Embedded Checkout Protocol od Shopify składa to samo zobowiązanie z drugiej strony — gdy w przepływie potrzebny jest człowiek, agent ładuje continue_url, a prawdziwa płatność sprzedawcy renderuje się wewnątrz powierzchni agenta po kanale JSON-RPC 2.0, przy czym transakcję finalizuje sprzedawca. Agent jest powierzchnią, a nie zamiennikiem.

Cztery rzeczy, których nie zdołaliśmy zweryfikować — tak je oznaczamy

Specyfikacja opublikowana na ucp.dev w chwili pobrania nosi wersję 2026-04-08, a jej lista standardowych capability — Cart, Checkout, Identity Linking, Order — różni się od samouczka z 11 stycznia, którego przykłady działają na wersji 2026-01-11 i pokazują checkout, discount oraz fulfillment. Między tymi datami coś doszło. Nie znaleźliśmy pierwotnego dziennika zmian wskazującego kiedy ani datowanych informacji o wydaniu wersji pośrednich, więc raportujemy różnicę, a nie zdarzenie wydania.

Nie znaleźliśmy opublikowanej liczby sprzedawców działających na UCP — ani u Google, ani u Shopify, ani u żadnego z popierających partnerów. Brak liczby nie dowodzi, że liczba jest mała, ale jest powodem, dla którego żadnej nie drukujemy.

Google podaje, że zbudowało pierwszą implementację referencyjną obsługującą zakupy w AI Mode w wyszukiwarce i w aplikacji Gemini. Dostępności, geografii ani skali tego wdrożenia nie zweryfikowaliśmy niezależnie.

Czy UCP stanie się tym standardem handlu agentowego — w chwili pisania nie sposób wiedzieć, a każdy tekst twierdzący inaczej zgaduje. Uczciwa lektura jest węższa: specyfikacja istnieje, jest publiczna, jest niezwykle staranna w kwestii dowodu, a kilka bardzo dużych firm podpisało się pod ogłoszeniem.

Niepodpisana połowa

Odsuńmy się od handlu, bo ciekawa część daje się uogólnić.

UCP opisuje świat, w którym maszyna działa w twoim imieniu, a każdy krok tego działania coś po sobie zostawia: kto poprosił — podpisane; na jakich warunkach — podpisane; ile razy — kluczem; w jakiej kolejności — skorelowane. Sześć tygodni później, gdy obciążenie zostanie zakwestionowane, istnieje artefakt. Nikt nie musi pamiętać.

A teraz pomyśl, skąd naprawdę bierze się upoważnienie do tych działań. Agent kupuje 400 sztuk, bo zapadła decyzja zakupowa. Umowa się przedłuża, bo ktoś zgodził się na warunek. Zakres się zmienia, bo dwoje ludzi omówiło to w czwartek i jedno z nich powiedziało „tak".

Te rozmowy to niepodpisana połowa tego samego przepływu pracy. Połowa maszynowa budowana jest na kryptograficznych potwierdzeniach i na specyfikacji, która traktuje spory jako scenariusz pierwszej klasy. Połowa ludzka to w większości organizacji czyjaś pamięć, odmienna pamięć kogoś innego i streszczenie napisane z obu.

Ta asymetria najpierw się pogorszy, zanim się poprawi, bo połowa maszynowa poprawia się w tempie specyfikacji, a ludzka nie poprawia się wcale. I tryb awarii jest konkretny: rzecz nie w tym, że ludzie kłamią. Rzecz w tym, że artefakt pochodny — streszczenie, protokół, lista zadań — zaczyna być traktowany jako sam zapis w chwili, gdy znika to, z czego został wyprowadzony. Streszczenia są z założenia stratne. Właśnie to czyni je użytecznymi. I właśnie to czyni z nich kiepskie źródło pierwotne: po odrzuceniu oryginału nie ma sposobu, by odróżnić streszczenie stratne od dokładnego.

Autorzy UCP zrozumieli to na poziomie protokołu i zapisali: zachowaj podpisany oryginał, wyprowadzaj z niego, co chcesz, i zadbaj, by wyprowadzenie zawsze dało się zestawić z czymś, co się nie ruszyło. To dyscyplina, nie technologia, i stosuje się do godziny rozmawiających ludzi dokładnie tak samo jak do POST /checkout-sessions.

Sedno sprawy: handel agentowy to standard pokwitowań w kostiumie zakupów

Universal Commerce Protocol opisuje się zwykle jako sposób, w jaki agenci AI kupują rzeczy. Przeczytany od deski do deski, lepiej daje się opisać jako próba odpowiedzi na pytanie, z którym wszystko, co agentowe, będzie się za chwilę mierzyć bez przerwy: gdy maszyna zadziałała za mnie, co dokładnie da się udowodnić o tym, na co przystałem?

Odpowiedź UCP jest dobra: deklaruj swoje capability publicznie, podpisuj warunki, podpisuj zgodę, opatrz ponowienie kluczem, koreluj wywołanie i podpisz webhook, który potem zdaje sprawę z tego, co się stało. To, czy protokół wygra, jest naprawdę otwarte. Pytanie, wokół którego został zbudowany, nie zniknie niezależnie od tego, kto wygra.

Zostaje pytanie, z którym warto posiedzieć. Twoi agenci zaraz będą mieli lepszy zapis tego, na co przystali, niż ty masz zapis tego, na co przystałeś. Dokąd to prowadzi?

---

Gdzie w tym Telli.sh: budujemy tę niepodpisaną połowę. Telli.sh nagrywa rozmowę, rozdziela mówiących, tłumaczy na żywo między 15 językami i przechowuje oryginalne nagranie oraz pełną transkrypcję obok każdego wygenerowanego streszczenia — tak, by artefakt pochodny nigdy nie stał się jedynym artefaktem. Telli.sh nie implementuje UCP i tego nie twierdzi; zajmujemy się drugim końcem tego samego problemu: decyzje autoryzujące zachowanie agentów zapadają najczęściej na głos i nie są nigdzie przechowywane.

Nagraj swoje kolejne spotkanie decyzyjne

Źródła

• Specyfikacja Universal Commerce Protocol, Overview, wersja 2026-04-08 — model usług, capability i rozszerzeń, konwencja nazewnicza, wersjonowanie datą, algorytm części wspólnej capability, kody błędów negocjacji i podpisu, standardowe capability (Cart, Checkout, Identity Linking, Order), transporty, nagłówek UCP-Agent i składnia RFC 8941, mechanizmy uwierzytelniania i wdrożenie bez pozwolenia, odkrywanie kluczy przez signing_keys, powiązanie tożsamości, obowiązkowy podpis webhooków oraz sekcja Transaction Integrity and Non-Repudiation; pobrano 5 września 2026
• Google Developers Blog, „Under the Hood: Universal Commerce Protocol (UCP)", 11 stycznia 2026 — lista partnerów i liczba ponad 20 popierających, zgodność z AP2, A2A i MCP, ujęcie N×N, manifest /.well-known/ucp, pięciokrokowy samouczek i zestaw nagłówków POST /checkout-sessions, Merchant of Record i opcja osadzona, implementacja referencyjna Google w AI Mode i Gemini oraz wymóg Merchant Center; pobrano 5 września 2026
• Shopify Engineering, Ilya Grigorik, „Building the Universal Commerce Protocol", 11 stycznia 2026 — ujęcie „20+ lat, miliardy transakcji, miliony sprzedawców", teza „nie błąd, lecz własność emergentna", cztery zasady projektowe oraz przekazanie sterowania w Embedded Checkout Protocol po JSON-RPC 2.0 przez continue_url; pobrano 5 września 2026
• Agent Payments Protocol (AP2) — protokół płatności, z którym UCP deklaruje zgodność
• Universal Commerce Protocol na GitHubie — otwarte repozytorium wskazane w obu ogłoszeniach
• Nasza lektura GPT-6 Astra i tego, co wciąż rozstrzyga warstwa nagrywania — ten sam argument od strony modelu: jakość rozumowania ma sufit tam, gdzie powstał zapis, o którym się rozumuje