From the field #08 - AX: agent experience, którego twoja strona nie ma

Część 1: twoja strona ma UX, nie ma AX

Spójrz na swoją stronę tak, jak zawsze. Człowiek wchodzi, layout prowadzi wzrok, treść robi swoje, ktoś klika przycisk. Ktoś włożył realny wysiłek, żeby to doświadczenie było dobre. To jest UX, dwadzieścia lat dopracowanej praktyki.

Teraz wejdź na tę samą stronę jako agent.

Nie crawler indeksujący tekst. Agent: system działający w czyimś imieniu, który musi wiedzieć, co twoja strona potrafi, o co może ją poprosić i jak się podłączyć. Czyta markup i znajduje layout zbudowany pod oczy. Brak stwierdzenia, czym ta strona jest. Brak listy tego, na co potrafi odpowiedzieć. Brak endpointu, który mógłby wywołać. Przyszedł działać, a znalazł broszurę.

To drugie doświadczenie ma już nazwę. Agent Experience, AX, i twoja strona prawie na pewno nie ma go wcale.

Dwa standardy skrystalizowały się, gdy wszyscy patrzyli na chatboty

Ciekawym przesunięciem 2026 nie był mądrzejszy chatbot. To dwa standardy hydrauliki, które po cichu twardniały pod agentami, oba wymierzone w to samo pytanie: jak autonomiczny system dowiaduje się, co coś potrafi, i potem tego używa.

Pierwszy to MCP, Model Context Protocol. To standard agent-do-narzędzia - jak model podłącza się do źródła danych albo capability i wywołuje je w sposób strukturalny. Anthropic go wypuścił, a przez 2025 i 2026 przestał być pomysłem jednego dostawcy i stał się domyślnym sposobem, w jaki agenci sięgają po narzędzia. Portfolio, które czytasz, już nim mówi.

Drugi to A2A, Agent2Agent. To standard agent-do-agenta - jak jeden agent odkrywa drugiego, dowiaduje się, do czego on jest, i przekazuje mu robotę. Zaczął się w Google i przeszedł pod Linux Foundation, co dzieje się z protokołem, kiedy branża decyduje, że to infrastruktura, a nie produkt. Jednostką tożsamości A2A jest Agent Card: mały publiczny manifest, który mówi, maszynowo, “jestem tym agentem, oto co robię, oto jak mnie złapać”.

MCP dla agent do narzędzia. A2A dla agent do agenta. Anthropic, OpenAI, Google, Linux Foundation, wszyscy pchający w tę samą stronę. To nie jest spekulatywne. To shipnięte specyfikacje z numerami wersji, i opisują web, w którym to, co puka do twoich drzwi, coraz częściej nie jest człowiekiem.

AX to pytanie, którego UX jeszcze nie zadano

Tu jest ujęcie, które zrobiło z tego odcinek. Przez dwadzieścia lat jedyne pytanie, które się liczyło o stronie, było ludzkie. Czy jest szybka, czy jest jasna, czy człowiek osiągnie to, po co przyszedł. UX.

Agentic web dodaje drugie pytanie, którego większości stron nigdy nie zadano. Czy agent widzi, co potrafisz. Czy może odkryć twoje capabilities bez skrobania strony zrobionej pod oczy. Czy może podłączyć się do tego, co oferujesz, i tego użyć. Czy jest manifest, który mówi agentowi, czym jesteś, czy musi zgadywać z twojej strony głównej.

To jest AX, Agent Experience, a luka między UX strony a jej AX jest, dla prawie każdego, totalna. UX dopracowany. AX nie istnieje. Brak Agent Card, brak discovery manifestu, brak maszynowo czytelnego stwierdzenia capability. Agent, który trafia, ma to samo doświadczenie, które miałby człowiek z odjętym arkuszem stylów i pomieszanym tekstem: technicznie coś tam jest, praktycznie nic, czego da się użyć.

Daj temu sześć do dwunastu miesięcy. Sposób, w jaki ocenia się stronę, się poszerzy. Nie tylko “czy to dobre dla człowieka”, ale “czy agent może z tym cokolwiek zrobić”. Strony, które odpowiadają tak, będą tymi, które agent potrafi znaleźć, opisać i na których potrafi działać. Strony, które odpowiadają nie, będą niewidoczne dokładnie w tym kanale, który rośnie najszybciej, i jak ze wszystkim w tej przestrzeni, porażka będzie cicha. Nic się nie psuje. Agent po prostu cię nie widzi, a ty nie dostajesz sygnału, że próbował.

Niewidoczny dla agenta to nie to samo co zepsuty

Bądź precyzyjny co do tego, jak wygląda brak AX, bo nie wygląda jak awaria.

Twoja strona działa. Człowiek używa jej bez problemu. Ale agent, który chce wiedzieć, co oferujesz, nie ma gdzie spojrzeć. Nie ma agent card pod /.well-known/agent-card.json, który mówiłby mu, kim jest ten agent i jakie ma skille. Nie ma MCP discovery manifestu, który wskazywałby mu wywoływalny endpoint. Nie ma discovery layer w ogóle, więc agent robi to, co agenci robią z nieprzejrzystą stroną: zgaduje ze skrobanego HTML, albo wybiera cel, który faktycznie potrafi przeczytać, albo nie robi nic i idzie dalej.

Każdy z tych wyników omija cię bokiem. I żaden nie pokazuje się w twoich analytics jako problem, bo od strony człowieka nie ma problemu. Strona działa. Po prostu nie istnieje dla czytelników, którzy przychodzą teraz bez oczu.

Po co poszedłem to zbudować

Buduję deterministyczne pipeline’y do AI-driven QA, a kręgosłupem tego wszystkiego jest jeden pomysł: kontekst przed modelem. Nie wrzucasz agenta w niejednoznaczność i nie liczysz. Dajesz mu czysty, jawny, strukturalny kontekst, a wtedy robi tę część, w której jest dobry. AX to ta sama zasada wymierzona we własny brand. Jeśli agentic web ma czytać moje portale, uczciwym ruchem jest podać agentowi dokładny kontekst, czym każdy z nich jest i co potrafi, zamiast kazać mu odtwarzać to ze strony zrobionej pod ludzi.

Więc potraktowałem brand tak, jak traktuję pipeline. Nie jedną stronę - całą flotę. Sześć brand portali, każdy osobny deploy, każdy potrzebujący tej samej warstwy agent-discovery: custom Agent Card, MCP discovery manifest, capabilities, które agent faktycznie przeczyta. Portfolio, na którym jesteś, jest jednym z nich. Strona dokumentacji mojego patternu testowego też. I prywatna baza wiedzy, która potrzebowała ostrożniejszej odpowiedzi niż reszta.

Uzbrojenie wszystkich sześciu zajęło około siedemdziesięciu minut czasu Claude Code, a na końcu każdy zwracał zieloną próbę. Sześć portali, pełna warstwa agent-discovery, siedemdziesiąt minut. Ta liczba jest prawdziwa - zeszła ze sprintu, nie ze slajdu - i jest kręgosłupem Części 2.

Część 2 to build. Dokładne manifesty, co deklarują i czego celowo nie, jeden wzorzec, który zrobił z jednego pliku źródłowego obsługę dwóch języków bez driftu, i portal, który dostał inną odpowiedź celowo, bo jego API nie jest po to, żeby było publiczne.

From the Field to jest to, co realnie buduję, co się psuje i czego się uczę. Realne projekty, realne liczby, realne bugi. Bez tutoriali.