Co widzi agent AI, kiedy przychodzi kupić w Twoim sklepie

Agent AI, który przychodzi kupić w Twoim sklepie, dostaje dziś zwykle tyle: nazwę produktu, jedną kwotę, słowo o dostępności i zdjęcie. Do domknięcia zamówienia brakuje mu czterech rzeczy: stabilnego identyfikatora, ceny z walutą i statusem podatku, dostępności ze znacznikiem czasu oraz jawnych kosztów dostawy i zasad zwrotu. Ten tekst pokazuje, jak spojrzeć na własny produkt tak, jak widzi go maszyna, pole po polu, i jaką decyzję o standardzie musisz przy okazji podjąć sam. Zakładam, że wiesz już, na czym polega zakup przez agenta; jeśli nie, zacznij od wpisu o tym, jak przygotować sklep pod agentów.

Wejście: rekord zamiast strony produktu

Otwórz kartę swojego najlepiej sprzedającego się produktu i zasłoń wszystko poza tekstem. Zdjęcia, układ, opinie, baner z rabatem, przycisk zakupu: dla agenta żadna z tych rzeczy nie jest wejściem. Wejściem jest zbiór par klucz-wartość, który dostał z feedu, z danych strukturalnych albo z API, plus to, co uda się wyskrobać z HTML. Jeżeli w tym zbiorze cena widnieje jako „od 149", jednostka nie występuje wcale, a dostępność brzmi „ostatnie sztuki", agent ma opis nastroju, nie parametry transakcji.

Sprawdź to na sobie, zamiast wierzyć mi na słowo.

Pole po polu: gdzie pęka zakup, gdy czegoś brakuje

Poniżej siedem pól w kolejności, w jakiej stają się potrzebne w trakcie zakupu. Przy każdym: co agent z nim robi i co przestaje być możliwe, kiedy pola nie ma. Przejdź tabelę z jednym realnym produktem otwartym obok, najlepiej takim, który ma warianty i minimum logistyczne.

Kolejność pól odpowiada czterem krokom, które Shopify opisuje dla agentów: negocjacja i uwierzytelnienie, wyszukanie produktów, budowa koszyka i przejście do checkoutu, monitorowanie zamówienia (shopify.dev/docs/agents, sprawdzone 19.08.2026). Sama lista pól jest naszą listą operacyjną, a nie wymaganiem któregoś z protokołów.

Dwa wiersze z tej tabeli wyglądają na drobiazg, a rozstrzygają najwięcej. Jednostka i wielokrotność decydują o tym, czy zamówienie z agenta wpada do normalnego procesu, czy do kolejki wyjątków, którą ktoś w firmie musi przeklikać ręcznie. Zasady zwrotu decydują o czymś jeszcze mniej widocznym: agent, który dostał od klienta warunek, odrzuca oferty, w których nie potrafi go potwierdzić. Milczenie w danych jest odpowiedzią przeczącą, choćby Twoja polityka zwrotów była hojniejsza od konkurencji. Jak zapisać część tych faktów w schema.org, rozkładamy w tekście o danych strukturalnych pod AI.

Trzy ciche porażki, groźniejsze niż puste pole

Brak pola widać od razu. Trzy sytuacje poniżej nie zgłaszają się w żadnym raporcie, bo dane formalnie są, tylko kłamią.

Feed mówi jedno, strona drugie

Agent rzadko czyta jedno źródło. Cenę bierze z feedu pobranego w nocy, atrybuty z danych strukturalnych, koszt dostawy z API, a resztę z HTML. Gdy te źródła się rozjeżdżają, nie widzi konfliktu, bo nie ma powodu podejrzewać samego siebie. Wybiera po prostu wartość, którą dostał wcześniej, i przedstawia ją klientowi jako Twoją ofertę. Rozjazd wychodzi na wierzch dopiero przy płatności, w najgorszym możliwym momencie, i wygląda dla klienta jak Twój błąd, ponieważ nim jest.

Metoda pomiaru, którą możesz uruchomić dziś: weź 200 losowych SKU, pobierz dla nich cenę, dostępność, jednostkę i koszt dostawy równolegle z feedu i ze strony, potem policz, w ilu wierszach cztery pola zgadzają się w obu źródłach. Odsetek zgodnych wierszy jest Twoim realnym sufitem zamówień, które agent domknie bez niespodzianki. Nie znam publicznego benchmarku dla tej miary i nie będę udawał, że znam; wartość liczy się tu we własnym szeregu czasowym, mierzona raz w miesiącu.

Stan magazynu z wczorajszego wieczoru

Dostępność starzeje się szybciej niż każde inne pole w katalogu. Feed odświeżany raz na dobę oznacza, że w godzinach szczytu agent podejmuje decyzję na danych sprzed kilkunastu godzin, a przy produktach z krótkim stanem to różnica między sprzedażą a anulowaniem. Sprawdź dwie rzeczy: co ile minut aktualizuje się stan w źródle, z którego czytają agenci, oraz czy checkout weryfikuje stan ponownie w momencie składania zamówienia.

Jeżeli druga odpowiedź brzmi „nie", pierwsza przestaje mieć znaczenie.

Cena, która istnieje tylko w kontekście

Tu robi się najciekawiej, bo najczęściej dotyczy sklepów dobrze prowadzonych. Cena kontraktowa widoczna po zalogowaniu, rabat naliczany na poziomie koszyka, próg darmowej dostawy, promocja pakietowa, stawka podatku zależna od kraju dostawy: agent działający bez sesji klienta nie ma żadnego z tych kontekstów.

Widzi cenę katalogową i tylko na niej opiera porównanie. W sprzedaży B2B skutek bywa odwrotny do zamierzonego, bo Twoja realna oferta dla stałego klienta jest lepsza od tej, którą agent pokazał, i przegrywasz porównanie własną ceną półkową. Da się to naprawić, wystawiając cennik dostępny po uwierzytelnieniu agenta, ale wymaga to decyzji, kto tym agentem właściwie jest.

Wojna protokołów z miejsca sprzedawcy, nie dostawcy standardu

Trwa spór o to, jak agent rozmawia ze sklepem, i po dwóch stronach stoją firmy z różnymi interesami. Poniżej to, co udało mi się potwierdzić u źródła 19 sierpnia 2026, bez liczb o adopcji, bo nikt ich publicznie nie podaje.

Źródła kolumn 2-4: agenticcommerce.dev, developers.google.com/merchant/ucp z wpisem developers.googleblog.com o UCP oraz shopify.dev/docs/agents. Wszystkie sprawdzone 19.08.2026. Nazw poziomów zaufania Shopify nie podaję, bo dokumentacja, którą czytałem, ich nie wymienia.

Jedna różnica warta uwagi przy czytaniu obu specyfikacji: ACP nazywa swoją licencję wprost, a na sprawdzonych przeze mnie stronach UCP licencja nie jest wymieniona, jest tylko określenie „otwarty standard" i zaproszenie do współtworzenia. Dla działu prawnego to istotna różnica. Druga rzecz, którą widać przy zestawieniu obok siebie: ACP koncentruje się na warstwie transakcyjnej i celowo nie standaryzuje danych produktowych, a UCP wprost sięga po feed, który już masz w Merchant Center. Wniosek dla Ciebie jest wygodny: część roboty jest wspólna dla obu, a różni się dopiero adapter checkoutu.

Część tej decyzji podejmuje za Ciebie platforma

Uczciwie: swobodę wyboru masz mniejszą, niż sugeruje słowo „decyzja". Jeżeli stoisz na zamkniętym SaaS, protokół wybiera Twój dostawca, a Ty dowiadujesz się o tym z changelogu. Shopify udokumentował przepływ agentowy na fundamencie UCP i to jest gotowa odpowiedź dla każdego sklepu na Shopify, niezależnie od tego, czy sprzedawca ją lubi. Poziom zaufania, od którego zależy, czy agent tylko przegląda, czy domyka checkout, przypisuje platforma agentowi, nie sprzedawca. Twoja realna dźwignia leży w warstwie niżej: w jakości danych, które platforma wystawi na zewnątrz, i w tym, czy Twój cennik oraz stan są policzalne przez API.

Rachunek jest tu prostszy, niż wygląda. Wybór platformy okazuje się wyborem protokołu, więc decyzję o platformie warto podejmować z tym pytaniem na liście, zamiast dokładać je rok później.

Niezależne od standardu, więc do zrobienia najpierw

Trzy rzeczy poniżej pracują w ACP, w UCP i w każdym kolejnym protokole, który wygra. Robisz je raz i przestają być decyzją strategiczną, a stają się porządkiem, na którym można potem postawić dowolny adapter.

• Jeden rekord na produkt. Identyfikator, jednostka, wielokrotność i atrybuty wariantu żyją w jednym miejscu, a feedy, strona i API czytają z niego, zamiast utrzymywać własne kopie z własnym cyklem życia.
• Jedno źródło prawdy o cenie i stanie. Kwota w feedzie, kwota na stronie i kwota w koszyku pochodzą z tego samego zapytania. Wtedy klient, agent i Twój magazyn widzą tę samą liczbę o tej samej godzinie.
• Zasady zwrotu zapisane jako dane. Okno w dniach, kto płaci za przesyłkę, wyjątki per kategoria. Regulamin w PDF obsługuje spór prawny, a pole obsługuje warunek postawiony przez klienta w rozmowie z agentem.

Najtańsze miejsce na te trzy rzeczy jest w warstwie, która i tak generuje Twoje feedy, dlatego automatyzację feedów traktujemy jako pracę o jeden poziom głębszą niż mapowanie kolumn pod kanał. W Seedlight budujemy platformy frameworkiem BEAM, w którym te dane mają jedno miejsce, a utrzymanie ich świeżości należy do etapu Maintenance and Growth.

Przy małym katalogu i sprzedaży przez marketplace decyzja nie należy do Ciebie

Sekcja dla tych, którym ten tekst nie powinien narobić pracy. Jeżeli masz kilkadziesiąt produktów bez wariantów, jedną stawkę podatku, jeden kraj dostawy i sprzedajesz wyłącznie przez Amazon, Allegro albo Kaufland, to dane produktowe i tak żyją w standardzie narzuconym przez marketplace, a checkout obsługuje operator platformy. Decyzję o protokole podejmuje wtedy on, nie Ty, i najlepszą inwestycją zostaje jakość samych ofert.

Jeżeli masz i sklep, i kanały, sprawdź najpierw, czy Twój feed marketplace i strona sklepu podają dziś tę samą cenę oraz ten sam stan, bo ten test kosztuje godzinę, a rozstrzyga, czy w ogóle warto rozmawiać o protokołach.

Próg, przy którym to przestaje być teoria, jest dość konkretny: sprzedaż bezpośrednia z Twojego sklepu na tyle istotna, że anulowane zamówienie boli, plus warianty, minima logistyczne albo ceny kontraktowe w grze. Wtedy warstwa danych staje się warstwą sprzedaży, a nie zapleczem marketingowym.

Diagnoza zajmuje jedno popołudnie

Kolejność, którą polecam: pobierz feed i stronę dla dwustu SKU, policz zgodność czterech pól, zmierz wiek danych o dostępności, sprawdź, czy checkout weryfikuje stan ponownie, i tylko na koniec zajrzyj do specyfikacji protokołów. Cztery pierwsze kroki wykonasz na własnych danych, a ich wynik powie Ci, czy decyzja o standardzie jest dziś w ogóle Twoim najpilniejszym problemem. Szerszy obraz tego, co dzieje się z ruchem, gdy decyzje zakupowe zapadają poza Twoją stroną, opisujemy w tekście o zero-click commerce.

Protokół możesz zmienić w kwartał. Bałagan w danych produktowych utrzymuje się latami.

Źródła i data sprawdzenia

Wszystkie cztery adresy sprawdzone 19 sierpnia 2026. Twierdzenia, których w nich nie znalazłem, zostały w tekście oznaczone jako niepotwierdzone.

• Agentic Commerce Protocol: agenticcommerce.dev (autorstwo Stripe i OpenAI, licencja Apache 2.0, zgodność z REST i MCP, Shared Payment Token, prace nad mechanizmem odkrywania).
• Universal Commerce Protocol: developers.google.com/merchant/ucp (feed Merchant Center, checkout własny albo wbudowany, zgodność z AP2, A2A i MCP, rozszerzanie na kolejne branże).
• UCP pod maską: developers.googleblog.com, wpis z 11 stycznia 2026 (ogłoszenie, partnerzy, manifest pod /.well-known/ucp, profile możliwości).
• Przepływ agentowy Shopify: shopify.dev/docs/agents (cztery kroki przepływu, poziomy zaufania i zakres dostępu, katalogi, narzędzia MCP dla koszyka, checkoutu i zamówień).