Agentic Web 2026: MCP, A2A, NLWeb i AGENTS.md

Agentic Web 2026: MCP, A2A, NLWeb i AGENTS.md. Jak przygotować firmę B2B, produkt i ofertę do działania agentów AI

Stan na 16 lipca 2026 r.

Internet przechodzi kolejną zmianę architektoniczną. Dotychczas strony były projektowane głównie po to, aby człowiek mógł je znaleźć, przeczytać i wykonać określoną czynność. W agentic web odbiorcą treści, danych i usług coraz częściej staje się również agent AI, który ma odnaleźć właściwą firmę, zrozumieć produkt, porównać warianty, sprawdzić dostępność, zebrać brakujące informacje, przygotować zapytanie ofertowe, skontaktować się z agentem dostawcy, a w określonych przypadkach także doprowadzić proces do transakcji.

Search Engine Journal wskazuje cztery ważne elementy tej powstającej infrastruktury: Model Context Protocol — MCP, Agent2Agent Protocol — A2A, NLWeb oraz AGENTS.md. Nie są to konkurencyjne rozwiązania. Każde odpowiada za inny fragment agentowego internetu: dostęp do narzędzi i danych, komunikację między agentami, konwersacyjny dostęp do zawartości strony albo instrukcje dla agentów programistycznych.

Z perspektywy handlu B2B nadal pozostaje jednak istotna luka. Protokoły techniczne mogą umożliwić agentom komunikację, ale same nie określają jeszcze:

co dokładnie firma sprzedaje;
czy produkt pasuje do danego zastosowania;
jaka konfiguracja jest oferowana;
jaka jest cena i do kiedy obowiązuje;
jakie jest MOQ;
jaka jest dostępność;
jakie dokumenty i certyfikaty są wymagane;
które parametry trzeba zebrać przed wyceną;
jak powinno wyglądać kompletne zapytanie ofertowe.

Właśnie tę lukę mają wypełniać dwa uzupełniające się standardy B2B:

A2A Card — standard opisu podaży, czyli firmy, produktu, oferty i zdolności dostawcy.

Direct RFQ — standard opisu popytu i konkretnego zapytania ofertowego.

1. Czym jest agentic web?

Agentic web można opisać jako warstwę internetu, w której systemy AI nie tylko wyświetlają odpowiedzi, lecz również wykonują zadania w imieniu użytkownika.

Klasyczna wyszukiwarka prowadziła użytkownika do strony. Answer engine przygotowuje odpowiedź na podstawie wielu źródeł. Agent AI może pójść dalej:

rozpoznać intencję;
odnaleźć potencjalnych dostawców;
odczytać parametry produktów;
odrzucić rozwiązania niespełniające wymagań;
sprawdzić dane aktualne w czasie rzeczywistym;
poprosić o brakujące informacje;
przygotować RFQ;
przekazać zadanie agentowi dostawcy;
odebrać ofertę;
przedstawić rekomendację człowiekowi;
w granicach udzielonego mandatu wykonać kolejną czynność.

Nie oznacza to końca stron internetowych ani klasycznego SEO. Strona pozostaje źródłem informacji, reputacji, dowodów i danych. Zmienia się jednak sposób korzystania z niej. Coraz częściej strona musi być jednocześnie:

czytelna dla człowieka;
indeksowalna przez wyszukiwarkę;
możliwa do cytowania przez answer engine;
jednoznaczna semantycznie;
odpytywalna przez agenta;
przygotowana do przekazania danych do systemu zewnętrznego;
gotowa do obsługi działania, a nie tylko wyświetlenia treści.

2. MCP — dostęp agenta do danych i narzędzi

Czym jest Model Context Protocol?

Model Context Protocol jest otwartym protokołem umożliwiającym aplikacjom wykorzystującym modele językowe łączenie się z zewnętrznymi źródłami danych i narzędziami. Według oficjalnej dokumentacji MCP umożliwia udostępnianie kontekstu, narzędzi i złożonych integracji. Komunikacja w stabilnej specyfikacji odbywa się przy wykorzystaniu komunikatów JSON-RPC 2.0 pomiędzy hostem, klientem MCP i serwerem MCP. Na 16 lipca 2026 r. najnowszą stabilną wersją wskazaną w oficjalnej dokumentacji pozostaje specyfikacja z 25 listopada 2025 r.

Serwer MCP może udostępniać trzy podstawowe rodzaje elementów:

resources — dane i zasoby;
prompts — przygotowane szablony i procedury;
tools — funkcje, które agent może wywołać.

MCP w firmie B2B

W przedsiębiorstwie handlowym lub produkcyjnym serwer MCP może udostępniać agentowi narzędzia takie jak:

search_products;
get_product_specification;
check_inventory;
calculate_price;
get_delivery_options;
retrieve_document;
create_rfq;
check_rfq_status;
prepare_quote;
get_order_status;
request_service_visit.

Dzięki temu agent nie musi polegać wyłącznie na treści podstrony, która może przedstawiać dane statyczne. Może pobrać aktualny stan magazynowy, cenę, dostępne terminy, dokumentację lub status prowadzonego zapytania.

Czego MCP nie rozwiązuje?

MCP nie jest katalogiem produktów, systemem klasyfikacji ofert ani językiem zapytań zakupowych. Informuje, jak agent ma połączyć się z narzędziem lub zasobem, ale nie definiuje pełnej semantyki produktu B2B.

Można zbudować narzędzie get_offer, ale trzeba jeszcze określić:

jakie dane wejściowe są wymagane;
co dokładnie oznacza „oferta”;
jak wyrazić MOQ;
jak opisać konfigurację;
jak oznaczyć cenę netto;
jak przekazać ważność ceny;
jak odróżnić dostępność magazynową od terminu produkcyjnego;
jak opisać kwalifikację techniczną.

Tę semantykę powinny zapewniać A2A Card i Direct RFQ.

Bezpieczeństwo MCP

MCP może otwierać dostęp do danych i wykonywania operacji, dlatego nie powinien być traktowany jak zwykły publiczny feed. Oficjalna specyfikacja wymaga zwrócenia szczególnej uwagi na zgodę użytkownika, kontrolę dostępu, prywatność, bezpieczeństwo narzędzi i świadome zatwierdzanie działań. Narzędzia powinny walidować dane wejściowe, stosować kontrolę dostępu, ograniczenia wywołań, sanitację wyników oraz rejestrowanie działań do celów audytowych.

W praktyce należy rozdzielić:

publiczne informacje produktowe;
dane dostępne po identyfikacji firmy;
ceny kontraktowe;
stany magazynowe;
dane klientów;
tworzenie ofert;
rezerwację towaru;
składanie zamówień;
operacje wymagające akceptacji człowieka.

3. A2A — komunikacja pomiędzy agentami

Czym jest Agent2Agent Protocol?

Agent2Agent Protocol jest otwartym standardem komunikacji i współpracy pomiędzy agentami AI zbudowanymi przez różnych dostawców i przy użyciu różnych frameworków. Oficjalna dokumentacja podkreśla, że MCP i A2A rozwiązują dwa różne problemy:

MCP obsługuje połączenie agenta z narzędziami i danymi;
A2A obsługuje połączenie agenta z innym agentem.

A2A osiągnął w 2026 r. stabilną wersję 1.0 określaną przez projekt jako wersję produkcyjną. Wprowadziła ona między innymi obsługę wielu protokołów transportowych, wersjonowanie, wielodostępność, podpisywane Agent Cards oraz rozszerzone mechanizmy uwierzytelniania.

Jak A2A może działać w B2B?

Wyobraźmy sobie następujący proces:

agent kupującego otrzymuje zadanie znalezienia folii maszynowej;
identyfikuje potencjalnego dostawcę;
odnajduje agenta dostawcy;
sprawdza, czy agent potrafi przygotować ofertę na dany produkt;
wysyła ustrukturyzowane zapytanie;
agent dostawcy sprawdza magazyn i warunki handlowe poprzez MCP;
jeżeli brakuje danych, odsyła pytania kwalifikacyjne;
po zebraniu informacji przygotowuje ofertę;
agent kupującego porównuje odpowiedź z innymi ofertami;
człowiek zatwierdza dalsze działanie.

A2A nie wymaga ujawniania wewnętrznego sposobu działania agentów. Agent dostawcy nie musi przekazywać agentowi kupującego swoich promptów, pamięci, wewnętrznych narzędzi ani logiki biznesowej. Udostępnia jedynie obsługiwane możliwości i wyniki zleconych zadań.

Oficjalna A2A Agent Card

W A2A agent publikuje Agent Card, czyli dokument JSON opisujący między innymi:

nazwę i tożsamość agenta;
operatora lub dostawcę;
adres interfejsu;
obsługiwane funkcje;
umiejętności;
formaty danych wejściowych i wyjściowych;
metody uwierzytelniania;
dostępne sposoby komunikacji.

Publiczna karta może zostać udostępniona w standardowej lokalizacji:

/.well-known/agent-card.json

Agent klienta odczytuje kartę, aby ocenić, czy dany agent nadaje się do wykonania zadania i jak należy się z nim bezpiecznie komunikować.

Ważne rozróżnienie: Agent Card a A2A Card

Nazwy są podobne, ale oznaczają dwie różne rzeczy.

A2A Agent Card

Jest elementem oficjalnego protokołu Agent2Agent. Opisuje agenta i jego techniczne możliwości.

Przykład:

Agent firmy DI-ZET potrafi sprawdzić dostępność produktu, przyjąć Direct RFQ i przygotować ofertę.

A2A Card

W naszym modelu jest standardem opisu podmiotu gospodarczego, produktu, oferty albo zdolności wykonawczej.

Przykład:

DI-ZET oferuje folię stretch maszynową Infinity Ultra 17 µm, dostępną z magazynu, w określonej cenie i z określonym terminem dostawy.

Aby ograniczyć nieporozumienia, należy konsekwentnie stosować pełne określenia:

A2A Agent Card — karta techniczna agenta zgodna z protokołem A2A;
A2A Business Card — karta przedsiębiorstwa;
A2A Product Card — karta produktu i oferty;
A2A Capability Card — karta zdolności produkcyjnej lub usługowej;
Direct RFQ Card — karta konkretnego zapytania.

4. NLWeb — strona, którą można odpytywać językiem naturalnym

Czym jest NLWeb?

NLWeb jest otwartym projektem rozwijanym przez Microsoft, którego celem jest umożliwienie tworzenia naturalnych, konwersacyjnych interfejsów do zawartości stron internetowych. Użytkownik lub agent może zadać stronie pytanie zwykłym językiem, zamiast ręcznie przechodzić przez strukturę kategorii, filtrów i podstron.

NLWeb wykorzystuje dane, które strona już publikuje, w tym Schema.org, RSS i inne formaty półstrukturalne. Każda instancja NLWeb może działać także jako serwer MCP, dzięki czemu zawartość witryny może zostać udostępniona zewnętrznym agentom.

Formalna specyfikacja NLWeb przewiduje między innymi dwa rodzaje punktów dostępu:

Ask — zadanie pytania i otrzymanie ustrukturyzowanej odpowiedzi;
Who — ustalenie, który agent lub system może odpowiedzieć na pytanie.

Przykład B2B

Zamiast przechodzić przez kilkanaście podstron, użytkownik może zapytać:

Potrzebuję folii stretch maszynowej 17 mikronów, dostępnej z magazynu, z dostawą do 48 godzin na terenie Polski. Co możecie zaoferować?

NLWeb może:

rozpoznać kategorię;
przeszukać dane produktowe;
odnaleźć właściwą A2A Product Card;
zwrócić produkt, parametry, cenę i warunki;
wskazać informacje wymagane do przygotowania RFQ;
uruchomić narzędzie MCP sprawdzające bieżącą dostępność;
przekazać zapytanie agentowi handlowemu.

NLWeb a answer engines

Dobrze przygotowane dane dla NLWeb mogą jednocześnie wspierać:

klasyczne SEO;
answer engine optimization;
generowanie odpowiedzi na stronie;
wyszukiwanie semantyczne;
obsługę agentów zewnętrznych;
tworzenie zapytań ofertowych.

Podstawą pozostają jednak prawidłowe dane źródłowe. NLWeb nie naprawi niejednoznacznej nazwy produktu, brakującej ceny, nieaktualnej dostępności ani pomieszanych jednostek.

5. AGENTS.md — instrukcja dla agentów programistycznych

AGENTS.md jest prostym, otwartym formatem pliku Markdown przeznaczonym dla agentów pracujących z kodem. Można traktować go jako README dla agentów programistycznych.

Plik może zawierać:

sposób uruchomienia projektu;
polecenia budowania i testowania;
strukturę repozytorium;
reguły kodowania;
wymagania bezpieczeństwa;
instrukcje dotyczące commitów i pull requestów;
ograniczenia dotyczące wdrożeń.

Format jest używany przez ponad 60 tysięcy projektów open source i znajduje się pod opieką Agentic AI Foundation działającej w ramach Linux Foundation. AGENTS.md nie ma wymaganego schematu — jest zwykłym plikiem Markdown, a w większych repozytoriach mogą działać pliki zagnieżdżone dla poszczególnych modułów.

Czego AGENTS.md nie należy robić?

AGENTS.md nie jest:

kartą produktu;
plikiem do pozycjonowania strony;
publiczną ofertą firmy;
odpowiednikiem A2A Agent Card;
protokołem komunikacji handlowej;
formatem RFQ.

Jego rola w agentic commerce jest pośrednia. Pomaga zespołom technicznym i agentom programistycznym prawidłowo rozwijać:

serwer MCP;
integrację A2A;
endpoint NLWeb;
generator A2A Cards;
walidator Direct RFQ;
synchronizację z ERP, CRM lub PIM.

6. Jak wszystkie warstwy współpracują?

Powstającą architekturę można przedstawić jako kilka współpracujących poziomów.

Warstwa 1: treść i dane źródłowe

Obejmuje:

semantyczny HTML;
podstrony produktów;
strony firmowe;
dokumentację;
FAQ;
pliki techniczne;
dane Schema.org;
feedy produktowe.

Schema.org udostępnia między innymi typy Product, ProductModel, Offer i Organization, pozwalające opisać produkt, identyfikatory, warianty, cenę, dostawę i podmiot składający ofertę.

Warstwa 2: konwersacyjny dostęp do strony

NLWeb pozwala człowiekowi lub agentowi odpytywać zawartość strony językiem naturalnym.

Warstwa 3: dostęp do aktualnych danych i działań

MCP pozwala sprawdzić dane w ERP, CRM, magazynie lub systemie ofertowym oraz wykonać dozwolone operacje.

Warstwa 4: komunikacja agent–agent

A2A umożliwia agentowi kupującego komunikację z agentem sprzedawcy, producenta, operatora logistycznego albo serwisu.

Warstwa 5: semantyka B2B

A2A Card opisuje dostawcę, produkt, ofertę i możliwości wykonawcze.

Direct RFQ opisuje potrzebę kupującego, wymagania, ilość, termin, kryteria i oczekiwany rezultat.

Warstwa 6: transakcja

W określonych scenariuszach mogą zostać wykorzystane protokoły handlowe i płatnicze, takie jak Universal Commerce Protocol lub Agentic Commerce Protocol. UCP definiuje wspólny język dla agentów, przedsiębiorstw i dostawców płatności, natomiast ACP jest rozwijanym przez OpenAI i Stripe standardem łączenia kupujących, agentów i sprzedawców w procesie zakupu; na 16 lipca 2026 r. specyfikacja ACP pozostaje oznaczona jako beta.

Protokoły te są szczególnie naturalne dla handlu detalicznego i standardowego checkoutu. W przemysłowym B2B przed transakcją często trzeba jeszcze przejść przez kwalifikację techniczną, negocjacje, zatwierdzenie dokumentacji, testy, ustalenie logistyki, finansowania, instalacji albo serwisu. Dlatego Direct RFQ nie powinien być utożsamiany z checkoutem.

7. A2A Card — standard opisu podaży B2B

A2A Card należy traktować jako rodzinę kart, a nie jeden uniwersalny dokument.

7.1. A2A Business Card

Opisuje firmę jako potencjalnego partnera handlowego.

Minimalny zakres:

jednoznaczna nazwa firmy;
nazwa prawna;
identyfikator firmy, np. NIP lub VAT ID;
kraj i lokalizacje;
obsługiwane rynki;
branże;
główne kategorie oferty;
rola w łańcuchu dostaw;
producent, dystrybutor, integrator, serwis lub wykonawca;
języki obsługi;
dane kontaktowe;
godziny pracy;
czas odpowiedzi;
dokumenty i certyfikaty;
obszar dostaw;
możliwości serwisowe;
adresy stron i dokumentacji;
data aktualizacji danych.

7.2. A2A Product Card

Opisuje konkretny produkt i dostępną ofertę.

Powinna zawierać:

jednoznaczną nazwę;
producenta;
markę;
model;
wariant;
SKU lub kod produktu;
kategorię;
zastosowania;
ograniczenia;
komplet parametrów;
jednostki;
materiały;
kompatybilność;
zakres dostawy;
opcje;
cenę albo zasady kalkulacji;
informację netto lub brutto;
walutę;
jednostkę cenową;
datę ważności ceny;
MOQ;
jednostkę zamówienia;
dostępność;
termin dostawy;
koszt dostawy;
warunki płatności;
gwarancję;
serwis;
dokumentację;
wymagane dane do kwalifikacji;
identyfikator Direct RFQ;
datę ostatniej weryfikacji.

7.3. A2A Capability Card

Opisuje nie gotowy produkt, lecz zdolność firmy do wykonania określonego zadania.

Przykłady:

produkcja elementów na zamówienie;
pakowanie kontraktowe;
obróbka CNC;
druk;
transport;
integracja linii;
serwis;
wynajem;
testy;
regeneracja urządzeń.

Karta powinna określać:

rodzaj procesu;
dane wejściowe;
możliwe rezultaty;
obsługiwane materiały;
zakres wymiarów;
tolerancje;
minimalne i maksymalne partie;
wydajność;
moce produkcyjne;
lokalizację wykonania;
termin realizacji;
system jakości;
wymagane dane wejściowe;
ograniczenia;
dostępne testy;
zasady wyceny.

8. Direct RFQ — standard opisu zapytania B2B

Direct RFQ jest warstwą, która przekształca ogólną intencję:

Potrzebuję folii do owijania palet.

w zapytanie możliwe do zakwalifikowania i wyceny:

Potrzebujemy 30 rolek folii stretch maszynowej o grubości 17 µm, dostawa do kodu 05-xxx, termin maksymalnie 48 godzin roboczych, prosimy o cenę netto, koszt transportu, dostępność i ważność oferty.

Minimalna struktura Direct RFQ Card

Identyfikacja

rfqId;
data utworzenia;
data ważności;
status;
wersja dokumentu.

Przedmiot zapytania

nazwa produktu lub usługi;
kategoria;
kod albo oczekiwany odpowiednik;
ilość;
jednostka;
wymagane parametry;
dopuszczalne tolerancje;
wymagane warianty.

Zastosowanie

cel zakupu;
środowisko pracy;
produkt pakowany lub przetwarzany;
kompatybilna maszyna;
ograniczenia techniczne;
obecnie używane rozwiązanie.

Warunki handlowe

oczekiwana waluta;
cena netto lub brutto;
oczekiwany sposób wyceny;
termin ważności oferty;
warunki płatności;
preferowane Incoterms;
zapotrzebowanie jednorazowe lub cykliczne.

Logistyka

miejsce dostawy;
kod pocztowy;
oczekiwany termin;
sposób rozładunku;
ograniczenia transportowe;
wymagania dotyczące pakowania.

Dokumentacja

deklaracje;
certyfikaty;
specyfikacje;
karty charakterystyki;
świadectwa jakości;
dokumenty regulacyjne;
wymagania branżowe.

Kryteria oceny

zgodność techniczna;
cena;
termin;
dostępność;
serwis;
gwarancja;
dokumentacja;
całkowity koszt posiadania;
doświadczenie dostawcy.

Mandat i zatwierdzenie

czy agent może tylko zebrać informacje;
czy może wysłać RFQ;
czy może negocjować;
czy może zaakceptować ofertę;
jaka kwota wymaga zgody człowieka;
kto podejmuje ostateczną decyzję.

9. Przykład: A2A Product Card dla produktu magazynowego

Poniższy zapis jest uproszczonym, autorskim przykładem struktury. Nie jest elementem oficjalnej specyfikacji A2A.

{
  "cardType": "A2AProductCard",
  "cardVersion": "1.0-draft",
  "productId": "infinity-ultra-17um",
  "name": "Folia stretch maszynowa Infinity Ultra 17 µm",
  "category": "Machine stretch film",
  "thickness": {
    "value": 17,
    "unit": "micrometre"
  },
  "availability": {
    "status": "in_stock",
    "source": "warehouse"
  },
  "price": {
    "value": 12.80,
    "currency": "PLN",
    "unit": "kg",
    "taxStatus": "net",
    "validThrough": "2026-07-31"
  },
  "orderConfiguration": {
    "shippingUnit": "pallet",
    "rollsPerPallet": 30
  },
  "delivery": {
    "country": "PL",
    "leadTime": {
      "value": 48,
      "unit": "business_hour"
    },
    "palletShippingPrice": {
      "value": 210,
      "currency": "PLN",
      "taxStatus": "net"
    }
  },
  "rfq": {
    "supported": true,
    "requiredFields": [
      "quantity",
      "deliveryPostalCode",
      "companyName",
      "contactEmail"
    ]
  },
  "lastVerified": "2026-07-16"
}

Najważniejsze nie jest samo użycie JSON. Istotne jest to, że każda wartość ma jednoznaczne znaczenie:

cena ma walutę;
cena ma jednostkę;
wiadomo, że jest ceną netto;
wskazano datę ważności;
dostępność nie jest ogólnym hasłem;
termin dostawy ma określoną jednostkę;
koszt transportu jest przypisany do konkretnej jednostki logistycznej;
agent wie, jakich danych potrzebuje do przygotowania RFQ.

10. Przykładowy przebieg agentowego RFQ

Etap 1: wykrycie produktu

Agent kupującego pyta stronę poprzez NLWeb:

Znajdź folię stretch maszynową 17 µm dostępną w Polsce z dostawą do 48 godzin.

Etap 2: odpowiedź z danych strony

NLWeb odnajduje A2A Product Card i zwraca:

nazwę produktu;
grubość;
cenę;
ważność ceny;
stan dostępności;
warunki wysyłki.

Etap 3: sprawdzenie aktualności

Agent wywołuje przez MCP:

check_inventory;
get_current_price;
calculate_shipping.

Etap 4: identyfikacja agenta dostawcy

Agent kupującego pobiera A2A Agent Card dostawcy i sprawdza, czy agent obsługuje umiejętność:

prepare_direct_rfq_quote

Etap 5: przesłanie Direct RFQ Card

Agent przekazuje:

oczekiwaną ilość;
miejsce dostawy;
termin;
dane firmy;
wymagania dokumentacyjne.

Etap 6: kwalifikacja

Agent dostawcy sprawdza kompletność danych. Jeżeli brakuje kodu pocztowego lub ilości, zwraca status input_required.

Etap 7: przygotowanie oferty

Agent dostawcy pobiera z systemów:

cenę;
stan magazynowy;
koszt transportu;
termin;
dokumenty.

Następnie generuje ustrukturyzowaną odpowiedź.

Etap 8: zatwierdzenie

Agent kupującego przedstawia wynik człowiekowi. Bez wyraźnego mandatu nie powinien samodzielnie składać wiążącego zamówienia.

11. Direct RFQ jako rozszerzenie A2A

Oficjalny protokół A2A pozwala tworzyć rozszerzenia domenowe. Rozszerzenia mogą wprowadzać dodatkowe struktury danych, wymagania, metody, zachowania i cykle statusów. Agent deklaruje obsługę rozszerzenia w swojej Agent Card, a klient może zdecydować, czy chce z niego skorzystać.

Docelowo Direct RFQ może zostać opisany jako rozszerzenie A2A obejmujące:

schemat RFQ;
statusy kwalifikacji;
pytania uzupełniające;
odpowiedź handlową;
wersjonowanie oferty;
odrzucenie;
kontrpropozycję;
ważność warunków;
załączniki;
zatwierdzenie człowieka;
ślad audytowy.

Przykładowe statusy procesu:

RFQ_DRAFT;
RFQ_SUBMITTED;
RFQ_INPUT_REQUIRED;
RFQ_QUALIFIED;
RFQ_REJECTED;
QUOTE_IN_PREPARATION;
QUOTE_READY;
QUOTE_EXPIRED;
HUMAN_APPROVAL_REQUIRED;
ORDER_READY.

A2A pozostawałby protokołem transportu i koordynacji, a Direct RFQ dostarczałby semantykę procesu zakupowego B2B.

12. Poziomy gotowości firmy B2B

Nie każda firma musi od razu budować serwer MCP i własnego agenta. Wdrożenie można podzielić na poziomy.

Poziom 1: Answer Engine Ready

Firma posiada:

jednoznaczne strony;
odpowiedzi na rzeczywiste pytania;
aktualne dane;
źródła i dokumenty;
semantyczne nagłówki;
Schema.org;
indeksowalne treści.

Agent może znaleźć informacje, ale nie zawsze może je w pełni zakwalifikować.

Poziom 2: Agent Qualifiable

Firma publikuje A2A Business Card, Product Card lub Capability Card.

Agent potrafi ustalić:

czym jest produkt;
kto go oferuje;
czy odpowiada wymaganiom;
jakie są ograniczenia;
jakie dane są jeszcze potrzebne.

Poziom 3: Direct RFQ Ready

Dostępne są:

wymagane pola RFQ;
wzór zapytania;
identyfikator produktu;
kryteria kwalifikacji;
jednoznaczny kanał przekazania;
oczekiwany czas odpowiedzi.

Agent może przygotować kompletne zapytanie bez długiej wymiany ogólnych wiadomości.

Poziom 4: MCP Connected

Agent może pobierać aktualne dane i korzystać z narzędzi:

magazynu;
kalkulatora;
dokumentacji;
CRM;
systemu ofertowego.

Poziom 5: A2A Enabled

Firma udostępnia agenta posiadającego A2A Agent Card i obsługującego zewnętrzne zadania.

Poziom 6: Transactional

Agent może w granicach mandatu:

negocjować;
rezerwować;
akceptować;
składać zamówienie;
inicjować płatność;
śledzić realizację.

Dopiero ten ostatni poziom wymaga pełnej infrastruktury transakcyjnej, uwierzytelniania, polityk ryzyka i formalnego mandatu.

13. Wdrożenie krok po kroku

Krok 1. Uporządkuj encje

Należy jednoznacznie rozdzielić:

firmę;
markę;
producenta;
dystrybutora;
produkt;
model;
wariant;
usługę;
zdolność wykonawczą;
ofertę;
dokument;
osobę kontaktową;
agenta.

Każda encja powinna posiadać stabilny identyfikator i adres kanoniczny.

Krok 2. Uporządkuj jednostki i parametry

Nie należy mieszać:

sztuk z kilogramami;
ceny rolki z ceną kilograma;
godzin z dniami roboczymi;
wartości netto z brutto;
dostępności magazynowej z terminem produkcji;
MOQ z jednostką logistyczną.

Krok 3. Rozdziel dane trwałe i czasowe

Dane trwałe:

producent;
model;
materiał;
wymiary;
zastosowania.

Dane czasowe:

cena;
promocja;
stan magazynowy;
termin;
koszt transportu;
ważność oferty.

Dane czasowe muszą mieć datę ostatniej weryfikacji i, gdy jest to możliwe, datę ważności.

Krok 4. Zbuduj karty A2A

Najpierw można opublikować statyczne wersje:

A2A Business Card;
A2A Product Card;
A2A Capability Card.

Nie trzeba od razu posiadać API. Statyczna, wersjonowana karta jest lepsza niż nieustrukturyzowany opis rozproszony po wielu podstronach.

Krok 5. Zbuduj Direct RFQ Card

Dla każdego produktu lub kategorii należy określić:

które dane są konieczne;
które są opcjonalne;
które można wywnioskować;
których nie wolno zgadywać;
kiedy wymagany jest kontakt z człowiekiem.

Krok 6. Połącz dane ze stroną

Karta nie powinna być odrębnym, zapomnianym plikiem. Dane powinny pochodzić z jednego źródła i zasilać:

podstronę produktu;
Schema.org;
kartę A2A;
formularz RFQ;
feed;
NLWeb;
MCP.

Krok 7. Dodaj NLWeb

NLWeb jest szczególnie użyteczny dla firm mających:

rozbudowane katalogi;
wiele dokumentów;
liczne warianty;
treści techniczne;
skomplikowaną nawigację;
wiele powiązanych serwisów.

Krok 8. Dodaj MCP

MCP powinien pojawić się wtedy, gdy agent ma pobierać dane aktualne albo wykonywać działania.

Na początek wystarczą narzędzia tylko do odczytu:

sprawdzenie stanu;
pobranie specyfikacji;
pobranie dokumentu;
kalkulacja kosztu;
sprawdzenie statusu.

Dopiero później należy dodawać operacje zapisujące dane.

Krok 9. Dodaj agenta A2A

Agent dostawcy powinien mieć ograniczony, jasno opisany zakres:

kwalifikowanie RFQ;
zadawanie pytań;
pobieranie informacji;
przygotowanie projektu oferty;
przekazywanie spraw do handlowca.

Krok 10. Zbuduj kontrolę i audyt

Każde działanie powinno być możliwe do odtworzenia:

kto zainicjował zadanie;
w czyim imieniu działał agent;
jakich danych użył;
jaka wersja karty obowiązywała;
które narzędzia wywołał;
kto zatwierdził rezultat;
kiedy oferta wygasła.

14. Najczęstsze błędy

Publikowanie samego opisu marketingowego

Hasła takie jak „najwyższa jakość”, „szybka dostawa” albo „atrakcyjna cena” nie pozwalają agentowi zakwalifikować oferty.

Brak daty ważności

Cena bez daty ważności może zostać wykorzystana przez agenta długo po zakończeniu promocji.

Brak jednostki ceny

12,80 PLN nie informuje, czy jest to cena za rolkę, kilogram, metr, opakowanie czy paletę.

Mieszanie produktu z ofertą

Produkt może mieć stałe parametry, ale wiele ofert zależnych od dostawcy, ilości, rynku i daty.

Traktowanie A2A Agent Card jak katalogu produktów

Oficjalna Agent Card powinna opisywać możliwości agenta. Szczegółowe dane handlowe powinny znajdować się w A2A Product Cards, zasobach MCP lub innych źródłach biznesowych.

Udostępnienie zbyt szerokich narzędzi MCP

Agent sprawdzający produkt nie powinien automatycznie otrzymywać możliwości zmiany cen, rezerwowania całego magazynu lub odczytywania danych wszystkich klientów.

Automatyzowanie procesu przed uporządkowaniem danych

Agent nie rozwiąże problemu sprzecznych cen, różnych nazw tego samego produktu, nieaktualnych PDF-ów i niespójnych jednostek. Automatyzacja przyspieszy również błędy.

15. Co oznacza to dla nowego SEO, AEO i A2O?

W agentic web widoczność nie kończy się na znalezieniu adresu strony.

Firma musi przejść przez kolejne etapy:

Findable — agent odnajduje firmę lub produkt.
Understandable — rozumie, czym jest oferta.
Comparable — potrafi zestawić ją z alternatywami.
Trustworthy — widzi źródło, datę i dowody.
Executable — wie, jakie działanie może wykonać.
Governable — zna ograniczenia, mandat i wymagane zatwierdzenia.

Klasyczne SEO wspiera głównie znajdowalność. AEO wspiera udzielanie odpowiedzi. A2O — Agent-to-Agent Optimization — powinno dodatkowo przygotowywać firmę do kwalifikacji, komunikacji i działania pomiędzy agentami.

W tym modelu:

Schema.org zapewnia podstawową semantykę strony;
NLWeb zapewnia konwersacyjne odpytywanie;
MCP zapewnia dostęp do danych i narzędzi;
A2A zapewnia komunikację agentów;
A2A Card zapewnia semantykę podaży B2B;
Direct RFQ zapewnia semantykę popytu i zapytania;
UCP lub ACP mogą obsługiwać wybrane elementy transakcyjne;
człowiek nadal określa mandat, polityki i granice działania.

Podsumowanie

MCP, A2A, NLWeb i AGENTS.md tworzą ważne elementy infrastruktury agentic web, ale nie zastępują dobrych danych produktowych ani procesów handlowych.

MCP odpowiada na pytanie:

Z jakich danych i narzędzi agent może skorzystać?

A2A odpowiada:

Jak jeden agent może zlecić zadanie innemu agentowi?

NLWeb odpowiada:

Jak człowiek lub agent może zapytać stronę o jej zawartość?

AGENTS.md odpowiada:

Jak agent programistyczny powinien pracować z kodem projektu?

A2A Card odpowiada:

Co firma może zaoferować, na jakich warunkach i z jakimi ograniczeniami?

Direct RFQ odpowiada:

Czego potrzebuje kupujący i jakie dane są konieczne do przygotowania prawidłowej oferty?

To właśnie połączenie otwartych protokołów technicznych z jednoznacznymi standardami danych handlowych może stworzyć praktyczną infrastrukturę agentic commerce dla B2B.

Firma nie staje się gotowa na handel agentowy tylko dlatego, że posiada chatbota albo API. Staje się gotowa wtedy, gdy jej produkty, oferty, zdolności, warunki i procesy mogą zostać bezpiecznie znalezione, zrozumiane, zakwalifikowane, porównane i obsłużone przez człowieka oraz przez upoważnionego agenta AI.

Potzrebujesz opisać swoje produkty B2B pod AI answer engines, A2A agentic commerce? Napisz do nas:

kontakt@salesbot.pl

B2B Direct RFQ A2A Agentic commerce answer engines