Trzy pierwsze filary agent-readiness dotyczyły czegoś, co miało jedną wspólną cechę — agent był w nich czytelnikiem. Czytelnikiem o szczególnych wymaganiach, ale wciąż kimś, kto odwiedzał stronę, żeby zrozumieć, co na niej jest, i wrócić z tą wiedzą do użytkownika. Mówiliśmy o czytelności, o danych strukturalnych, o sygnałach — wszystko to były warstwy informacji, które strona przekazuje agentowi, żeby ten mógł dobrze ją przeczytać.
Filar czwarty jest jakościowo inny. Dotyczy momentu, w którym agent przestaje być czytelnikiem, a zaczyna być kimś, kto wykonuje akcje w twojej stronie. Wypełnia formularz. Składa zamówienie. Rezerwuje termin. Pyta o dostępność. Umawia spotkanie. Zapisuje się na newsletter. I robi to nie jako test, nie w swojej własnej sandbox’ie — tylko bezpośrednio na twojej stronie, w twoim sklepie, w twoim systemie, w imieniu kogoś, kto mu to zlecił.
Ta różnica jest ogromna i trzeba ją nazwać wprost. Dopóki agent tylko czyta, jest kimś w rodzaju gościa, który chodzi po twojej witrynie, ogląda wystawę, notuje. Kiedy zaczyna działać, staje się pracownikiem, który wchodzi za ladę i wykonuje operacje w twoim imieniu. Z jedną różnicą — nie masz z tym pracownikiem kontraktu, nie wiesz kto go przysłał, nie masz jasnych procedur co wolno, a co nie. I prawdopodobnie sam jeszcze nie podjąłeś decyzji, czy chcesz, żeby tacy pracownicy w ogóle działali u ciebie.
W tym wpisie rozbiję to na trzy części. Pierwsza — gdzie dokładnie biegnie granica między gościem a pracownikiem, bo nie jest ona tak wyraźna jak się wydaje. Druga — trzy drogi, którymi strona pozwala agentowi-pracownikowi działać, i co każda z nich wymaga od ciebie jako właściciela. Trzecia — pytania, które warto sobie zadać zanim wpuścisz pracownika, którego nie znasz.
Gdzie biegnie granica między gościem a pracownikiem
Intuicyjnie wydaje się, że różnica jest prosta. Agent czytający twój blog, żeby odpowiedzieć użytkownikowi na pytanie — to gość. Agent klikający „złóż zamówienie” na twoim sklepie — to pracownik. Ale w praktyce granica jest rozmyta, i właśnie ta rozmytość jest źródłem większości problemów w tej warstwie.
Rozważmy kilka przypadków pośrednich.
Agent czytający twój formularz kontaktowy, żeby powiedzieć użytkownikowi, jakie pola trzeba wypełnić — gość czy pracownik? Jeszcze gość. Niczego nie robi, tylko relacjonuje.
Agent wypełniający ten formularz w imieniu użytkownika, po wpisaniu danych przez człowieka, ale przed naciśnięciem „wyślij” — gość czy pracownik? Wchodzi w szarą strefę. Już nie tylko czyta. Ale jeszcze nie wysłał.
Agent, który po krótkiej rozmowie z użytkownikiem („Zarezerwuj mi stolik w sobotę na 19:00 na dwie osoby”) wchodzi na twoją stronę restauracji, wypełnia formularz rezerwacji i klika „potwierdź” — to już pracownik. Wykonał akcję, której skutki istnieją w twoim systemie. Ktoś w twojej restauracji dostał powiadomienie o rezerwacji. Stolik jest zablokowany.
Agent ChatGPT-Users odwiedzający twój sklep, żeby sprawdzić cenę i dostępność produktu — gość czy pracownik? Teoretycznie gość, tylko czyta. Praktycznie — w logu serwera wygląda jak zwykły ruch, ale ten ruch nie jest człowiekiem. Nie kliknie w reklamę, nie przeczyta rekomendacji, nie da się upsellować. Obciąża twój serwer, ale nie generuje żadnej z metryk, na których zbudowałeś model biznesowy. Cicha forma pracownika, który robi jedną rzecz — pobiera dane.
Ta ostatnia warstwa jest zresztą centralnym argumentem w sporze Amazona z Perplexity, o którym pisałem w poprzednim wpisie. Agent, który „tylko czyta” twoją stronę zakupową, jest dla modelu biznesowego tej strony zupełnie inny niż człowiek, który czyta tę samą stronę. A kiedy agent dodatkowo zaczyna klikać — przechodzi do koszyka, wybiera opcję wysyłki, finalizuje zakup — staje się pełnoprawnym pracownikiem, który wykonał cały proces zakupowy, omijając wszystkie punkty, na których sklep miał okazję zarobić dodatkowo.
Granica więc nie biegnie w miejscu „czy agent kliknął”. Biegnie w miejscu, w którym jego wizyta pozostawia ślad w twoim systemie. Rezerwacja. Zamówienie. Zapis do newslettera. Wysłana wiadomość kontaktowa. Każda z tych rzeczy jest działaniem, i każda wymaga od ciebie jako właściciela strony innej decyzji niż tylko „jak sprawić, żeby agent zrozumiał, co tu mam”.
Trzy drogi, którymi strona pozwala agentowi działać
Kiedy już wiesz, że chcesz (albo nie chcesz) pozwolić agentowi-pracownikowi działać na twojej stronie, następne pytanie to jak to zrobić dobrze. W 2026 są trzy drogi, i każda z nich ma inny profil dojrzałości, inne wymagania i inne konsekwencje.
Droga pierwsza — interakcja z UI. Najstarsza, najbardziej powszechna, najbardziej chaotyczna. Agent działa na twojej stronie tak jak człowiek — widzi przycisk, klika go. Widzi formularz, wypełnia go. Widzi link, podąża za nim. Jest to domyślny scenariusz dla większości agentów w 2026, bo nie wymaga od strony żadnej dodatkowej pracy. Strona nie musi nic wiedzieć o agencie — po prostu dostaje żądania HTTP, tak jak od każdej innej przeglądarki.
Dla właściciela strony ta droga jest najmniej kontrolowalna. Agent może zachować się nieprzewidywalnie — kliknąć nie to, co trzeba, wypełnić źle formularz, zinterpretować niejednoznaczne elementy inaczej niż ty zakładałeś. Jeśli twoja strona ma na tej drodze jakieś krytyczne operacje (np. zakup produktu droższego niż 1000 zł), opieranie się na „agent dobrze kliknie” jest ryzykiem. Dlatego najbardziej odpowiedzialni właściciele stron już teraz dodają w tej warstwie kroki potwierdzenia, które wymagają decyzji człowieka — email confirmation, 2FA, ekrany z opóźnieniem.
Dobra wiadomość jest taka, że jakość tej drogi zależy głównie od rzeczy, które i tak warto mieć w ramach dostępności i semantyki — o czym pisałem szeroko w poprzednich wpisach serii i w serii o semantyce. Poprawne etykiety formularzy, sensowne anchory linków, logiczne struktury — wszystko to jednocześnie pomaga czytnikowi ekranu i agentowi. Więc jeśli robisz to dobrze dla dostępności, robisz to dobrze dla agentów-pracowników.
Droga druga — API. Starsza niż może się wydawać, bo API dla sklepów internetowych istnieje od dekad. Ale w kontekście agentów nabiera nowego znaczenia. Jeśli twój sklep ma REST API, twoja platforma rezerwacji ma endpoint do rezerwacji, twoja usługa ma endpoint do wyceny — agent może to wywołać bezpośrednio, omijając UI.
Jest to zdecydowanie bardziej kontrolowalna droga niż UI. Agent nie może przypadkiem kliknąć nie tego guzika, bo nie ma guzików — ma tylko wywołania funkcji z jasno określonymi parametrami. Strona może (i powinna) sprawdzać autoryzację, rate-limiting, poprawność parametrów przed wykonaniem akcji. Agent, który wywołuje API, musi się tam uwierzytelnić, i to uwierzytelnienie jest cyfrowym śladem, który zostaje w logach.
Ale droga API ma koszty. Trzeba je udostępnić, udokumentować, zabezpieczyć. Trzeba utrzymywać. Trzeba zdecydować, kto ma dostęp, na jakich zasadach, za jakie stawki. Dla większości małych i średnich stron w Polsce API jest dziś czymś, czego nie ma, nawet jeśli byłoby korzystne. Sklepy WooCommerce mają natywne REST API, ale rzadko jest ono udokumentowane publicznie z myślą o agentach.
Droga trzecia — wystawione narzędzia. Najnowsza, najbardziej ambitna, najbardziej eksperymentalna. W tej drodze strona jawnie deklaruje, jakie akcje agent może wykonać, z jakimi parametrami, w jaki sposób. Agent nie zgaduje po UI, nie odkrywa API metodą prób i błędów — dostaje oficjalny katalog narzędzi, których może użyć.
Konkretnym wcieleniem tej drogi w 2026 jest WebMCP — proponowany standard Chrome, udostępniony w lutym 2026 we wczesnym preview. Strona może przez WebMCP powiedzieć: „oto narzędzie zarezerwuj_stolik z parametrami data, liczba_osob, godzina; oto narzędzie sprawdz_dostepnosc_produktu z parametrem sku„. Agent, zamiast klikać po formularzach, wywołuje te narzędzia strukturalnie, z gwarancją poprawności parametrów.
Jest to droga, której dziś jeszcze się nie wdraża produkcyjnie na masową skalę — WebMCP jest w early preview, inne standardy są jeszcze młodsze. Ale jest to kierunek, w którym zmierza najambitniejsza część rynku. Dla właściciela strony WebMCP oznacza największą kontrolę nad tym, co agent może zrobić — bo sam decydujesz, jakie narzędzia wystawiasz, z jakimi parametrami, z jakimi ograniczeniami.
Krótki hub tematyczny — jeśli interesuje cię ekosystem protokołów agentic commerce (UCP, ACP, AP2) i konkretne implementacje dla sklepów, w hubie Universal Commerce Protocol jest cały materiał o tej warstwie z perspektywy WooCommerce i agentic commerce.
Pytania, które warto sobie zadać zanim wpuścisz pracownika
Dotarliśmy do sedna. Jeśli agent przestaje być gościem i staje się pracownikiem, a ty decydujesz się go wpuścić — w którejś z trzech dróg albo we wszystkich trzech — musisz odpowiedzieć na kilka pytań, których do tej pory na twojej stronie prawdopodobnie nikt nie zadawał.
Kto ma prawo wykonywać akcje w moim systemie? Odpowiedź „każdy, kto wejdzie na stronę” była akceptowalna w świecie, w którym stronę odwiedzał człowiek-użytkownik. W świecie, w którym co trzecia wizyta może być agentem działającym w imieniu kogoś, koncept „każdy” przestaje wystarczać. Musi być warstwa autoryzacji, która odróżnia ruch autoryzowany od nieautoryzowanego. Dla najprostszych stron wystarczy stare dobre logowanie użytkownika — agent, który składa zamówienie, musi być zalogowany na konto użytkownika, którego reprezentuje. Dla bardziej wymagających przypadków trzeba rozważyć kryptograficzną weryfikację tożsamości agenta, federację zaufanych dostawców, rejestry typu tego, który zaczyna budować Meta po zakupie Moltbook. To jest warstwa, którą dokładniej rozwijam na CyberFlux.pl w tekście o nowej tożsamości uprzywilejowanej — agenty w firmowych środowiskach to dziś problem klasy IAM, a nie problem UX.
Jak zapewniam, że agent robi to, czego chce użytkownik, a nie czego chce ktoś inny? To jest pytanie o prompt injection i permission injection. Agent, który czyta twoją stronę i na jej podstawie wykonuje akcje, może paść ofiarą ukrytych instrukcji umieszczonych w treści strony — w opisie produktu, w komentarzu, w recenzji. Pisałem szerzej o tym na CyberFluxie w kontekście architektury agentów. Jeśli twoja strona pozwala agentom na akcje, musisz traktować każdą treść, którą agent widzi jako potencjalne polecenie. Nie ma prostego rozwiązania — są warstwy mitygacji: sanityzacja treści od użytkowników, limity rate’u, wymóg potwierdzenia przed akcjami nieodwracalnymi, izolacja kontekstów.
Jakie akcje są odwracalne, a jakie nie? To jest pytanie o gradację ryzyka. Zapis do newslettera — odwracalny (można się wypisać). Rezerwacja stolika — prawie odwracalna (można anulować). Zakup produktu za 5000 zł z opcją „fast checkout bez potwierdzenia” — praktycznie nieodwracalny. W warstwie, w której agent działa w twoim imieniu, każda akcja powinna mieć świadomie określony poziom ryzyka i odpowiednio dobraną warstwę potwierdzenia. Nieodwracalne akcje powinny zawsze wymagać potwierdzenia człowieka, niezależnie od tego, kto wykonał żądanie. Agent, który może finalizować transakcję za 5000 zł bez żadnego potwierdzenia, to jest ryzyko, którego nie powinno się akceptować — nawet jeśli agent jest zaufany.
Jak zauważę, że coś poszło nie tak? Pytanie o audyt i monitoring. W świecie, w którym akcje wykonują agenci, klasyczne metody śledzenia ruchu nie wystarczą. Musisz mieć logi, które rozróżniają ruch ludzki od agentowego, ruch autoryzowany od nieautoryzowanego, akcje udane od nieudanych, wzorce normalnego zachowania od anomalii. To nie jest temat na dzisiejszy wpis — ale warto mieć świadomość, że każda droga pozwalająca agentowi działać wymaga warstwy obserwowalności, którą trzeba zbudować, zanim pojawi się pierwszy problem.
Jakie są moje limity — ekonomiczne i techniczne? Agent, który odwiedza twoją stronę co dziesięć sekund, bo prosi go o to tysiąc użytkowników dziennie, generuje ruch, którego twój hosting może nie wytrzymać. Agent, który próbuje składać zamówienia w tempie, które sugeruje automatyzację, może wyczerpać twoje stany magazynowe w ciągu minut. Rate limiting, quoty, limity transakcji — to są narzędzia, które w świecie ludzkich użytkowników były pomocnicze, a w świecie agentów stają się niezbędne. Wpuszczenie agentów bez limitów to jest zaproszenie do operacyjnego chaosu — niezależnie od dobrych intencji tych konkretnych agentów.
Co z tego wynika praktycznie
Filar działania w agent-readiness jest momentem, w którym z warstwy SEO-owej przechodzimy do warstwy, która z klasycznym SEO nie ma nic wspólnego. To jest warstwa architektoniczna — dotyczy tego, jak twoja strona jest zaprojektowana jako system, a nie jak jest zoptymalizowana dla wyszukiwarki.
Dobra wiadomość: nie musisz dziś rozwiązywać wszystkich tych problemów naraz. Jeśli twoja strona nie ma krytycznych akcji (jesteś blogiem, portalem informacyjnym, stroną firmową bez sprzedaży), filar 4 dotyczy cię tylko w części — zapewnienie, że formularze są dostępne i nie podatne na oczywiste nadużycia, wystarczy. Jeśli twoja strona ma akcje o średnim znaczeniu (formularz kontaktowy, newsletter), warto zainwestować w warstwę autoryzacji i odwracalności.
Jeśli natomiast prowadzisz sklep, platformę usługową, system rezerwacji, cokolwiek gdzie agent mógłby wykonać akcję o realnej wadze — filar 4 jest dziś najważniejszą warstwą agent-readiness, w której warto inwestować czas. Bo pierwszy incydent, w którym agent zrobił u ciebie coś niezamierzonego, będzie kosztować więcej niż cała praca zapobiegawcza. W agentic commerce świecie, który rozpisujemy w hubie UCP, ta warstwa będzie decydować o tym, które sklepy przetrwają przejście na nowy model zakupowy, a które staną się ostrzegawczymi przykładami w branżowych analizach.
Następny wpis — towarzysz w serii Agent-ready Divi — pokaże konkretnie, jak te zasady przekładają się na formularze w Divi 5, integracje WooCommerce, wtyczki rezerwacyjne. Gdzie są domyślne dziury, co można naprawić łatwo, a co wymaga architektonicznych decyzji.
Zasada, która wraca we wszystkich filarach tej serii, wraca i tu. Agent nie wymyślił nowej dyscypliny — architektura bezpieczeństwa systemów webowych istnieje od dekad. Różnica polega na tym, że do tej pory w warstwie działania mieliśmy dwóch aktorów: zalogowanego użytkownika (któremu ufamy częściowo) i botów (których staramy się wyeliminować). Agent wprowadza trzeciego aktora — autoryzowanego pośrednika działającego w imieniu użytkownika. To jest kategoria, której klasyczne architektury stron nie znały. I budowa pod nią poprawnych schematów autoryzacji, audytu, limitów, odwracalności — to jest praca, która przed nami, nie za nami.