Agentic Web 1 listopada 2026 · 4 min czytania

Ogon, który udaje fundament

W ERP łatwiej wstawić agenta niż rozpisać reguły, a na stronie łatwiej dobudować WebMCP niż poprawić semantykę. Rozwiązanie na trudny ogon jest tak wygodne, że zaczyna zastępować fundament.

Tekst: Łukasz Jajor

Wygodne dwadzieścia procent. Heurystyka na 80 procent, model na ogon - senteri.pl — Ogon, który udaje fundament - senteri.pl

Mam zasadę, która powstała przy pracy z systemami firmowymi: heurystyka zawsze, bo załatwia 80 procent, a model na ogon. Ostatnio zauważyłem, że ten sam układ, i ten sam błąd, powtarza się w zupełnie innym miejscu: na stronach internetowych przygotowywanych dla agentów AI. W obu przypadkach rozwiązanie pomyślane na trudne 20 procent jest tak wygodne, że zaczyna udawać fundament.

Zasada z ERP

Większość decyzji w systemie firmowym ma strukturę. Faktura przychodzi z KSeF jako uporządkowany XML: kontrahent, pozycje, kwoty, daty. Kategorię da się ustalić z historii poprzednich księgowań tego kontrahenta. Kompletacja zamówień w magazynie to klasyczny problem optymalizacyjny, który od dekad rozwiązują algorytmy. Takie zadania załatwia heurystyka: reguły, statystyka z historii, prosty algorytm. Działa lokalnie, przewidywalnie, ma stały koszt, a dane nie opuszczają firmy.

Model językowy przydaje się tam, gdzie reguły się kończą: przy tytule przelewu napisanym przez człowieka, mailu od klienta, dokumencie, który nie przyszedł w żadnym formacie. To jest ogon. Rzadki, nieprzewidywalny, i tu model rzeczywiście robi różnicę.

Tyle że łatwiej jest wstawić agenta, który „zajmie się wszystkim”, niż rozpisać 80 procent na reguły. Agent nie wymaga znajomości procesu. Reguła wymaga. I tak powstają agenci, którzy wysyłają do modelu dane już uporządkowane, żeby wykonać pracę, którą algorytm zrobiłby taniej, szybciej i bez wątpliwości, co się stało z danymi.

Ten sam układ na stronach

Na stronach fundamentem jest semantyczny HTML i dostępność. Google pisze w dokumentacji swojego narzędzia do oceny gotowości na agentów wprost: dobrze zbudowane drzewo dostępności to podstawowy sposób, w jaki agenci AI rozumieją stronę. Przycisk, który jest przyciskiem, pole z etykietą, cena w kodzie, a nie w obrazku. To działa dla każdego agenta i każdego człowieka, również dla tego, który korzysta z czytnika ekranu.

I z tym fundamentem jest źle. W lutym 2026 błędy dostępności miało 95,9 procent stron głównych z miliona najpopularniejszych, po raz pierwszy od sześciu lat więcej niż rok wcześniej.

WebMCP to ogon. Pozwala stronie wystawić agentowi narzędzia: zamiast klikać przez formularz rezerwacji, agent wywołuje funkcję z jasno opisanymi danymi wejściowymi. Pomysł jest słuszny. Są procesy, których z samego HTML-a nie da się bezpiecznie wykonać, i dla nich osobna, jawna warstwa ma sens.

Jak ogon staje się fundamentem

Problem zaczyna się, gdy wygodniej jest dobudować nową warstwę, niż naprawić starą. Poprawienie dostępności na istniejącej stronie to żmudna praca: setki komponentów, formularze, nawigacja. Dodanie kilku narzędzi WebMCP to zadanie na sprint. Efekt w raporcie wygląda podobnie: strona jest „gotowa na agentów”.

A raport już to liczy. Audyt Lighthouse dla agentów sprawdza obok drzewa dostępności także zarejestrowane narzędzia WebMCP i formularze, którym brakuje jego deklaracji. Kiedy coś zaczyna być mierzone obok fundamentu, zaczyna być traktowane jak fundament. Kto widzi ostrzeżenie o brakującym WebMCP, naprawi właśnie je, bo to łatwiejsze.

Do tego dochodzą dwie prawdy. Interfejs dla ludzi i narzędzia dla agentów to dwie warstwy, które mogą się rozjechać: inna cena, inny krok, inna dostępność produktu. Przy budowie obiegu dokumentów zintegrowanego z ERP najwięcej czasu kosztowało mnie właśnie pytanie, kto jest źródłem prawdy, gdy dwa systemy mogą zmienić ten sam stan. Semantyczny HTML to jedna prawda dla wszystkich. Dwie warstwy to dwie prawdy i pytanie, która wygra.

Kto na tym zarabia

Za wygodą stoi rachunek. Funkcje AI w systemach firmowych coraz częściej rozlicza się pulami tokenów albo kredytów. Przy takim rozliczeniu dostawca zarabia na każdym zadaniu, które wykona model, a nie na tym, które rozwiąże reguła. Heurystyka, która załatwia 80 procent przypadków, z punktu widzenia takiego cennika jest utraconym przychodem.

Na stronach mechanizm jest podobny, tylko rozłożony na dwie strony. WebMCP sprawia, że pojedyncze zadanie agenta jest tańsze: zamiast analizować zrzuty ekranu, agent wywołuje gotowe narzędzie. Ale tańsze zadanie oznacza więcej zadań, i każde z nich rozlicza platforma agentowa. Koszt dodatkowej warstwy ponosi właściciel strony, a przychód z każdego wykonanego przez agenta zadania trafia gdzie indziej.

Nie twierdzę, że to spisek. To bodźce. Kto rozlicza się od użycia, ma powód, żeby użycia było jak najwięcej, a rozwiązanie na ogon generuje użycie lepiej niż fundament.

Czego ta teza nie mówi

Nie mówi, że modele są niepotrzebne ani że WebMCP jest zły. Model na ogon to dobre użycie modelu. WebMCP dla procesów, których nie da się zrobić inaczej, to dobre użycie WebMCP. Teza dotyczy kolejności i proporcji: ogon ma sens dopiero na fundamencie, a nie zamiast niego.

Przed zakupem agenta do ERP i przed dodaniem narzędzi WebMCP do strony warto zadać to samo pytanie: co z tego da się zrobić bez modelu i bez dodatkowej warstwy? Odpowiedź zwykle brzmi „większość”. I to ta większość decyduje, czy reszta w ogóle zadziała.

Źródła