Przez trzy dekady dobry serwis internetowy odpowiadał głównie na jedno pytanie: czy człowiek potrafi znaleźć informację, zrozumieć ją i kliknąć we właściwy przycisk?
To założenie właśnie przestaje wystarczać.
Drugim klientem Internetu staje się agent AI. Nie tylko czyta stronę. Dostaje cel, porównuje oferty, dobiera narzędzia, wywołuje API, komunikuje się z innymi agentami, a coraz częściej może także zainicjować zakup lub płatność.
Nie oznacza to, że dotychczasowy Web był „dla ludzi”, a teraz trzeba zbudować drugi Internet od zera. Maszyny korzystają z sieci od dawna. robots.txt ma historię sięgającą 1994 r., JSON-LD opisuje dane w sposób czytelny maszynowo, a OpenAPI pozwala formalnie opisać możliwości HTTP API.
Nowością jest coś innego: maszyna przestaje być tylko odbiorcą informacji i staje się wykonawcą działań.
Właśnie dlatego ważniejsza od hasła „Internet dla maszyn” jest inna sekwencja:
discovery → structured context → actions → identity and delegation → payments → audit
To warstwa wykonawcza dla agentów. I jej budowa już trwa.
Problemem nie jest to, czy AI potrafi przeczytać stronę
Dzisiejszy serwis WWW zwykle ma backend, który przechowuje stan i wykonuje operacje, oraz frontend, który tłumaczy wszystko na tekst, formularze, menu, kolory i przyciski.
Dla człowieka to naturalne. Dla agenta jest to często niepotrzebny objazd.
Jeżeli agent ma zarezerwować pokój, może otworzyć stronę, rozpoznać kalendarz, znaleźć daty, kliknąć odpowiednie kontrolki, wybrać wariant, przejść dalej i sprawdzić wynik. To UI automation. Działa, ale jest kruche. Wystarczy zmiana layoutu, niejednoznaczna etykieta albo element ukryty za modalem.
Alternatywą jest semantic execution. Zamiast zmuszać model do odgadywania, co oznacza przycisk, serwis może udostępnić działanie w rodzaju book_room(check_in, check_out, room_type) wraz z typami argumentów, ograniczeniami i opisem skutków.
To nie jest kosmetyczna różnica. To zmiana sposobu, w jaki cyfrowy klient korzysta z produktu.
WebMCP jest jedną z prób wniesienia takiej semantycznej warstwy bezpośrednio do przeglądarki. Strona może wystawić agentowi ustrukturyzowane narzędzia, zamiast liczyć wyłącznie na analizę interfejsu graficznego. MCP robi podobną rzecz na szerszym poziomie, łącząc aplikacje AI z narzędziami, danymi i usługami. OpenAPI pozostaje natomiast dojrzałym sposobem opisywania samych API.
Ciekawy sygnał daje badanie „Designing Agent-Ready Websites for AI Web Agents” z 2026 r. W kontrolowanym prototypie e-commerce wariant przygotowany pod agentów osiągnął 89,3 proc. ścisłego sukcesu, wobec 49,3 proc. dla wersji bazowej. Średnia liczba kroków spadła z 9,31 do 6,49.
Wynik brzmi mocno, ale trzeba zachować proporcje. Badanie obejmowało jeden prototyp, pięć zadań, trzy modele i 300 uruchomień. To argument za dalszym testowaniem, nie dowód, że każda witryna po dodaniu warstwy agentowej podwoi skuteczność automatyzacji.
Strona nie zniknie. Powstanie drugi interfejs
Najbardziej prawdopodobny kierunek nie wygląda jak osobny „Internet agentów” działający obok normalnego Webu.
Bardziej sensowny jest model dwóch interfejsów do tego samego systemu.
Człowiek dostaje HTML, CSS, obrazy, formularze i wygodny UX. Agent dostaje dane strukturalne, schematy, operacje, polityki dostępu, aktualną cenę, status i jednoznaczny wynik działania. Obie warstwy korzystają z tego samego backendu i tego samego źródła prawdy.
To ma duże konsekwencje biznesowe. API przestaje być dodatkiem „dla integratorów”. Staje się częścią produktu.
Agent nie musi znać marki, otwierać strony głównej ani oglądać baneru sprzedażowego. Może szukać możliwości: „znajdź nocleg z parkingiem do 600 zł, z bezpłatnym odwołaniem do jutra”, „kup 10 sztuk tego komponentu z dostawą w 48 godzin”, „znajdź dane, które kosztują mniej niż 0,05 USD za zapytanie”.
W takim świecie wygrywa nie tylko firma z najlepszym UI. Wygrywa firma, której usługa jest jednoznaczna dla maszyny.
Dlatego odpowiednikiem SEO dla agentów nie będzie wyłącznie pisanie treści „pod modele”. Znacznie ważniejsza może okazać się semantyczna kontraktowość: stabilne identyfikatory, dobrze opisane parametry, jawne ceny, dostępność, czas ważności danych, skutki operacji, możliwość ponowienia lub cofnięcia działania i wynik nadający się do automatycznej walidacji.
MCP, A2A i WebMCP nie rozwiązują tego samego problemu
Wokół agentów pojawiło się już tyle skrótów, że łatwo uznać je za konkurencyjne standardy walczące o tę samą warstwę. To mylące.
OpenAPI opisuje możliwości HTTP API. MCP łączy model lub aplikację agentową z narzędziami i danymi. A2A służy komunikacji pomiędzy agentami. WebMCP próbuje udostępniać agentowi działania osadzone w aktywnej stronie internetowej.
Te technologie mogą działać obok siebie.
MCP ma dziś szczególnie mocne momentum. Specyfikacja jest aktywnie rozwijana, projekt został przekazany do Agentic AI Foundation w ekosystemie Linux Foundation, a duże firmy budują na nim integracje. Dobry przykład daje Visa, która udostępnia zdalny serwer MCP jako most do własnych usług płatniczych.
To dobrze pokazuje rolę protokołu: MCP nie zastępuje API, bazy danych, OAuth ani systemu płatniczego. Jest warstwą, przez którą agent może korzystać z istniejących możliwości.
A2A rozwiązuje inny problem. Agent ma znaleźć innego agenta, zrozumieć jego możliwości i wymieniać z nim zadania lub wyniki. W 2026 r. projekt osiągnął wersję 1.0 i jest rozwijany w Linux Foundation.
Najwięcej ostrożności wymaga WebMCP. Chrome opisuje go jako proponowany standard webowy, ale dokumentacja W3C Community Group ma status Draft Community Group Report. Nie jest standardem W3C i nie znajduje się na formalnym standards track.
To realny i interesujący eksperyment, ale jeszcze nie „nowy standard Internetu”.
Najtrudniejsze pytanie brzmi: kto pozwolił agentowi to zrobić?
Wywołanie funkcji jest stosunkowo łatwe. Znacznie trudniej ustalić, czy agent miał prawo ją wywołać.
W tradycyjnym systemie pytamy zwykle, który użytkownik jest zalogowany i jakie uprawnienia ma aplikacja. Przy autonomicznym agencie pojawia się więcej poziomów: właściciel decyzji, aplikacja agentowa, konkretne uruchomienie agenta, zakres delegacji i wreszcie konkretna intencja użytkownika.
To ostatnie jest kluczowe.
Wyobraźmy sobie polecenie: „kup rower do 800 euro, tylko od sprzedawcy z darmowym zwrotem”. Sam fakt, że agent ma dostęp do płatności, nie powinien oznaczać prawa do kupienia dowolnego roweru za dowolną kwotę. System potrzebuje dowodu, że finalna transakcja mieści się w granicach zgody.
Właśnie w tę stronę idą Visa, Mastercard, Google i FIDO. Pojawiają się agent-specific payment tokens, passkeys, Payment Instructions, AP2 i Verifiable Intent. Wspólną ideą jest oddzielenie tożsamości od delegowanej intencji oraz możliwość kryptograficznego udowodnienia, co użytkownik faktycznie zaakceptował.
Nie ma jednak jednego gotowego „paszportu dla agentów AI”. AP2 i Verifiable Intent są rozwijane, a FIDO prowadzi prace standaryzacyjne. W3C Verifiable Credentials i OpenID for Verifiable Credentials dostarczają elementów infrastruktury poświadczeń, ale same nie rozwiązują całego problemu.
Docelowo potrzebny jest raczej łańcuch zaufania:
człowiek lub firma → aplikacja agentowa → konkretne uruchomienie → delegowane uprawnienie → podpisana intencja → wykonana operacja → potwierdzenie
Dopiero taki model nadaje się do świata, w którym agent nie tylko czyta kalendarz, ale może kupować, rezerwować, podpisywać lub rozliczać.
AI zaczyna płacić, ale pod tym hasłem kryją się różne rynki
„Płatności wykonywane przez AI” brzmią jak jedna technologia. W praktyce rozwijają się co najmniej dwa bardzo różne modele.
Pierwszy to agent jako reprezentant człowieka w handlu. Protokoły takie jak Agentic Commerce Protocol i Universal Commerce Protocol próbują opisać katalog, produkt, wariant, cenę, stan magazynowy, dostawę, zwroty, podatki i checkout w formie, którą agent może obsłużyć bez odtwarzania całego procesu z pikseli.
Tutaj pieniądze nadal należą do człowieka lub firmy. Agent działa na podstawie delegowanych uprawnień, a istniejące sieci płatnicze pozostają w centrum rozliczenia.
Visa rozwija Intelligent Commerce z tokenizacją, uwierzytelnieniem i instrukcjami płatniczymi. Sama zaznacza jednak, że rozwiązanie jest rozwijane i wdrażane oraz nie musi być dostępne na wszystkich rynkach.
Mastercard poinformował w czerwcu 2026 r. o uruchomieniu infrastruktury Agent Pay na poziomie sieciowym w Europie i o kontrolowanych, rzeczywistych transakcjach agentowych z udziałem europejskich banków, w tym mBanku i Pekao. To ważny etap, ale nadal nie jest dowodem masowej adopcji.
Drugi model jest jeszcze ciekawszy: agent kupuje pojedynczy zasób cyfrowy dokładnie wtedy, kiedy go potrzebuje.
Machine Payments Protocol wykorzystuje mechanizm HTTP 402 Payment Required. Usługa może odpowiedzieć na żądanie ceną i payment challenge. Agent płaci, ponawia żądanie z dowodem i otrzymuje API call, dataset albo jednostkę compute.
Ekonomicznie to spora zmiana.
Dzisiejsze API często wymagają rejestracji, klucza, abonamentu lub wcześniejszej relacji billingowej. W modelu machine payments możliwy staje się prostszy przepływ:
agent potrzebuje danych → widzi cenę 0,01 USD → płaci → pobiera wynik
MPP nie jest jednak ukończonym standardem IETF. Projekt prowadzi do Internet-Draftu, nie opublikowanego RFC. Równolegle rozwija się x402, które realizuje podobną ideę, szczególnie w środowisku crypto-native. Sam fakt, że Stripe wspiera oba kierunki, dobrze pokazuje stan rynku: infrastruktura powstaje, ale zwycięzca nie został wybrany.
Gdy agent może działać, bezpieczeństwo staje się trudniejsze
Paradoks agentowego Webu polega na tym, że największym zagrożeniem nie musi być agent, który nie potrafi znaleźć przycisku.
Groźniejszy jest agent, który dostał idealnie opisane narzędzie i wykonał je na podstawie złego albo zmanipulowanego kontekstu.
Materiały WebMCP zwracają uwagę między innymi na tool poisoning, czyli sytuację, w której opis narzędzia próbuje nakłonić agenta do niewłaściwego działania. Sam MCP jasno wskazuje, że mechanizmy protokołu nie zastępują zgody, autoryzacji, kontroli dostępu i ochrony danych.
To fundamentalne.
W klasycznym interfejsie człowiek widzi ekran przed ważną operacją. W interfejsie dla agenta semantyczne wywołanie może od razu wywołać skutek: wysłać wiadomość, skasować rekord, zatwierdzić rezerwację albo wydać pieniądze.
Dlatego „agent-ready” nie może oznaczać „mamy serwer MCP”.
Dojrzała usługa będzie potrzebować mocnych schematów wejścia i wyjścia, rozdzielenia operacji odczytowych od zmieniających stan, minimalnych zakresów uprawnień, krótkotrwałych credentiali, idempotency, limitów kwotowych, dodatkowego potwierdzenia dla działań wysokiego ryzyka i pełnego audytu.
Po fakcie trzeba móc odpowiedzieć: kto uruchomił agenta, jakie miał uprawnienia, na jakiej podstawie podjął decyzję, co wykonał i jaki był rezultat.
Bot management zaczyna zmieniać się w agent trust management.
Co firmy powinny zrobić już teraz
Nie trzeba czekać na jeden zwycięski protokół. Najważniejsze przygotowania są znacznie bardziej przyziemne.
Firma z dobrze zaprojektowanym API, aktualną dokumentacją OpenAPI, stabilnymi identyfikatorami produktów, uporządkowanym modelem danych, jawnymi cenami i stanami, sensownym OAuth oraz rejestrem operacji jest w dużo lepszej pozycji niż firma, której logika biznesowa istnieje wyłącznie w zachowaniu frontendu.
Kolejny krok to wystawianie funkcji w sposób zrozumiały dla agentów, z jednoznacznym opisem skutków. Potem dochodzą delegacja, potwierdzanie działań wysokiego ryzyka, płatności i audyt.
Można to zapisać jako prostą ewolucję:
API-first → agent-readable → agent-actionable → agent-authorized → agent-payable → agent-auditable
To moim zdaniem najważniejszy wniosek biznesowy z obecnego etapu.
Przewaga nie będzie polegała na tym, że firma „ma AI”. Przewagę może dać fakt, że jej produkty i operacje są możliwe do bezpiecznego odkrycia, zrozumienia, porównania i wykonania przez cudze systemy AI.
Internet nie będzie mniej ludzki. Będzie miał więcej niż jednego klienta
Nie spodziewam się jednego „HTTP dla agentów”, który zunifikuje cały rynek. Bardziej prawdopodobny jest stos kilku współpracujących warstw.
MCP i klasyczne API mogą obsługiwać dostęp do narzędzi. A2A może odpowiadać za komunikację agentów. OAuth, passkeys i poświadczenia będą budować delegację i zaufanie. Protokoły commerce opiszą zakup, a karty, przelewy, PSP i stablecoiny pozostaną warstwą rozliczeniową.
Nie spodziewam się też zniknięcia stron WWW. Człowiek nadal będzie potrzebował obrazu, tekstu, kontekstu, emocji i interfejsu. Agent potrzebuje czegoś innego: kontraktu możliwości.
Największa zmiana polega więc nie na tym, że Internet trzeba wyrzucić i zbudować od nowa.
Trzeba przestać zakładać, że każdy cyfrowy klient kończy swoją podróż na stronie wyświetlonej człowiekowi.
Przez lata sieć uczyła maszyny, jak znaleźć informację. Teraz zaczyna uczyć je, jak bezpiecznie wykonać działanie.
I to może okazać się znacznie większą zmianą niż kolejna generacja chatbotów.
Źródła
- RFC 9309, Robots Exclusion Protocol
https://www.rfc-editor.org/rfc/rfc9309.html - OpenAPI Specification, OpenAPI Initiative
https://github.com/OAI/OpenAPI-Specification - JSON-LD 1.1, W3C Recommendation
https://www.w3.org/TR/json-ld11/ - Tim Berners-Lee, Linked Data
https://www.w3.org/DesignIssues/LinkedData.html - Model Context Protocol, Specification 2026-07-28
https://modelcontextprotocol.io/specification/2026-07-28 - Model Context Protocol, Introduction
https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro - MCP joins the Agentic AI Foundation
https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/ - Agent2Agent Protocol Specification
https://a2a-protocol.org/latest/specification/ - Linux Foundation, A2A adoption and 1.0
https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year - Chrome for Developers, WebMCP
https://developer.chrome.com/docs/ai/webmcp - W3C Community Group, WebMCP Technical Notes
https://w3c-cg.github.io/aikr/webMCP/webmcp-technical-notes.html - Elnaffar, Rashidi, Designing Agent-Ready Websites for AI Web Agents
https://arxiv.org/abs/2607.12056 - PDF pracy Designing Agent-Ready Websites for AI Web Agents
https://arxiv.org/pdf/2607.12056 - OpenID Connect Core 1.0
https://openid.net/specs/openid-connect-core-1_0.html - OpenID for Verifiable Credentials, specifications
https://openid.net/sg/openid4vc/specifications/ - SPIFFE, Secure Production Identity Framework for Everyone
https://spiffe.io/ - FIDO Alliance, standards for trusted AI agent interactions
https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/ - Verifiable Intent, open specification
https://github.com/agent-intent/verifiable-intent/ - W3C, Verifiable Credentials Overview
https://www.w3.org/TR/vc-overview-1.0/ - Agentic Commerce Protocol
https://www.agenticcommerce.dev/ - Google, Universal Commerce Protocol i narzędzia dla agentic commerce
https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Machine Payments Protocol, repozytorium specyfikacji
https://github.com/tempoxyz/mpp-specs - Stripe, Introducing the Machine Payments Protocol
https://stripe.com/blog/machine-payments-protocol - x402, dokumentacja
https://docs.x402.org/introduction - Visa Intelligent Commerce, dokumentacja deweloperska
https://developer.visa.com/capabilities/visa-intelligent-commerce - Mastercard, Europe is Building the Foundations for Trusted Agentic Commerce
https://www.mastercard.com/news/europe/en/perspectives/en/2026/europe-is-building-the-foundations-for-trusted-agentic-commerce/ - Visa, Trusted Agent Protocol for AI Commerce
https://corporate.visa.com/en/sites/visa-perspectives/newsroom/visa-unveils-trusted-agent-protocol-for-ai-commerce.html
Dyskusja