WordPress jako system operacyjny agentowego internetu. Kto zapłaci za tokeny?
Automattic ogłosił 21 kwietnia 2026 w poście „WordPress as the Operating System of the Agentic Web”, że WordPress jest systemem operacyjnym agentowego internetu. Post Jamesa Griersona, szefa globalnej ekspansji firmy, opisuje 8 mocnych stron tej roli i 6 słabych. Pomija jednak jedno pytanie. Kto pokrywa koszty tokenów AI po stronie końcowego użytkownika. Ta luka decyduje o tym, kto otrzyma pierwszy nieoczekiwany rachunek po wydaniu WordPressa 7.0.
„WordPress’s foundational principles position it uniquely to become the operating system of the agentic web.”
James Grierson, Automattic, 21 kwietnia 2026
Nazwanie 43-procentowego udziału w rynku „operating system” agentowego internetu jest mocną deklaracją. Pominięcie kosztów AI, które wzięłą na siebie końcowy użytkownik, jest mocnym pominięciem.
Co właściwie ogłosił Automattic 21 kwietnia 2026
Automattic określił WordPress jako fundament agentowego internetu z trzech powodów. Otwarty kod, ekosystem 61 000 darmowych wtyczek oraz standaryzowane API. James Grierson powołuje się na statystyki samego Automattica, czyli 43% udziału we wszystkich stronach internetowych i ponad 60% rynku CMS. Wartość 90 000 wtyczek pojawia się dopiero po doliczeniu marketplace komercyjnych.
Pełna lista pros i cons z postu
Automattic wymienia 8 mocnych stron WordPressa jako platformy dla agentów AI. Sprawdzony, masowy ekosystem. Transparencja kodu open source. Recenzowany kod i standardy społecznościowe. Bezpieczeństwo wynikające z transparencji. REST API i połączenia MCP. Rozszerzalność komercyjna przez WooCommerce. Architektura hooków i filtrów. Dziesięciolecia dokumentacji.
Lista 6 słabych stron jest równie konkretna. Stary kod i dług techniczny. Niespójna jakość wtyczek. Porzucone i niezabezpieczone pluginy. Narzut wydajnościowy. Złożoność systemu hooków dla agentów. Postrzeganie PHP i kurczenie się ścieżek wejścia dla nowych programistów. Fragmentacja środowisk hostingowych.
Czego w poście nie ma
W poście Griersona nie pojawia się ani razu słowo token. Nie ma sekcji o własności klucza API. Nie ma modelu rozliczeń. Nie ma scenariusza, w którym agent kończy zaplanowaną pulę zapytań w połowie tygodnia. Brak tych odpowiedzi wynika z perspektywy autora. Post powstał z punktu widzenia firmy, która sprzedaje hosting i moduły AI w pakiecie. Operator strony self-hosted ma inne priorytety.
Druga rzecz, której Automattic nie omawia, to logowanie operacji wykonywanych przez agenta. Każda akcja zapisu przez MCP modyfikuje stan bazy danych, lecz wymaga osobnego wpisu w dzienniku audytowym, czego post Griersona nie wymienia. Trzecia rzecz, czyli polityka prywatności, decyduje o tym, jakie dane wpisu lub komentarza opuszczają serwer i trafiają do dostawcy AI. Te trzy rzeczy odróżniają wizję od gotowego do wdrożenia produktu.
Model Context Protocol i Abilities API w praktyce
Model Context Protocol to standard, który pozwala agentom AI łączyć się z zewnętrznymi systemami. Automattic wdrożył MCP w WordPress.com w dwóch fazach. Najpierw odczyt, potem zapis. Self-hosted WordPress uzyskuje analogiczną zdolność przez Abilities API i WordPress MCP Adapter.
Read-only w październiku 2025, zapis w marcu 2026
WordPress.com udostępnił MCP w trybie tylko do odczytu w październiku 2025. Pełne wsparcie dla operacji zapisu włączono w marcu 2026. Od tego momentu agent może utworzyć wpis, opublikować go, dodać komentarz i zarządzać mediami przez język naturalny. Każda taka operacja generuje koszt po stronie modelu, który ją wykonuje.
Konsekwencja praktyczna jest prosta. Aktywacja jednej wtyczki, która rozmawia z agentem, zamienia każdą edycję wpisu w zapytanie do zewnętrznego dostawcy AI. Rachunek przychodzi tam, gdzie jest klucz API.
Co zmieni Abilities API w wersji self-hosted
Abilities API w połączeniu z WordPress MCP Adapter pozwala twórcom wtyczek wystawić istniejące funkcje jako narzędzia dla agentów. Adapter mostkuje plugin abilities do specyfikacji MCP. Twórca dotychczasowej wtyczki dodaje kilka linii konfiguracji. Agent uzyskuje dostęp do tej funkcji.
Ten skrót obniża próg wejścia, przez co liczba wtyczek z funkcjami AI w sklepie WordPress.org rośnie szybciej niż liczba audytów bezpieczeństwa tych wtyczek. WPPoland obserwuje ten wzorzec od marca 2026 na klientach utrzymywanych w naszym programie utrzymanie strony WordPress.
Rola WordPress Playground dla agentów
WordPress Playground pozwala uruchomić pełną instancję WordPressa w przeglądarce w kilka sekund. Automattic wskazuje to narzędzie jako sandbox dla agentów. Agent testuje zmianę w środowisku Playground, a dopiero potwierdzone działanie wraca do produkcji. Konstrukcja zmniejsza ryzyko zniszczenia danych przez halucynację modelu. Nie zmienia jednak tego, kto rozliczy zużyte tokeny.
Luka w wizji, czyli kto płaci za tokeny
Russell Heimlich, programista z 20-letnim doświadczeniem w ekosystemie WordPress, zadał to pytanie publicznie w tekście „WordPress AI Features Are Coming. Nobody Is Talking About What They’ll Cost Your Users” opublikowanym 24 kwietnia 2026. Heimlich, znany w społeczności pod pseudonimem russellenvy, wskazuje, że Automattic ani razu nie wymienia kwestii kosztów AI w swojej wizji agentowego internetu. Jego punkt jest praktyczny. Jeśli wtyczka instaluje się sama, prosi o połączenie konta u dostawcy AI, a potem otwiera czat w panelu, użytkownik nie wie, że każda wiadomość kosztuje.
Argument Russella Heimlicha
Heimlich opisuje własny przypadek pracy z modelem AI. Korzysta z miesięcznej subskrypcji u dostawcy modelu Claude i wyczerpuje tygodniowy limit zapytań mimo zaawansowanych optymalizacji prompta i przepływu pracy. Z tego wyciąga konkretny wniosek. Osoba bez doświadczenia w pracy z modelami języka, na przykład bloger kulinarny, który właśnie postawił stronę i zainstalował popularną wtyczkę z funkcją AI, zużyje tę pulę szybciej i bez jasnego komunikatu o przyczynie błędu.
„Every interaction between an AI agent and a WordPress site costs tokens.”
„Every single one of those exchanges burns tokens. Real money. Her money. And she has no idea.”
Russell Heimlich, russellenvy.com, 24 kwietnia 2026
Drugi argument Heimlicha dotyczy odpowiedzialności za doświadczenie użytkownika. Wtyczka, która wprowadza funkcję AI bez czytelnego komunikatu o kosztach, przerzuca koszt edukacji użytkownika na operatora strony i pośrednio na agencję. Trzeci argument odnosi się do reputacji marki WordPress jako platformy. Pierwsza fala niezadowolenia po nieoczekiwanych rachunkach wraca jako negatywny sygnał całemu ekosystemowi, niezależnie od tego, że źródłem problemu jest pojedyncza wtyczka.
Heimlich dochodzi do tego momentu i kończy. WPPoland uzupełnia jego argument o trzy rzeczy. Kontrakt agencji z klientem. Model własności klucza. Tryb degradacji wtyczki przy wyczerpanym limicie.
Trzy modele własności klucza API i ich konsekwencje
W praktyce spotyka się 3 modele rozliczania tokenów AI w wtyczkach WordPress.
Bring-your-own-key. Klient zakłada konto u dostawcy AI, generuje klucz i wkleja go w panelu wtyczki. Koszty trafiają wprost do klienta. Twórca wtyczki nie pośredniczy. Model jest przejrzysty pod względem księgowym, lecz wymaga, aby klient rozumiał, jak działa pula tokenów u tego dostawcy.
Subskrypcja obsługiwana przez twórcę wtyczki. Wtyczka pobiera od klienta stałą opłatę miesięczną i sama rozlicza się z dostawcą AI. Ryzyko nadużycia spada na twórcę, który balansuje cennik z faktycznym zużyciem. Model jest wygodny dla klienta końcowego i ryzykowny dla operatora wtyczki.
Współdzielona pula tokenów z miesięcznym limitem. Wszyscy klienci tej wtyczki dzielą jedną pulę. Po wyczerpaniu pula odnawia się następnego miesiąca lub ulega poszerzeniu w wyższym pakiecie. Model upraszcza komunikat dla użytkownika, lecz wprowadza nowy efekt, czyli sąsiad zużywa moje tokeny.
Scenariusz blogerki kulinarnej z TikToka
Heimlich opisał ten scenariusz pierwszy. Bloger wiralowy stawia stronę WordPress, instaluje wtyczkę z funkcją AI, klika w kreatorze. Kreator prosi o połączenie konta Claude, ChatGPT lub Gemini. Bloger łączy konto, ponieważ instrukcja tak mówi. Następnie traktuje pole AI jako zwykły czat. Po dwóch dniach pula tygodniowa znika. Wtyczka pokazuje pusty loader bez komunikatu. Bloger wini WordPressa. Każda część tej historii powtarza się dziś u realnych klientów.
Co to oznacza dla właścicieli stron WordPress przed wydaniem 7.0
Wydanie WordPressa 7.0 zbliża się szybko. Wersja Release Candidate 2 ukazała się 26 marca 2026 na wordpress.org. Data wydania ogólnodostępnego nie jest jeszcze oficjalnie potwierdzona w komunikatach projektu. Niezależnie od konkretnej daty, infrastruktura MCP po stronie self-hosted dojrzewa równolegle. Operator strony powinien wykonać 3 ruchy przed pierwszą falą aktualizacji wtyczek z AI w środku.
Audyt aktualnie zainstalowanych wtyczek pod kątem AI
Sprawdź każdą zainstalowaną wtyczkę pod kątem 3 informacji. Czy w roadmapie produktu pojawia się komponent AI w nadchodzącej wersji. Czy autor wtyczki opublikował model rozliczania tokenów. Czy istnieje opcja wyłączenia funkcji AI bez utraty pozostałych zdolności wtyczki. Wtyczki bez tych odpowiedzi wymagają monitorowania zmian w changelogu między aktualizacjami.
W praktyce 3 kategorie wtyczek najszybciej wprowadzają funkcje AI. Wtyczki SEO, takie jak Yoast SEO i Rank Math, gdzie generator opisów meta korzysta z modelu językowego. Wtyczki kalendarzy i wydarzeń, takie jak The Events Calendar, gdzie agent generuje opisy serii powtarzających się wydarzeń. Wtyczki sklepowe i CRM, gdzie asystent AI proponuje opisy produktów i odpowiedzi na zapytania klienta. Każda z tych 3 kategorii ma inny profil zużycia tokenów, ponieważ inna jest długość pojedynczego promptu.
Pełny audyt warto połączyć z audytem bezpieczeństwa WordPressa raz na pół roku. WPPoland prowadzi taki audyt jako element programu utrzymania strony, a od marca 2026 dokłada do niego sekcję z mapą funkcji AI w zainstalowanych wtyczkach.
Pytania do dostawców wtyczek
Trzy pytania do twórcy wtyczki przed włączeniem trybu AI brzmią konkretnie. Pierwsze, gdzie znajduje się klucz API i kto go opłaca. Drugie, jaki jest komunikat dla użytkownika po wyczerpaniu puli tokenów. Trzecie, czy każda akcja wykonywana przez agenta jest logowana w sposób umożliwiający odtworzenie historii. Twórcy poważnych wtyczek odpowiedzą w jeden dzień. Brak odpowiedzi sam w sobie jest odpowiedzią.
Konfiguracja domyślnych zachowań przy braku tokenów
Skonfiguruj wtyczkę tak, aby brak tokenów degradował funkcję, a nie blokował dashboard. Trzy ustawienia rozwiązują 80% problemów. Komunikat tekstowy o przyczynie błędu zamiast pustego loadera. Lokalna kopia ostatniej udanej odpowiedzi widoczna jako placeholder. Wyłączenie modułu AI z poziomu profilu redaktora bez konieczności edycji kodu.
Co powinni zrobić twórcy wtyczek
Twórcy wtyczek mają większą odpowiedzialność niż operatorzy stron, ponieważ kształtują pierwsze doświadczenie końcowego użytkownika z agentem AI. Trzy zasady projektowania ograniczają liczbę zdziwionych klientów po pierwszym rachunku.
Komunikat o kosztach przed pierwszym żądaniem
Pierwsze żądanie do agenta poprzedza zawsze komunikat. Wtyczka pokazuje, jaka akcja zostanie wykonana, ile tokenów szacunkowo zużyje i które konto AI zostanie obciążone. Komunikat wyświetla się raz, lecz jego brak skutkuje stratą zaufania użytkownika przy pierwszej niespodziance. Wzorzec sprawdzony w popularnych narzędziach deweloperskich, takich jak GitHub Copilot lub Cursor.
Tryb degradacji zamiast pustego loadera
Tryb degradacji obsługuje 4 stany puli tokenów. Pełny dostęp. Ostrzeżenie o niskim stanie. Tryb tylko-do-odczytu, gdzie agent czyta dane, lecz nie generuje treści. Tryb wyłączony. Każdy stan ma własny komunikat dla użytkownika. Pusty loader nie jest stanem akceptowalnym, ponieważ użytkownik bez kontekstu interpretuje go jako błąd całej platformy.
Bring-your-own-key vs subskrypcja vs współdzielona pula
Wybór modelu rozliczeń wpływa na 3 obszary jednocześnie, czyli komunikat instalacyjny, panel ustawień i procedurę reagowania na incydent. Bring-your-own-key wymaga starannego onboardingu klienta. Subskrypcja wymaga negocjacji wolumenu z dostawcą AI po stronie twórcy wtyczki. Współdzielona pula wymaga monitoringu nadużyć. Twórca wtyczki opisuje wybór modelu w dokumentacji, a nie tylko w polityce prywatności.
Jak agencja powinna przygotować klienta
Agencja zarządzająca wieloma stronami klientów ma 3 rzeczy do uzgodnienia z każdym klientem przed wydaniem WordPressa 7.0. Klauzulę umowną o usługach AI. Reżim aktualizacji wtyczek. Komunikację incydentu po przekroczeniu limitu tokenów.
Klauzula umowna o zewnętrznych usługach AI
Klauzula składa się z 4 zdań. Klient samodzielnie pokrywa koszty tokenów u zewnętrznych dostawców AI. Agencja informuje klienta o każdej nowej funkcji AI w utrzymywanych wtyczkach przed jej aktywacją. Klient autoryzuje aktywację pisemnie. Agencja monitoruje zużycie i raportuje anomalie w terminie do 48 godzin. Wzorzec wyrasta z ugruntowanego doświadczenia WPPoland w pracy z klientami biznesowymi, gdzie nieoczekiwane koszty zewnętrzne psują relację najszybciej.
Klauzula opisuje również procedurę awaryjną w 2 krokach. Pierwsze, automatyczna pauza zapytań do agenta po przekroczeniu progu zdefiniowanego z klientem. Drugie, kontakt agencji z klientem w trybie roboczym, czyli e-mail i telefon w godzinach pracy klienta. Niezdefiniowany próg progowy oznacza w praktyce, że pierwsza informacja o przekroczeniu trafia do klienta dopiero w fakturze od dostawcy AI, co stanowi najczęstszą przyczynę utraty zaufania w pierwszym kwartale współpracy.
Reżim aktualizacji, czyli ręcznie, automatycznie, po przeglądzie
Klient wybiera 1 z 3 reżimów aktualizacji wtyczek. Aktualizacje ręczne, gdzie agencja wprowadza nową wersję po testach. Aktualizacje automatyczne z dziennym raportem zmian. Aktualizacje po przeglądzie, gdzie agencja blokuje wprowadzenie nowych funkcji do czasu zatwierdzenia przez klienta. Reżim po przeglądzie chroni klienta najlepiej w okresie wprowadzania funkcji AI w pluginach.
Co umieścić w briefie dla nowego projektu
Brief nowego projektu uwzględnia 4 nowe pytania względem briefu z 2024 roku. Pierwsze, czy klient akceptuje obecność funkcji AI w panelu redakcyjnym. Drugie, kto będzie właścicielem kluczy API u dostawców AI. Trzecie, jaki budżet miesięczny przeznacza klient na tokeny. Czwarte, jakie scenariusze użytkownika nie powinny generować zapytań do agenta. Te 4 pytania odpowiadają na luki, których Automattic nie domknął w swojej wizji.
Po wykonaniu tych ustaleń projekt może bezpiecznie korzystać z infrastruktury MCP, Abilities API i ekosystemu wtyczek. Operator zna koszty. Twórca wtyczki zna ograniczenia. Agent AI ma wyraźnie zdefiniowane granice działania. Reszta mocnych stron WordPressa, takich jak otwarty kod i bogata dokumentacja, działa bez zmian.
WPPoland prowadzi tę rozmowę z każdym klientem od marca 2026. Pełną mapę praktyk omawiamy szczegółowo w artykule jak zwiększyć widoczność strony w AI i LLM oraz w strategicznym podsumowaniu LLMO. Sama widoczność dla agentów to drugi temat, lecz fundament jest ten sam, czyli zrozumienie, gdzie zaczyna się i kończy odpowiedzialność za koszt zapytania.
