Filary 1, 2 i 3 odpowiadają na pytania o wiedzę: czy agent może przeczytać stronę, czy rozumie co na niej jest, czy wie że w ogóle istnieje. To są pytania o percepcję.
Filar 4 zadaje inne pytanie. Nie „czy agent rozumie” — tylko „czy agent może coś zrobić”.
To jest moment w którym strona przestaje być dokumentem do odczytania a zaczyna być środowiskiem do działania. I to jest moment w którym agent przestaje być narzędziem do wyszukiwania informacji a staje się narzędziem do realizacji intencji użytkownika — zamówienia, rezerwacji, zapytania, kontaktu.
Dla większości stron to jest największy skok jakościowy w całej drabinie agent-readiness. I największa luka.
Czym jest operacyjność
Filar 4 to zdolność strony do wykonywania działań przez agenta — formularze przyjazne agentom, API zamiast imitowania kliknięć, brak barier takich jak captcha blokująca automatyzację.
Słowo „zamiast” w tej definicji jest kluczowe. Nie „obok imitowania kliknięć” — zamiast. Agent który imituje kliknięcia człowieka — porusza kursorem, klika w przyciski, wypełnia pola jak człowiek — robi to z konieczności, nie z wyboru. To jest obejście problemu, nie jego rozwiązanie. Browser-use i computer-use istnieją i działają, ale są powolne, zawodne przy każdej zmianie layoutu i nie skalują się gdy agent obsługuje wiele sesji równolegle.
Operacyjność projektuje się inaczej — tak żeby agent działał natywnie.
Trzy stopnie operacyjności
Pierwsza i najłatwiejsza warstwa to formularze z sensowną semantyką. Agent który ma wypełnić formularz kontaktowy w imieniu użytkownika musi wiedzieć że to pole to email, to imię, to treść wiadomości. Brak atrybutów label, name i autocomplete sprawia że agent zgaduje — i zgaduje błędnie tyle razy ile wystarczy żeby przestać próbować. To jest zmiana którą można wprowadzić w kilka godzin na każdej stronie, bez architektury, bez API. A różnica dla agenta jest fundamentalna.
Drugi stopień to API. Najlepszy scenariusz dla agenta to nie wypełnianie formularza który zaprojektowano dla człowieka — tylko wywołanie endpointu który robi to samo bezpośrednio. Sklep który ma REST API do składania zamówień daje agentowi pewną, szybką, niezależną od layoutu ścieżkę działania. Platforma rezerwacyjna która wystawia endpoint do rezerwacji terminu — podobnie. Jeśli API istnieje, warto je udokumentować w OpenAPI — agent który widzi dokumentację wie co może wywołać i jak.
Trzeci stopień to WebMCP — propozycja standardu Google pozwalająca stronom wystawiać agentom zestaw akcji które mogą wykonać bezpośrednio, bez konieczności zgadywania struktury DOM. Strona deklaruje: „mam akcję 'dodaj do koszyka’, mam akcję 'sprawdź dostępność’, mam akcję 'złóż zapytanie ofertowe'”. Agent wywołuje funkcję, nie symuluje kliknięć. To jest jakościowa zmiana w architekturze — ale jak wskazuje artykuł na Webflux.pl z serii „Czego nie wdrożycie w 2026”, WebMCP jest w 2026 roku w early preview w Chrome i nie jest produkcyjnie gotowy dla wszystkich. Warto wiedzieć że istnieje i myśleć jakie akcje chciałoby się przez niego wystawić — bo to zmusza do zdefiniowania co na stronie jest „akcją” a co tylko „treścią”.
Niewidoczna bariera — captcha i bot protection
Jest jeden element operacyjności który jest osobną kategorią problemów: zabezpieczenia które blokują agentów nie wiedząc że to robią.
CAPTCHA przy każdym kroku formularza. Cloudflare Bot Fight Mode na maksymalnym poziomie. Rate limiting który odpala się przy drugim żądaniu. JavaScript challenge dla każdego nieznanego user-agenta.
Każde z tych zabezpieczeń ma sens jako ochrona przed złośliwym ruchem. Każde z nich jednocześnie odcina agentów działających w dobrej wierze w imieniu użytkowników. Problem nie polega na tym że te zabezpieczenia istnieją — polega na tym że właściciel strony często nie wie że to robią. Agenty po prostu napotykają mur i odchodzą. W logach nie ma błędu. W analityce nie ma śladu. Jest tylko transakcja której nie było.
Świadomość jakie zabezpieczenia działają na stronie i co blokują — to jest część Filaru 4 której nie widać w kodzie.
Granica między Filarem 4 a resztą
Operacyjność jest tym filarem który najbardziej zależy od tego czym strona jest. Blog nie potrzebuje API — nikt nie oczekuje że agent złoży zamówienie na artykuł. Strona firmowa z formularzem kontaktowym potrzebuje sensownych etykiet i autocomplete — to tygodniowa praca. Sklep internetowy który chce uczestniczyć w infrastrukturze Instant Checkout i Copilot Checkout potrzebuje całego drugiego stopnia — API, dokumentacji, integracji z protokołami agentic commerce.
Filar 4 jest pierwszym filarem gdzie „ile pracy” zależy radykalnie od modelu biznesowego strony. I pierwszym gdzie koszt braku jest bezpośrednio przeliczalny na transakcje których nie będzie.
Pełna checklista Filaru 4 wraz z pozostałymi pięcioma filarami dostępna jest w artykule na Webflux.pl: Sześć filarów agent-readiness — praktyczna checklista dla twojej strony