WordPress como sistema operativo da web agentiva. Quem paga pelos tokens?
A Automattic anunciou em 21 de abril de 2026 no artigo WordPress as the Operating System of the Agentic Web que o WordPress é o sistema operativo da web agentiva. O texto de James Grierson, responsável pela expansão global da empresa, lista 8 pontos fortes e 6 pontos fracos deste papel. Falta uma pergunta. Quem cobre o custo dos tokens de IA do lado do utilizador final. Esta lacuna decide quem recebe a primeira fatura inesperada quando a versão 7.0 do WordPress for lançada.
„WordPress’s foundational principles position it uniquely to become the operating system of the agentic web.”
James Grierson, Automattic, 21 de abril de 2026
Chamar a 43 por cento da web o „operating system” do futuro agentivo é uma afirmação forte. Omitir quem paga pelo uso de IA que circula por esse sistema é uma omissão igualmente forte.
O que a Automattic anunciou de facto a 21 de abril de 2026
A Automattic posiciona o WordPress como fundamento da web agentiva por três razões. Código aberto, um ecossistema com 61 000 plugins gratuitos e APIs padronizadas. James Grierson cita as próprias estatísticas da Automattic, nomeadamente uma quota de 43 por cento de todos os sites e mais de 60 por cento do mercado de CMS. O número de 90 000 plugins inclui marketplaces comerciais.
Lista completa de prós e contras do artigo
A Automattic enumera 8 pontos fortes do WordPress como plataforma para agentes de IA. Um ecossistema massivo e comprovado. Transparência do código aberto. Código revisto por pares e padrões da comunidade. Segurança via transparência. REST API e ligação MCP. Extensibilidade comercial via WooCommerce. Arquitetura de hooks e filtros. Décadas de documentação.
A lista dos 6 pontos fracos é igualmente concreta. Código antigo e dívida técnica. Qualidade inconsistente dos plugins. Plugins abandonados e inseguros. Sobrecarga de desempenho. Complexidade do sistema de hooks para agentes. Perceção do PHP e o estreitamento do canal de novos programadores. Fragmentação dos ambientes de alojamento.
O que o artigo não menciona
No artigo de Grierson a palavra token não aparece nem uma vez. Não há secção sobre a propriedade da chave API. Não há modelo de faturação. Não há cenário em que um agente esgote a quota planeada a meio da semana. A omissão decorre da perspetiva do autor. O artigo provém de uma empresa que vende alojamento e módulos de IA em pacote. Um operador auto-hospedado tem outras prioridades.
A segunda omissão respeita ao registo das ações executadas pelo agente. Cada escrita via MCP altera o estado da base de dados e exige uma entrada de auditoria separada, algo que o artigo não aborda. A terceira omissão é a política de privacidade, que decide que dados de um artigo ou comentário saem do servidor e chegam ao fornecedor de IA. Estas três omissões separam uma visão de um produto pronto a implementar.
Model Context Protocol e Abilities API na prática
O Model Context Protocol é um padrão que permite a agentes de IA ligar-se a sistemas externos. A Automattic implantou o MCP no WordPress.com em duas fases. Leitura primeiro, escrita depois. O WordPress auto-hospedado obtém a mesma capacidade através da Abilities API e do WordPress MCP Adapter.
Apenas leitura em outubro de 2025, escrita em março de 2026
O WordPress.com ativou o MCP em modo de leitura em outubro de 2025. Suporte total para operações de escrita entrou em produção em março de 2026. A partir desse momento, um agente pode criar um artigo, publicá-lo, adicionar um comentário e gerir media através de linguagem natural. Cada operação gera um custo no lado do modelo que a executa.
A consequência prática é simples. Ativar um único plugin que dialoga com um agente transforma cada edição de artigo num pedido a um fornecedor externo de IA. A fatura chega onde a chave API estiver guardada.
O que a Abilities API muda em ambiente auto-hospedado
A Abilities API combinada com o WordPress MCP Adapter permite aos autores de plugins expor funcionalidades existentes como ferramentas para agentes. O adaptador faz a ponte entre as plugin abilities e a especificação MCP. O autor de um plugin existente acrescenta algumas linhas de configuração. O agente passa a ter acesso à funcionalidade.
Este atalho diminui a barreira de entrada, pelo que o número de plugins com funcionalidades de IA no repositório WordPress.org cresce mais depressa do que o número de auditorias de segurança a esses plugins. A WPPoland observa este padrão desde março de 2026 nos clientes inscritos no programa manutenção de sites WordPress.
O papel do WordPress Playground para agentes
O WordPress Playground inicia uma instância completa de WordPress no navegador em segundos. A Automattic posiciona esta ferramenta como caixa de areia para agentes. O agente testa uma alteração no Playground, e apenas a ação confirmada chega à produção. A construção reduz o risco de danos nos dados causados por alucinações do modelo. Não muda quem paga os tokens consumidos.
A lacuna na visão, ou seja, quem paga pelos tokens
Russell Heimlich, programador WordPress com 20 anos no ecossistema, colocou esta pergunta publicamente em WordPress AI Features Are Coming. Nobody Is Talking About What They’ll Cost Your Users, publicado a 24 de abril de 2026. Heimlich, conhecido na comunidade pelo identificador russellenvy, indica que a Automattic não menciona uma única vez a questão dos custos de IA na sua visão agentiva. O ponto é prático. Quando um plugin se instala sozinho, pede ao utilizador para ligar uma conta num fornecedor de IA e abre depois um campo de chat no painel, o utilizador desconhece que cada mensagem custa dinheiro.
O argumento de Russell Heimlich
Heimlich descreve o seu próprio caso a trabalhar com modelos de IA. Utiliza uma subscrição mensal junto do fornecedor do modelo Claude e esgota o limite semanal apesar de otimizações avançadas de prompt e fluxo de trabalho. Daí extrai uma conclusão concreta. Uma pessoa sem experiência com modelos de linguagem, por exemplo um blogger gastronómico que acabou de criar um site e instalou um plugin popular com IA, esgotará a quota mais depressa e sem mensagem de erro clara sobre a causa.
„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 de abril de 2026
Um segundo argumento de Heimlich respeita à responsabilidade pela experiência do utilizador. Um plugin que introduz uma funcionalidade de IA sem mensagem clara de custos transfere o ónus de educar o utilizador para o operador do site e indiretamente para a agência. Um terceiro argumento aborda a reputação da marca WordPress. A primeira vaga de descontentamento perante faturas inesperadas reflete-se em todo o ecossistema, independentemente do facto de a fonte do problema ser um único plugin.
Três modelos de propriedade da chave API e respetivas consequências
Na prática 3 modelos de faturação dos tokens de IA em plugins WordPress dominam o mercado.
Bring-your-own-key. O cliente cria uma conta no fornecedor de IA, gera uma chave e cola-a no painel do plugin. Os custos vão diretamente para o cliente. O autor do plugin não atua como intermediário. O modelo é contabilisticamente transparente e exige que o cliente compreenda como funciona a quota de tokens nesse fornecedor.
Subscrição gerida pelo autor do plugin. O plugin cobra ao cliente uma taxa mensal fixa e acerta contas com o fornecedor de IA. O risco de uso indevido recai sobre o autor do plugin, que equilibra preços com o consumo real. O modelo é cómodo para o utilizador final e arriscado para o operador do plugin.
Quota partilhada com limite mensal. Todos os clientes do plugin partilham uma única quota. Após o esgotamento a quota renova-se no mês seguinte ou expande-se num pacote superior. O modelo simplifica a comunicação ao utilizador e introduz um efeito novo, ou seja, o vizinho a consumir os meus tokens.
Cenário do blogger gastronómico do TikTok
Heimlich descreveu este cenário primeiro. Um blogger viral cria um site WordPress, instala um plugin com IA, percorre o assistente. O assistente pede para ligar uma conta Claude, ChatGPT ou Gemini. O blogger liga a conta porque a instrução o diz. Em seguida trata o campo de IA como um chat normal. Dois dias depois a quota semanal desaparece. O plugin mostra um indicador de carregamento vazio sem mensagem. O blogger culpa o WordPress. Cada parte desta história repete-se em clientes reais hoje.
O que isto significa para os proprietários de sites WordPress antes do lançamento da 7.0
O lançamento do WordPress 7.0 aproxima-se rapidamente. A versão Release Candidate 2 foi publicada em 26 de março de 2026 em wordpress.org. A data de disponibilidade geral ainda não foi confirmada oficialmente nas comunicações do projeto. Independentemente da data exata, a infraestrutura MCP no lado auto-hospedado amadurece em paralelo. Um operador deve executar 3 movimentos antes da primeira vaga de atualizações de plugins com IA incorporada.
Auditoria dos plugins atualmente instalados quanto a IA
Verifique cada plugin instalado contra 3 informações. Se o roadmap do produto inclui um componente de IA na próxima versão. Se o autor do plugin publicou um modelo de faturação de tokens. Se existe opção para desativar funcionalidades de IA sem perder o resto das capacidades do plugin. Plugins sem estas respostas exigem monitorização do changelog entre atualizações.
Na prática 3 categorias de plugins introduzem funcionalidades de IA mais depressa. Plugins de SEO, como Yoast SEO e Rank Math, em que o gerador de meta descrições recorre a um modelo de linguagem. Plugins de calendários e eventos, como The Events Calendar, em que um agente gera descrições de séries de eventos recorrentes. Plugins de e-commerce e CRM, em que um assistente de IA propõe descrições de produtos e respostas a perguntas de clientes. Cada uma destas 3 categorias tem um perfil de consumo de tokens distinto, porque o tamanho de um único prompt difere.
A auditoria completa combina-se bem com uma auditoria de segurança WordPress a cada seis meses. A WPPoland realiza esta auditoria como elemento do programa de manutenção e, desde março de 2026, acrescenta um mapa de funcionalidades de IA nos plugins instalados.
Perguntas a colocar aos fornecedores de plugins
Três perguntas ao autor do plugin antes de ativar o modo de IA são concretas. Primeira, onde fica a chave API e quem a paga. Segunda, qual é a mensagem ao utilizador depois de a quota de tokens estar esgotada. Terceira, se cada ação executada pelo agente é registada de forma a permitir reconstruir o histórico. Autores de plugins sérios respondem em um dia. A ausência de resposta é por si uma resposta.
Configurar o comportamento por defeito quando faltam tokens
Configure o plugin para que a falta de tokens degrade a funcionalidade em vez de bloquear o painel. Três definições resolvem 80 por cento dos problemas. Uma mensagem textual sobre a causa do erro em vez de um indicador de carregamento vazio. Uma cópia local da última resposta bem-sucedida visível como placeholder. A possibilidade de desativar o módulo de IA a partir de um perfil de editor sem alterações ao código.
O que devem fazer os autores de plugins
Os autores de plugins têm maior responsabilidade do que os operadores de sites porque moldam a primeira experiência do utilizador final com um agente de IA. Três princípios de design reduzem o número de clientes surpreendidos depois da primeira fatura.
Mensagem de custo antes do primeiro pedido
O primeiro pedido a um agente é sempre antecedido por uma mensagem. O plugin mostra que ação será executada, quantos tokens serão aproximadamente consumidos e qual a conta de IA a debitar. A mensagem aparece uma vez e a sua ausência custa a confiança do utilizador na primeira surpresa. O padrão está consagrado em ferramentas populares de programador, como GitHub Copilot ou Cursor.
Modo de degradação em vez do indicador vazio
O modo de degradação trata 4 estados da quota de tokens. Acesso completo. Aviso de saldo baixo. Modo só-leitura, em que o agente lê dados mas não gera conteúdo. Modo desativado. Cada estado tem a sua própria mensagem ao utilizador. Um indicador de carregamento vazio não é um estado aceitável, porque um utilizador sem contexto interpreta-o como falha geral da plataforma.
Bring-your-own-key vs. subscrição vs. quota partilhada
A escolha do modelo de faturação afeta 3 áreas em simultâneo, ou seja, a mensagem de instalação, o painel de definições e o procedimento de resposta a incidentes. Bring-your-own-key exige onboarding cuidadoso do cliente. O modelo de subscrição exige negociação de volume com o fornecedor de IA do lado do autor do plugin. O modelo de quota partilhada exige monitorização contra usos indevidos. O autor do plugin documenta a escolha do modelo na documentação do utilizador, não apenas na política de privacidade.
Como uma agência deve preparar o cliente
Uma agência que mantém vários sites de clientes tem 3 pontos a alinhar com cada cliente antes do lançamento do WordPress 7.0. Uma cláusula contratual sobre serviços de IA. Um regime de atualizações de plugins. A comunicação de um incidente após ultrapassar um limite de tokens.
Cláusula contratual sobre serviços de IA externos
A cláusula tem 4 frases. O cliente cobre os custos de tokens junto dos fornecedores externos de IA. A agência informa o cliente de cada nova funcionalidade de IA em plugins mantidos antes da ativação. O cliente autoriza a ativação por escrito. A agência monitoriza o consumo e reporta anomalias num prazo de 48 horas. O padrão resulta de experiência consolidada da WPPoland com clientes empresariais, em que custos externos inesperados degradam a relação mais depressa.
A cláusula descreve ainda um procedimento de emergência em 2 passos. Primeiro, pausa automática dos pedidos do agente após ultrapassar um limiar definido com o cliente. Segundo, contacto da agência com o cliente em modo de trabalho, ou seja, e-mail e telefone dentro do horário do cliente. Um limiar indefinido significa na prática que a primeira informação sobre o excesso chega ao cliente apenas na fatura do fornecedor de IA, o que constitui a causa mais frequente de perda de confiança no primeiro trimestre da colaboração.
Regime de atualizações, ou seja, manual, automático ou após análise
O cliente escolhe 1 de 3 regimes de atualização de plugins. Atualizações manuais, em que a agência implementa a nova versão após testes. Atualizações automáticas com relatório diário de alterações. Atualizações após análise, em que a agência bloqueia a introdução de novas funcionalidades até aprovação do cliente. O regime após análise protege melhor o cliente durante o período de introdução das funcionalidades de IA nos plugins.
O que incluir no briefing para um novo projeto
O briefing de um novo projeto contempla 4 perguntas adicionais face a um briefing de 2024. A primeira, se o cliente aceita a presença de funcionalidades de IA no painel editorial. A segunda, quem detém as chaves API junto dos fornecedores de IA. A terceira, qual o orçamento mensal que o cliente reserva para tokens. A quarta, que cenários de utilizador não devem gerar pedidos ao agente. Estas 4 perguntas respondem às lacunas que a Automattic não fechou na sua visão.
Após estas decisões, um projeto pode usar com segurança a infraestrutura MCP, a Abilities API e o ecossistema de plugins. O operador conhece os custos. O autor do plugin conhece as limitações. O agente de IA tem fronteiras claramente definidas. As restantes forças do WordPress, como o código aberto e a documentação extensa, funcionam sem alteração.
A WPPoland conduz esta conversa com cada cliente desde março de 2026. O mapa completo de práticas é descrito em pormenor em como tornar o site visível para IA e LLMs e em resumo estratégico LLMO. A visibilidade para agentes é um tema próprio, mas o fundamento é o mesmo, ou seja, perceber onde começa e termina a responsabilidade pelo custo de uma consulta.
