Od widoczności w AI do Agentic Commerce B2B — jak przygotować firmę, produkty i proces sprzedaży na agentów zakupowych? Praktyczny przewodnik krok po kroku

Stan wiedzy i rynku: 2 września 2026 r.

Sztuczna inteligencja przestaje być wyłącznie narzędziem pomagającym klientowi znaleźć informacje. Coraz częściej staje się warstwą pośredniczącą między potrzebą kupującego a rzeczywistym działaniem: wyszukaniem produktu, porównaniem wariantów, sprawdzeniem dostępności, wypełnieniem formularza, przygotowaniem zapytania, a w prostszych przypadkach również wykonaniem transakcji.

Dla handlu B2B, przemysłu, logistyki, wyposażenia magazynowego, automatyzacji, materiałów eksploatacyjnych, części zamiennych i usług technicznych oznacza to zasadniczą zmianę.

Do tej pory firma przygotowywała stronę głównie dla:

człowieka → Google → handlowca.

Docelowy model zaczyna wyglądać tak:

człowiek lub agent → wyszukiwarka / answer engine → dane produktu → kwalifikacja → akcja → system dostawcy → człowiek lub transakcja.

Nie oznacza to, że już dziś każdy agent AI samodzielnie kupuje maszyny, materiały czy wyposażenie magazynu. Oznacza natomiast, że infrastruktura potrzebna do takiego modelu powstaje właśnie teraz.

OpenAI rozwija product discovery i własny model dostarczania danych produktowych przez merchant feeds, a w dokumentacji zakupowej wskazuje, że informacje takie jak dostępność, cena, jakość danych czy status producenta/sprzedawcy mogą wpływać na wybór sprzedawcy prezentowanego użytkownikowi.

Google równolegle zaleca traktowanie klasycznych fundamentów SEO, unikalnej treści, indeksowalności i wysokiej jakości danych jako podstawy widoczności również w generatywnym Search, a jednocześnie wskazuje rozwój usług agentowych jako kolejny obszar, który właściciele witryn powinni obserwować.

WebMCP pozwala już eksperymentalnie wystawiać funkcje stron internetowych jako strukturalne narzędzia dla agentów, w tym przez rozszerzenie standardowych formularzy HTML.

Model Context Protocol w wersji z 28 lipca 2026 r. przeszedł w stronę bezstanowego, skalowalnego modelu HTTP z silniejszą warstwą autoryzacji i rozszerzeń.

Agent2Agent Protocol posiada już stabilną wersję 1.0.0, służącą do komunikacji i delegowania zadań pomiędzy niezależnymi agentami.

Jednocześnie pojawiają się praktyczne eksperymenty transakcyjne. DoorDash udostępnił dd-cli, pozwalające m.in. wyszukiwać ofertę, budować koszyk, ponawiać wcześniejsze zamówienia oraz przechodzić do checkoutu; narzędzie zostało zaprojektowane również do używania przez agentów posiadających dostęp do powłoki systemowej. Na 2 września 2026 r. pełna funkcjonalność pozostaje jednak dostępna w modelu waitlist.

Wniosek dla B2B jest prosty:

nie wystarczy przygotować stronę, którą AI potrafi przeczytać. Trzeba zacząć przygotowywać firmę, której system AI potrafi zrozumieć, zakwalifikować i bezpiecznie użyć.

1. Najpierw zmień model myślenia: z SEO na pełny Search-to-Action

Klasyczny model cyfrowej sprzedaży wyglądał mniej więcej tak:

zapytanie → wynik wyszukiwania → strona → formularz → handlowiec.

W środowisku AI dochodzi wiele nowych etapów:

potrzeba → rozmowa z AI → query fan-out → retrieval → odpowiedź → shortlist produktów → porównanie → kwalifikacja → akcja.

Dlatego coraz mniej wystarcza odpowiedź na pytanie:

Czy nasza strona pojawia się wysoko?

Trzeba zacząć zadawać kolejne pytania:

Czy system AI zna firmę?

Czy wiąże ją z właściwą kategorią?

Czy potrafi znaleźć właściwy produkt?

Czy rozumie parametry tego produktu?

Czy umie odróżnić produkt od podobnych modeli i wariantów?

Czy wie, kiedy produkt pasuje?

Czy wie, kiedy nie pasuje?

Czy wie, czego jeszcze nie wiadomo?

Czy zna aktualne warunki handlowe?

Czy istnieje jednoznaczna następna akcja?

Czy agent może tę akcję bezpiecznie wykonać?

Ostatnie pytanie jest największą zmianą roku 2026.

2. Nie wszystkie zakupy B2B automatyzują się w ten sam sposób

Pierwszym praktycznym krokiem powinno być podzielenie oferty według rodzaju decyzji zakupowej.

Typ A — prosty, jednoznaczny produkt SKU

Przykłady:

materiał eksploatacyjny;
standardowe opakowanie;
rolka określonego materiału;
element wyposażenia;
część o jednoznacznym numerze;
powtarzalny produkt katalogowy.

Docelowa ścieżka może wyglądać:

DISCOVER → MATCH → PRICE → STOCK → APPROVAL → ORDER.

To jest najlepszy kandydat do wczesnego Agentic Commerce.

Typ B — produkt standardowy wymagający podstawowego doboru

Przykłady:

urządzenie magazynowe;
standardowa maszyna;
wózek;
owijarka;
zaklejarka;
urządzenie etykietujące;
wyposażenie stanowiska.

Ścieżka:

DISCOVER → QUALIFY → DIRECT RFQ → HUMAN REVIEW → QUOTE.

Agent może wykonać znaczną część pracy, ale nie powinien arbitralnie zatwierdzać doboru.

Typ C — produkt konfigurowany

Przykłady:

urządzenie z wieloma opcjami;
maszyna zależna od wymiarów produktu;
system wymagający prób;
urządzenie integrowane z linią.

Ścieżka:

DISCOVER → COLLECT REQUIREMENTS → PREQUALIFY → REVIEW → RFQ → ENGINEERING → QUOTE.

Typ D — rozwiązanie projektowe

Przykłady:

automatyzacja magazynu;
linia pakująca;
system transportowy;
paletyzacja;
projekt intralogistyczny;
kompletna modernizacja procesu.

Tu agent nie „wybiera produktu”.

Powinien pomagać przejść przez:

PROBLEM → REQUIREMENTS → CAPABILITY MATCH → PROJECT RFQ → HUMAN ENGINEERING.

To rozróżnienie jest fundamentalne.

Nie istnieje jeden uniwersalny „agentic checkout” dla całego B2B.

3. Zbuduj najpierw jeden Product Master

Największym błędem będzie tworzenie osobnej wersji danych:

na stronie;
w PDF;
w ERP;
w JSON-LD;
w feedzie;
w formularzu;
dla ChatGPT;
dla agenta;
dla CRM.

Docelowa zasada powinna brzmieć:

ONE PRODUCT TRUTH → MULTIPLE INTERFACES

Centralnym obiektem powinien być Product Master Record.

Powinien odpowiadać przynajmniej na następujące grupy pytań.

Identity

jednoznaczny Product ID;
producent;
marka;
model;
wariant;
SKU;
MPN;
GTIN, jeżeli istnieje;
nazwy alternatywne;
poprzednik;
następca.

Classification

kategoria;
podkategoria;
zastosowanie;
klasyfikacje zewnętrzne, jeżeli używane.

Technical

parametry techniczne;
jednostki;
wartości minimalne;
maksymalne;
zakresy;
tolerancje;
standard;
opcje.

Applications

do czego produkt jest przeznaczony;
dla jakich branż;
jakie problemy rozwiązuje.

Limitations

kiedy nie należy go stosować;
jakie ma ograniczenia;
czego nie potrafi.

Compatibility

materiały;
urządzenia;
akcesoria;
komponenty;
wymagane zależności.

Documents

instrukcje;
karty techniczne;
certyfikaty;
deklaracje;
rysunki;
dokumentacja instalacyjna.

Commercial

model sprzedaży;
cena albo RFQ;
MOQ;
dostępność;
lead time;
rynek;
dostawa;
warunki.

Nie wszystko musi być publiczne.

Ale wszystkie interfejsy powinny bazować na tej samej prawdzie.

4. Oddziel PRODUCT od OFFER

Jedną z najważniejszych zasad przyszłego agentic commerce jest rozdzielenie właściwości produktu od aktualnych warunków sprzedaży.

Produkt może istnieć przez dziesięć lat.

Cena może obowiązywać trzydzieści dni.

Dlatego:

PRODUCT

to np.:

maksymalny wymiar, masa, materiał, moc, funkcje.

OFFER

to:

cena, stock, waluta, seller, dostawa, ważność, promocja.

To rozróżnienie stosuje również Schema.org przez oddzielenie Product od Offer. Google rekomenduje Product i Offer dla stron handlowych oraz podkreśla znaczenie aktualnych danych o dostępności i cenie.

Dla agentów jest to jeszcze ważniejsze.

Agent nie powinien potraktować ceny z artykułu z 2024 roku jako aktualnej oferty we wrześniu 2026 roku.

5. Każda dynamiczna informacja musi posiadać Freshness

Dane można podzielić na trzy grupy.

LOW RISK

Rzadko się zmieniają:

producent;
model;
podstawowa konstrukcja;
nominalny wymiar.

MEDIUM RISK

Zmieniają się okresowo:

warianty;
kompatybilność;
akcesoria;
dokumentacja.

HIGH RISK

Zmieniają się szybko:

cena;
dostępność;
stock;
termin realizacji;
promocja;
koszt transportu.

Dane HIGH powinny posiadać przynajmniej:

verifiedAt

oraz tam, gdzie ma to sens:

validThrough.

Przyszły agent zakupowy powinien potrafić odróżnić:

„produkt kosztuje 5 000 EUR”

od:

„cena 5 000 EUR została potwierdzona 2 września 2026 r. i obowiązuje do 30 września”.

6. Zbuduj Evidence Map

Agent nie powinien dostawać wyłącznie informacji.

Powinien istnieć mechanizm ustalenia:

skąd ta informacja pochodzi?

Dla istotnego claimu przechowuj:

Claim → Source → Date → Verification → Confidence.

Przykład:

maksymalna masa = 2 000 kg
źródło = dokumentacja producenta
wersja dokumentu = X
verifiedAt = 2026-09-02
confidence = high.

Szczególnie ważne jest to dla:

maksymalnych parametrów;
kompatybilności;
wydajności;
bezpieczeństwa;
norm;
oszczędności;
kosztów;
deklaracji ekologicznych.

Wraz ze wzrostem autonomii agentów rośnie znaczenie danych możliwych do zweryfikowania.

7. Nie publikuj jedynie „pozytywnych” informacji

Klasyczny marketing lubi mówić:

produkt jest szybki, elastyczny, uniwersalny.

Agent zakupowy potrzebuje czegoś innego.

Musi wiedzieć:

Kiedy produkt pasuje?

Kiedy może pasować?

Kiedy nie pasuje?

Czego jeszcze nie wiadomo?

Dlatego dla produktów technicznych warto wprowadzić cztery statusy:

MATCH

Wymagania mieszczą się w znanym zakresie.

MISMATCH

Istnieje potwierdzony warunek wykluczający.

UNKNOWN

Brakuje informacji.

REVIEW

Decyzja wymaga eksperta, testu, analizy procesu albo dodatkowej konfiguracji.

To jeden z najważniejszych elementów architektury agentowej.

8. UNKNOWN musi być poprawną odpowiedzią

Dzisiejsze systemy generatywne często próbują być pomocne nawet wtedy, kiedy brakuje danych.

W handlu technicznym to nie zawsze jest zaleta.

Jeżeli kupujący podał:

wysokość ładunku = 1800 mm,

ale nie podał:

masy,

system nie powinien zakładać:

„zapewne mieści się w limicie”.

Powinien odpowiedzieć:

UNKNOWN — potrzebna maksymalna masa kompletnego ładunku.

Ta zasada powinna być wpisana w architekturę danych, formularze i agent tools.

9. Nie wyciągaj parametrów, których źródło nie podaje

Przykład:

Producent podaje:

prędkość obrotową = 12 obr./min.

Nie oznacza to automatycznie:

wydajność = 12 produktów/min.

Rzeczywista wydajność może zależeć od:

programu;
wysokości;
liczby cykli;
załadunku;
rozładunku;
operatora;
dodatkowych czynności.

Prawidłowy wynik:

REVIEW — wymagane potwierdzenie wydajności dla konkretnego procesu.

Im więcej decyzji podejmują agenci, tym ważniejsza staje się ta zasada.

10. Zbuduj Canonical Answer Page dla każdej strategicznej kategorii

Product Master sam w sobie nie rozwiązuje problemu discovery.

Trzeba jeszcze pomóc wyszukiwarkom, answer engines i ludziom zrozumieć:

czym jest kategoria i jak podejść do wyboru.

Dobra kanoniczna strona kategorii powinna odpowiadać na:

Co to jest?

Jaki problem rozwiązuje?

Jak działa?

Jakie istnieją warianty?

Jak dobrać rozwiązanie?

Jakich danych potrzebuje dostawca?

Jakie są ograniczenia?

Co porównać?

Jakie produkty należą do kategorii?

Co zrobić dalej?

Google w swoim aktualnym przewodniku dla generatywnego Search wyraźnie rekomenduje unikalną, wartościową treść, dobrą strukturę techniczną i indeksowalność zamiast masowej produkcji stron pod każdą wariację zapytania.

Czyli:

budujemy najlepszą odpowiedź,

a nie tysiąc wariantów tej samej odpowiedzi.

11. Projektuj pod Query Fan-out, ale nie produkuj stron pod każde pytanie

AI może rozbić problem na wiele zapytań:

cena,
wydajność,
alternatywy,
ograniczenia,
producent,
parametry,
zastosowania.

Nie oznacza to, że każde pytanie powinno posiadać osobny URL.

Lepszy model:

Canonical Page + Supporting Cluster + Product Pages + Evidence.

Strona główna kategorii odpowiada na pełne spektrum problemu.

Supporting guides rozwijają ważne osobne intencje.

Karty produktów zawierają fakty produktowe.

12. Udostępniaj dane jako HTML, Schema i feed — ale z jednego źródła

Na poziomie publicznym warto projektować kilka projekcji Product Master.

Human HTML

Dla użytkownika.

JSON-LD

Dla systemów wspierających Schema.org.

Product feed

Jeżeli firma korzysta z ekosystemu, który taki feed obsługuje.

Product JSON

Jako przyszła warstwa integracyjna.

Google rekomenduje równoległe wykorzystanie strukturalnych danych produktu i Merchant Center, gdy ma to zastosowanie.

OpenAI posiada obecnie własne zasady dotyczące przekazywania danych przez merchant feeds, a merchant pozostaje odpowiedzialny za poprawność dostarczanych danych.

Nie oznacza to jednak, że firma powinna ręcznie zarządzać trzema kopiami danych.

Powinno istnieć:

Product Master → adapter Google

Product Master → adapter OpenAI

Product Master → adapter WWW

13. Zdefiniuj następną akcję dla każdego produktu

To etap, który w 2026 roku staje się szczególnie ważny.

Dla każdego produktu należy odpowiedzieć:

Co użytkownik albo agent może zrobić po jego zakwalifikowaniu?

Nie zawsze jest to „kup”.

Możliwe Action Types:

CONTACT

Poproś o kontakt.

DIRECT RFQ

Przygotuj zapytanie ofertowe.

SAMPLE REQUEST

Zamów próbkę.

TEST REQUEST

Umów test.

SERVICE REQUEST

Zgłoś serwis.

PART IDENTIFICATION

Zidentyfikuj część.

AVAILABILITY CHECK

Sprawdź stock.

REORDER

Ponów wcześniejsze zamówienie.

ORDER

Złóż zamówienie.

PROJECT DISCOVERY

Rozpocznij analizę projektu.

To pierwszy krok od strony informacyjnej do Action Architecture.

14. Nie zastępuj normalnego kontaktu agentem

Nawet najlepiej zaprojektowany Direct RFQ powinien posiadać fallback:

Nie znam danych — chcę porozmawiać.

Dlatego przy produkcie nadal powinny istnieć:

e-mail;
telefon;
krótki formularz;
konsultacja.

Agentic Commerce nie oznacza eliminacji człowieka.

Oznacza przesunięcie części pracy wykonywanej dotychczas ręcznie przed rozmową z człowiekiem.

15. Zbuduj Direct RFQ zamiast kolejnego formularza kontaktowego

Typowy formularz:

imię
telefon
wiadomość

jest niewystarczający dla zakupów technicznych.

Direct RFQ powinien przekazywać strukturę wymagań.

Przykład dla rozwiązania magazynowego:

Produkt / proces

Czego dotyczy projekt?

Obiekt

Jakie są wymiary, masa, rodzaj produktu?

Wydajność

Ile jednostek na godzinę/dzień?

Środowisko

Temperatura, wilgotność, warunki specjalne.

Automatyzacja

Manualnie, półautomatycznie czy automatycznie?

Integracja

Czy system łączy się z innymi urządzeniami?

Instalacja

Gdzie ma zostać uruchomiony?

Termin

Kiedy rozwiązanie ma być dostępne?

Buyer

Kto składa zapytanie?

16. Pola RFQ muszą być typowane

Nie zapisuj wszystkiego jako tekst.

Nie:

„około dwóch ton”.

Lepiej:

value = 2000
unit = kg
qualifier = approx

Nie:

„dużo palet”.

Lepiej:

palletsPerHour = 60

Pozwala to agentowi i systemowi automatycznie wykonać kwalifikację.

17. Dodaj requiredAtStage

Nie każde pole musi być znane od początku.

Na etapie discovery może wystarczyć:

typ procesu + podstawowy wymiar.

Przed kwalifikacją potrzebne są:

wymiary + masa + wydajność.

Przed RFQ:

dane firmy + lokalizacja.

Przed ofertą:

dodatkowe wymagania techniczne.

Dlatego warto przypisywać pola do etapów:

DISCOVERY

QUALIFICATION

RFQ SUBMISSION

TECHNICAL REVIEW

QUOTE.

Dzięki temu agent nie zadaje trzydziestu pytań na początku rozmowy.

18. Stosuj Progressive RFQ

Prawidłowy proces może wyglądać tak:

Agent: jaki jest maksymalny wymiar?

Użytkownik odpowiada.

Agent: jaka jest masa?

Po dwóch odpowiedziach system wykrywa MISMATCH.

Nie pyta już o:

budżet;
termin;
adres instalacji;
folię;
akcesoria.

Informuje:

standardowa konfiguracja nie spełnia wymagania; można sprawdzić inną wersję albo produkt.

To oszczędza czas obu stron.

19. Oddziel Qualification od Resolution

Jeżeli wynik brzmi:

MISMATCH

nie oznacza to zawsze:

koniec.

Możliwe kolejne działania:

ALTERNATIVE_CONFIGURATION

ALTERNATIVE_PRODUCT

HUMAN_REVIEW

ASK_MISSING_DATA

CONTACT_SUPPLIER

STOP

Dlatego przyszły system powinien zwracać dwie informacje:

qualification.status

oraz

qualification.resolution.

To bardzo ważne dla agentów.

20. Agent nie może mieć nieograniczonego prawa do działania

Przyszły system powinien rozróżniać:

DISCOVER

Agent może znaleźć ofertę.

READ

Może odczytać dane.

COMPARE

Może porównać produkty.

PREPARE

Może przygotować RFQ.

SUBMIT

Może wysłać RFQ.

ACCEPT QUOTE

Może zaakceptować ofertę.

ORDER

Może złożyć zamówienie.

PAY

Może wykonać płatność.

To są zupełnie różne poziomy uprawnienia.

Najbezpieczniejszy model na obecnym etapie dla większości B2B:

PREPARE → HUMAN APPROVAL → SUBMIT.

21. Wprowadź approval boundary

Przed wysłaniem ważnego RFQ agent powinien pokazać:

Podsumowanie zapytania.

Użytkownik widzi:

produkt;
konfigurację;
wymagania;
dane firmy;
pliki;
termin;
budżet, jeżeli podano;
odbiorcę.

Dopiero po zatwierdzeniu następuje:

SUBMIT.

Jeszcze ważniejsze jest to przy:

zamówieniach;
płatnościach;
danych poufnych;
plikach technicznych;
zobowiązaniach finansowych.

WebMCP przewiduje mechanizmy interakcji użytkownika przy wrażliwych akcjach, np. zakupach.

22. Nie traktuj WebMCP jako zamiennika normalnej strony

WebMCP jest na 2 września 2026 r. proponowanym standardem i znajduje się w fazie eksperymentalnej/origin trial.

Jego istotna zaleta polega jednak na czymś innym:

istniejący formularz HTML może otrzymać strukturalne znaczenie dla agenta.

Chrome opisuje dwa modele:

Declarative API

Adnotacje do standardowych formularzy.

Imperative API

JavaScript rejestrujący narzędzia z określonym JSON Schema.

Dlatego prawidłowa kolejność brzmi:

dobry formularz HTML → canonical schema → WebMCP enhancement

a nie:

specjalna strona tylko dla agentów.

23. Frontend i backend agentowy to dwie różne rzeczy

WebMCP pomaga agentowi działającemu w przeglądarce zrozumieć funkcje strony.

MCP działa na innym poziomie.

Chrome opisuje to wprost:

WebMCP jest warstwą frontendową, podczas gdy MCP służy do łączenia agentów z backendowymi systemami, narzędziami i danymi.

Praktyczna architektura może więc wyglądać:

strona WWW

↓

WebMCP

↓

API

↓

CRM / ERP / PIM

a równolegle:

agent

↓

MCP

↓

to samo API

↓

CRM / ERP / PIM.

24. MCP nie powinien otrzymać własnej kopii danych

Aktualny MCP 2026-07-28 rozwija m.in.:

bezstanowy core;
routowanie przez nagłówki;
cache’owanie list;
silniejszą autoryzację;
formalne rozszerzenia.

Dla firmy B2B może to oznaczać późniejsze wystawienie narzędzi:

product.search
product.get
product.compare
availability.check
rfq.prepare
rfq.submit
rfq.status
order.reorder

Ale narzędzia te powinny korzystać z:

Product Master + Offer + RFQ backend.

Nie z osobnej bazy stworzonej „dla MCP”.

25. A2A jest kolejnym poziomem, nie kartą produktu

Agent2Agent Protocol 1.0 służy do współpracy pomiędzy niezależnymi agentami. Specyfikacja przewiduje m.in. discovery capabilities, strukturalną wymianę informacji i zarządzanie zadaniami.

W sierpniu 2026 r. A2A zostało również przyjęte jako Growth Stage project przez Agentic AI Foundation; dokumentacja A2A opisuje MCP jako pionową warstwę integracji z narzędziami, a A2A jako poziom współpracy między agentami.

Przykładowo:

Agent kupującego

może zlecić:

„znajdź rozwiązanie i przygotuj zapytanie”.

Agent dostawcy

może odpowiedzieć:

„potrzebuję jeszcze tych trzech danych”.

Ale firma nie powinna deklarować „A2A Ready”, jeśli nie istnieje rzeczywisty agent.

26. Najwcześniejszym Agentic Commerce w B2B będzie prawdopodobnie reorder

W praktyce największa automatyzacja może pojawić się początkowo nie przy zakupie dużej maszyny, ale przy prostych, powtarzalnych produktach.

Przykład:

Kup 20 takich samych rolek materiału jak poprzednio.

Agent zna:

klienta;
produkt;
SKU;
ostatnie zamówienie;
ilość;
standardowe miejsce dostawy.

Do sprawdzenia pozostaje:

stock;
aktualna cena;
termin;
limit zakupowy.

Proces:

IDENTIFY PREVIOUS ORDER

↓

CHECK SKU

↓

CHECK CURRENT OFFER

↓

COMPARE MATERIAL CHANGE

↓

CHECK AUTHORITY

↓

USER APPROVAL

↓

REORDER.

To może być prostsze niż wdrożenie pełnego agentowego zakupu pierwszej maszyny.

27. Zaprojektuj oddzielny Reorder Profile

Dla produktów powtarzalnych warto zbudować:

Customer identity

Kto kupuje?

Previous order

Co kupował?

Product ID

Czy to dokładnie ten sam produkt?

Version check

Czy specyfikacja się zmieniła?

Price check

Jaka jest dzisiejsza cena?

Availability

Czy produkt jest dostępny?

Quantity

Ile zamawiamy?

Delivery

Dokąd?

Authority

Czy agent może przygotować czy także wysłać?

Approval

Czy wymagana jest zgoda użytkownika?

To będzie w wielu B2B realniejszy pierwszy Agentic Transaction niż kompletny autonomiczny marketplace.

28. Firma powinna zachować relację z klientem

To ważna lekcja płynąca również z handlu konsumenckiego.

Reuters opisuje sytuację, w której retailerzy chcą korzystać z rosnącego ruchu generowanego przez narzędzia AI, ale jednocześnie starają się zachować finalną transakcję i dane klienta we własnych systemach.

Dla B2B można z tego wyprowadzić rozsądną zasadę:

BE DISCOVERABLE EVERYWHERE.

TRANSACT ON YOUR OWN RAILS.

Agent może odkryć produkt w dowolnym systemie.

Ale:

RFQ;
konfiguracja;
dane klienta;
dokumentacja;
oferta;
zamówienie;
historia;

powinny trafiać do infrastruktury firmy.

29. Wartością nie będzie już tylko lead, ale structured demand data

Typowy lead wygląda:

Firma X, e-mail Y, chce urządzenie.

Direct RFQ może przekazywać:

produkt = X
długość = 1200 mm
szerokość = 800 mm
masa = 900 kg
wydajność = 40/h
automatyzacja = semi-auto
temperatura = 18°C
termin = Q1.

Po kilkuset zapytaniach firma posiada nowy rodzaj danych.

Może zobaczyć:

najczęstsze wymagania;
parametry graniczne;
najczęstsze MISMATCH;
brakujące produkty;
brakujące konfiguracje;
popularne opcje;
zmiany wymagań rynku.

To prowadzi do:

RFQ DATA → PRODUCT OPPORTUNITY MAP.

AI nie tylko generuje leady.

Może pomagać rozwijać portfolio.

30. Stwórz Agentic Commerce Readiness Score

Praktyczny audyt produktu może obejmować dziewięć poziomów.

Level 1 — Identified

Produkt posiada jednoznaczny ID.

Level 2 — Structured

Parametry są zapisane strukturalnie.

Level 3 — Comparable

Można porównywać produkty.

Level 4 — Evidence-backed

Kluczowe parametry mają dowody.

Level 5 — Qualifiable

Istnieją MATCH / MISMATCH / UNKNOWN / REVIEW.

Level 6 — Action Ready

Istnieje Direct RFQ / reorder / inna właściwa akcja.

Level 7 — Machine Published

Dane są dostępne maszynowo.

Level 8 — Agent Accessible

Istnieje WebMCP / API / MCP lub podobna funkcja.

Level 9 — Agent Transactional

Agent może przejść przez kontrolowaną akcję handlową.

Nie trzeba natychmiast dążyć do Level 9 dla wszystkich produktów.

31. Które produkty wdrażać pierwsze?

Najlepiej wybrać trzy skrajne przykłady.

Pilot 1 — standardowy produkt techniczny

Cel:

Product → Qualification → Direct RFQ.

Pilot 2 — produkt configured-to-order

Cel:

sprawdzenie UNKNOWN, REVIEW, conditional logic i human handoff.

Pilot 3 — prosty produkt powtarzalny

Cel:

Product → Offer → Approval → Reorder.

Dopiero te trzy testy pokazują, czy architektura jest naprawdę uniwersalna.

32. Zbuduj evals przed udostępnieniem agentom

Nie wystarczy stwierdzić:

mamy tool.

Trzeba sprawdzić, czy agent:

wybiera właściwe narzędzie;

nie uruchamia go w złej sytuacji;

prawidłowo mapuje dane użytkownika;

nie wymyśla brakujących wartości;

rozumie MISMATCH;

zatrzymuje się przy REVIEW;

prawidłowo interpretuje błędy;

pyta o brakujące dane;

nie wykonuje submit bez zgody;

poprawnie reaguje na niebezpieczne instrukcje.

Chrome posiada już osobny mechanizm WebMCP Evals i rekomenduje testowanie, czy agent rozumie, kiedy wywołać tool, jak go wykonać oraz jaki rezultat jest akceptowalny.

Evals staną się dla agentic commerce odpowiednikiem dzisiejszych testów UX + QA + bezpieczeństwa.

33. Testuj także przypadki negatywne

Dobry zestaw evals powinien zawierać co najmniej:

Happy path

Produkt pasuje.

Missing parameter

Brakuje wartości krytycznej.

Boundary

Wartość dokładnie na limicie.

Mismatch

Produkt nie pasuje.

Alternative

Nie pasuje bieżący wariant, ale istnieje inny.

Conflicting data

Dwa źródła podają inne wartości.

Expired price

Cena jest nieaktualna.

Agent overreach

Agent próbuje zamówić bez wymaganej zgody.

Prompt injection

Nieufne dane na stronie próbują zmienić zachowanie agenta.

Duplicate submission

Agent ponawia request po timeout.

To ostatnie jest szczególnie ważne w commerce.

34. Wprowadź idempotency

Jeżeli agent wyśle:

RFQ-123,

a połączenie zostanie przerwane, może nie wiedzieć, czy zapytanie dotarło.

Ponowienie tej samej operacji nie powinno utworzyć pięciu leadów.

Dlatego system transakcyjny powinien stosować:

Idempotency Key

albo równoważny mechanizm.

To detal techniczny, ale bardzo ważny w środowisku agentowym.

35. Nie udostępniaj agentom sekretów i danych prywatnych

Publiczny Product JSON może zawierać:

parametry;
dokumenty publiczne;
informacje handlowe.

Nie powinien zawierać:

haseł;
tokenów;
prywatnych cenników;
rabatów klienta;
wewnętrznych kosztów;
danych innych klientów;
plików objętych NDA;
wewnętrznej dokumentacji serwisowej.

Warto wprowadzić klasy dostępu:

PUBLIC

AUTHENTICATED

CUSTOMER

PARTNER

INTERNAL

CONFIDENTIAL.

36. Oddziel dane zakupowe od marketingowych

Jeżeli użytkownik przesyła RFQ, oznacza to:

chce otrzymać odpowiedź dotyczącą swojego zapytania.

Nie oznacza automatycznie:

chce newsletter.

Commerce i marketing powinny pozostać osobnymi warstwami.

To będzie jeszcze ważniejsze, gdy część zapytań zacznie pochodzić od agentów działających w imieniu organizacji.

37. Nie każ agentowi udawać człowieka

Najgorsza przyszła architektura:

agent analizuje DOM, zgaduje, co oznacza każdy przycisk, klika losowo i wpisuje dane.

Lepsza:

strona deklaruje jasno: rfq.prepare, rfq.submit, availability.check.

WebMCP właśnie próbuje zmniejszyć zależność od takiej kruchej „actuation” poprzez jawne tools i JSON Schema.

38. Nie zaczynaj jednak projektu od MCP

To częsty błąd.

Firma ma:

niespójne dane;
trzy ceny;
dwa modele pod jednym URL;
brak Product ID;
brak warunków fit;
brak źródeł.

I chce wdrożyć MCP.

To odwrócona kolejność.

Prawidłowo:

DATA

↓

PRODUCT TRUTH

↓

QUALIFICATION

↓

ACTION CONTRACT

↓

FORM / API

↓

MCP / WebMCP

↓

A2A.

Protokół nie naprawi złej informacji.

39. Nie zaczynaj również od „specjalnej treści dla AI”

Google wprost ostrzega przed nadmiernym tworzeniem osobnych treści pod wariacje zapytań czy sztuczkami GEO/AEO pozbawionymi wartości dla użytkowników.

Lepszy kierunek:

jedna dobra prawda produktowa;

jedna dobra strona kategorii;

realne evidence;

jasne ograniczenia;

pełne dane;

właściwe structured data;

machine adapters.

40. Nowe KPI: widoczność przestaje wystarczać

Przyszły dashboard powinien mierzyć cały lejek.

AI Brand Inclusion

Jak często marka pojawia się w odpowiedziach?

Product Retrieval Rate

Jak często właściwy produkt zostaje znaleziony?

Product Understanding Accuracy

Czy AI prawidłowo odczytuje parametry?

Qualification Accuracy

Czy MATCH/MISMATCH/UNKNOWN/REVIEW działa poprawnie?

Action Availability

Jaki procent produktów posiada właściwą action route?

RFQ Start Rate

Ile osób/agentów rozpoczyna RFQ?

RFQ Completion Rate

Ile kończy?

Clarification Rate

Ile zapytań wymaga dodatkowych danych?

Time to Qualification

Jak szybko otrzymujemy komplet danych?

Quote Rate

RFQ → oferta.

Win Rate

RFQ → sprzedaż.

Reorder Success Rate

Ile ponowień zakupów działa bezproblemowo?

Agent Action Success Rate

Jak często agent prawidłowo wykonuje workflow?

41. Szczególnie wartościowy będzie Mismatch Rate

Załóżmy, że 35% zapytań o jeden produkt kończy się:

wysokość za duża.

To nie jest tylko problem sprzedażowy.

To sygnał:

rynek może potrzebować nowej wersji produktu.

Jeżeli 27% klientów pyta:

czy istnieje funkcja X,

a nie ma jej w portfolio:

to potencjalny Product Development Signal.

Dzięki temu dział marketingu, sprzedaży i produktu zaczynają pracować na tych samych danych.

42. Architektura docelowa B2B

Pełny model może wyglądać następująco:

BUYER NEED
↓
SEARCH / AI / AGENT
↓
CANONICAL ANSWER
↓
CATEGORY / ENTITY UNDERSTANDING
↓
PRODUCT MASTER
↓
PRODUCT CARD
↓
QUALIFICATION
↓
MATCH / MISMATCH / UNKNOWN / REVIEW
↓
ACTION ROUTE
├── STANDARD CONTACT
├── DIRECT RFQ
├── SAMPLE
├── SERVICE
├── REORDER
└── ORDER
↓
APPROVAL
↓
API / WEBMCP / MCP
↓
CRM / ERP / PIM / CPQ
↓
HUMAN REVIEW OR TRANSACTION
↓
QUOTE
↓
ORDER
↓
DELIVERY
↓
SERVICE
↓
REORDER

To nie jest pojedynczy „system AI”.

To architektura danych i procesów pozwalająca różnym systemom AI działać na tych samych zasadach.

43. Praktyczna roadmapa 90 dni

Dni 1–15 — Inventory

Wybierz:

10–20 strategicznych produktów;
2–3 główne kategorie;
1 produkt prosty;
1 produkt techniczny;
1 produkt konfigurowany.

Zidentyfikuj:

URL;
Product ID;
źródła;
dokumentację;
obecne formularze;
ceny;
konflikty.

Dni 16–30 — Product Truth

Zbuduj Product Master dla pilota.

Uzupełnij:

identity;
technical;
applications;
limitations;
compatibility;
documents;
evidence;
commercial;
freshness.

Dni 31–40 — Answer Layer

Przepisz strategiczne strony według Answer Architecture.

Dodaj:

odpowiedź w skrócie;
canonical answer;
parametry;
dobór;
ograniczenia;
FAQ;
dokumenty;
aktualność.

Dni 41–50 — Structured Layer

Wdroż:

Product;
Offer tam, gdzie właściwe;
Organization;
Breadcrumb;
warianty;
feed, jeżeli wykorzystywany;
kanoniczny machine JSON.

Dni 51–60 — Qualification

Dla jednego produktu zbuduj:

MATCH

MISMATCH

UNKNOWN

REVIEW

oraz:

nextAction.

Dni 61–70 — Direct RFQ

Zbuduj prawdziwy strukturalny formularz.

Niech generuje:

canonical RFQ object.

Dodaj:

progressive questions;
validation;
conditional logic;
approval;
RFQ ID.

Dni 71–80 — Action Layer

Wybierz:

WebMCP albo własny API proof-of-concept;
rfq.prepare;
rfq.submit;
availability.check.

Nie buduj jeszcze dwudziestu tools.

Dni 81–90 — Evals

Testuj:

20–50 realnych przypadków;
przypadki graniczne;
braki;
niezgodności;
błędne dane;
powtórzone requesty;
brak authority.

Dopiero po tym rozszerz system.

44. Co zrobić w następnych 6–12 miesiącach

Jeżeli pilotaż działa:

Rozszerz Product Master.

Zbuduj kolejne RFQ Profiles.

Dodaj Reorder Profile.

Połącz z CRM.

Połącz z ERP/PIM.

Udostępnij API.

Dodaj MCP.

W dalszym etapie rozważ rzeczywistego A2A Agent.

Najważniejsza zasada:

każda kolejna warstwa powinna używać tych samych obiektów informacji.

45. Co jest realne dziś, a co nadal emerging?

Produkcyjnie realne dziś

Product Master;
strukturalne dane produktu;
feedy produktowe;
Answer Architecture;
qualification;
structured RFQ;
API;
human-in-the-loop;
CRM integration;
reorder workflows;
MCP backend.

Emerging / wdrażane obecnie

WebMCP;
browser-native agent tools;
rozbudowane agentic purchasing;
cross-agent A2A commerce;
autonomiczne B2B procurement flows.

WebMCP pozostaje proponowanym standardem w aktywnym rozwoju, a Chrome wskazuje ograniczenia m.in. związane z headless browsing i koniecznością bezpośredniego odwiedzenia witryny w celu odkrycia dostępnych tools.

Nie warto więc budować strategii zakładającej, że jeden konkretny protokół wygra.

Warto zbudować dobrą warstwę danych i action contracts, do których można podłączać adaptery.

46. Adapter-first zamiast protocol-first

To prawdopodobnie najbezpieczniejsza zasada architektoniczna na lata 2026–2028.

Nie:

wszystkie dane przepisujemy do formatu X.

Tylko:

PRODUCT MASTER
    ↓
QUALIFICATION
    ↓
ACTION CONTRACT
    ↓
ADAPTERS
    ├── HTML
    ├── Schema.org
    ├── Google
    ├── OpenAI
    ├── WebMCP
    ├── MCP
    ├── A2A
    └── przyszły standard

Jeżeli za dwa lata pojawi się nowy dominujący protokół:

tworzymy adapter.

Nie przepisujemy katalogu.

47. Jak sprawdzić, czy firma jest rzeczywiście Agent Ready?

Zadaj dziesięć pytań.

Czy każdy ważny produkt posiada trwały ID?
Czy istnieje jedno źródło prawdy parametrów?
Czy dynamiczne dane mają freshness?
Czy kluczowe claimy posiadają evidence?
Czy znamy warunki MATCH?
Czy znamy MISMATCH?
Czy system potrafi odpowiedzieć UNKNOWN?
Czy istnieje jednoznaczny następny krok?
Czy agent może wykonać go strukturalnie?
Czy krytyczne działania posiadają authority i human approval?

Jeżeli odpowiedź brzmi:

1–3 × TAK,

firma jest głównie:

AI-readable.

Jeżeli:

4–7 × TAK,

jest:

Agent Qualifiable.

Jeżeli:

8–10 × TAK,

zaczyna być:

Agent Actionable.

48. Największa przewaga nie będzie technologiczna

Najtrudniejsze do skopiowania nie będzie:

posiadanie MCP.

Konkurencja może uruchomić serwer MCP bardzo szybko.

Trudniejsze będzie posiadanie:

czystych Product Master Data;
historii RFQ;
wiedzy o rzeczywistych wymaganiach klientów;
evidence;
qualification rules;
compatibility data;
produktów z dobrze opisanymi ograniczeniami;
własnych benchmarków;
doświadczenia serwisowego;
historii transakcji;
poprawnej architektury uprawnień.

To jest prawdziwy moat.

49. Dlaczego należy zacząć teraz

Badanie Narvar z sierpnia 2026 r. wskazało, że 65% badanych konsumentów w USA deklarowało zamiar wykorzystania AI w okresie zakupowym, podczas gdy jedynie 8% ankietowanych przedstawicieli retailerów określało swoją organizację jako bardzo pewną przygotowania do wykorzystania AI w customer experience. Badanie dotyczy handlu konsumenckiego, a nie przemysłowego B2B, dlatego nie należy bezpośrednio przenosić tych wartości na zakupy przedsiębiorstw. Pokazuje jednak szybko rosnącą asymetrię między sposobem, w jaki kupujący wykorzystują AI, a tempem adaptacji infrastruktury po stronie sprzedawców.

W B2B zmiana może następować wolniej.

Ale jej efekt może być większy.

Bo jedno poprawnie przygotowane RFQ może reprezentować wartość nie 100 PLN, lecz:

dziesiątki tysięcy, setki tysięcy albo miliony.

50. Zasada końcowa

Nie optymalizuj firmy wyłącznie pod:

Google.

Nie optymalizuj jej wyłącznie pod:

ChatGPT.

Nie optymalizuj jej wyłącznie pod:

jednego agenta.

Buduj:

CORRECT BUSINESS TRUTH.

Następnie pozwól różnym systemom korzystać z niej poprzez właściwy interfejs.

Docelowa transformacja wygląda tak:

WEB CONTENT
↓
STRUCTURED PRODUCT DATA
↓
PRODUCT UNDERSTANDING
↓
EVIDENCE
↓
QUALIFICATION
↓
ACTION CONTRACT
↓
DIRECT RFQ / REORDER
↓
HUMAN OR AGENT APPROVAL
↓
TRANSACTION

Najważniejsza zmiana roku 2026 nie polega więc na tym, że:

AI potrafi znaleźć produkt.

Coraz ważniejsze staje się to, że:

AI potrafi przejść od znalezienia produktu do działania.

Firma B2B przygotowana na ten etap powinna potrafić powiedzieć agentowi dokładnie:

co oferuje;

jakie ma parametry;

skąd te informacje pochodzą;

kiedy rozwiązanie pasuje;

kiedy nie pasuje;

czego jeszcze nie wiadomo;

jakie dane trzeba zebrać;

jaką akcję można wykonać;

kto może ją zatwierdzić;

i gdzie kończy się automatyzacja, a zaczyna odpowiedzialność człowieka.

To właśnie jest praktyczna definicja:

Agent-Ready B2B Commerce

na dzień 2 września 2026 r.

Szybki kontakt z Warehouser™ — rozwiązania dla magazynów.

Opisz, czego potrzebuje Twój magazyn. Wybierz obszar i opisz potrzebę własnymi słowami. Jeżeli nie masz wszystkich parametrów, podaj to, co już wiesz: proces, problem, skalę, lokalizację i oczekiwany termin. Brakujące informacje możemy uporządkować przed skierowaniem zapytania dalej.

Materiały do pakowania • Maszyny i urządzenia • Wyposażenie magazynu • Automatyzacja i technologie magazynowe

Zadzwoń: 691 669 192
Napisz: kontakt@warehouser.pl

Administratorem danych jest Warehouser™. Dane wykorzystamy w celu przyjęcia i obsługi Twojej wiadomości oraz udzielenia odpowiedzi. Szczegóły dotyczące podstaw prawnych, okresu przechowywania danych, odbiorców i Twoich praw znajdziesz w Polityce prywatności.

Warehouser™ pomaga uporządkować potrzeby i zapytania. W rozwiązaniach partnerskich dobór techniczny, wycenę, sprzedaż, dostawę, gwarancję i serwis prowadzi partner wskazany w konkretnej ofercie.

Warehouser™ — rozwiązania dla magazynów.

Materiały do pakowania • Maszyny i urządzenia • Wyposażenie magazynu • Automatyzacja i technologie magazynowe