Eu já acompanhava o trabalho de Jorge Costa há algum tempo. Quando fui conferir seu histórico, encontrei contribuições em Gutenberg, Site Editor, edição colaborativa e DataViews. Além disso, esse percurso agora inclui agentes de IA no WordPress.

Assim, convidei Jorge para uma conversa. Eu queria ir além da lista de APIs. Como um projeto com mais de 20 anos adota uma tecnologia que muda toda semana sem abandonar os sites existentes?

A resposta não foi colocar um chatbot no painel. Foi criar contratos, permissões e camadas. Dessa forma, a comunidade pode experimentar sem amarrar o WordPress a um único provider ou protocolo.

De usuário do WordPress a developer do Core

Jorge começou a usar WordPress em 2007 ou 2008, ainda adolescente. Naquela internet, criar um blog era uma das principais formas de publicar ideias e aprender sobre tecnologia.

Ele montava sites sem dominar HTML ou programação. Assim, a vontade de customizar temas abriu o caminho para o desenvolvimento. Cerca de dez anos depois, Jorge passou a contribuir com o Core do projeto que havia usado para aprender.

Seu perfil oficial no WordPress.org registra participação em 21 releases, sendo 17 como Noteworthy Contributor. Além disso, esse percurso inclui o início do Gutenberg, o Site Editor, protótipos de edição colaborativa e a modernização das interfaces administrativas.

O histórico ajuda a explicar sua visão sobre inteligência artificial. Afinal, o WordPress não começa do zero a cada mudança de paradigma.

Modernizar sem quebrar o que já funciona

A interface usada por Jorge em 2007 tem pouco em comum com o WordPress atual. Porém, parte da fundação continua reconhecível. Custom fields, por exemplo, já existiam à época e ainda hoje sustentam milhares de integrações.

Essa continuidade cobra um preço. Em um novo projeto, uma equipe pode descartar uma API e recomeçar. No WordPress, a mesma decisão pode quebrar sites e workflows mantidos há anos.

A retrocompatibilidade torna algumas mudanças mais lentas, mas sustenta a confiança do ecossistema. Consequentemente, quem mantém um plugin não espera reescrever todo o produto a cada atualização.

Essa discussão também vale para o vibe coding. Um agente pode gerar uma aplicação rapidamente. No entanto, alguém ainda precisa cuidar da segurança, das atualizações, dos dados e da manutenção contínua. O WordPress já conta com uma comunidade dedicada a esse trabalho.

A estratégia não é colocar um chatbot no painel

O Core AI Team está construindo as fundações, não impondo uma interface de IA. Quatro peças ajudam a entender a estratégia:

• AI Client do WordPress: entrou no Core na versão 7.0 e oferece a função wp_ai_client_prompt() para plugins chamarem modelos. Por baixo, usa o PHP AI Client, uma biblioteca independente do WordPress.
• Connectors API: registra conexões com providers e outros serviços externos. Dessa forma, ela separa o recurso de IA da configuração usada para autenticar o serviço.
• Abilities API: descreve operações que o WordPress, um plugin ou um tema podem executar, com entradas, saídas e permissões definidas.
• MCP Adapter: projeto oficial distribuído separadamente do Core. Assim, ele permite que clientes MCP descubram e executem as abilities selecionadas.

Em resumo, cada camada possui uma responsabilidade. O AI Client abstrai chamadas aos modelos. A Abilities API descreve o que os plugins podem fazer. Já o MCP Adapter conecta abilities a clientes externos.

Expliquei a implementação dessas camadas no post sobre WordPress 7.0, PHP AI Client, Abilities API e MCP. No entanto, a entrevista revelou outro ponto. As abilities precisam continuar úteis mesmo se o protocolo atual perder espaço amanhã.

Abilities API: o contrato entre plugins e agentes

Durante a conversa, comparei a Abilities API ao estoque de uma loja. Assim, ela organiza as operações disponíveis, os dados de entrada e os resultados. Por outro lado, o MCP funciona como uma vitrine capaz de apresentar parte desse catálogo a clientes externos.

Jorge completou a analogia. Para cada ability, o plugin define quatro elementos básicos:

• Quais dados podem entrar;
• Qual resultado deve sair;
• Qual callback executa a operação;
• Quem tem permissão para usá-la.

Em outras palavras, essa estrutura lembra Function Calling. O modelo não tem acesso irrestrito ao painel. Ele recebe um catálogo de operações com contratos definidos.

Desde o WordPress 6.9, a Abilities API faz parte do Core. Além disso, na API PHP, cada ability precisa declarar uma permission_callback. Ela decide se o usuário atual pode executar aquela operação.

No WordPress 7.0, o Core adicionou as APIs JavaScript @wordpress/abilities e @wordpress/core-abilities. Dessa forma, o mesmo modelo também atende ações no admin, integrações no browser e novas interfaces construídas em JavaScript.

Três controles independentes protegem cada operação

Conectar um agente ao WordPress não exige liberar o painel inteiro. A arquitetura separa três decisões:

1. Registro: o plugin registra a ability com descrição, schemas, callback de execução e permission_callback.
2. Exposição: o developer escolhe se a ability aparece no canal desejado. Na REST API, a exposição precisa resultar em show_in_rest: true. No WordPress 7.1, esse valor também pode vir de meta.public, enquanto a configuração específica do canal continua tendo precedência. No MCP Adapter, a exposição usa configuração própria.
3. Autorização: na REST API, o cliente precisa autenticar-se como usuário. Em qualquer canal, a execução continua sujeita à permission_callback.

As annotations readonly, destructive e idempotent descrevem o comportamento de uma ability. Porém, elas não substituem a autenticação nem a verificação de capabilities.

Essa separação limita o escopo dos agentes de IA no WordPress, mas não corrige uma implementação insegura. O plugin ainda precisa validar entradas, verificar permissões e identificar operações que alterem ou apaguem dados.

Para ações sensíveis, eu adicionaria aprovação humana antes da execução. Assim, a IA pode sugerir e automatizar, mas a autorização continua a respeitar os papéis e as regras do site.

Como descobrir o que agentes de IA no WordPress podem fazer

Existe um detalhe importante: uma ability registrada não precisa aparecer em todos os lugares. O developer pode disponibilizá-la pela REST API e mantê-la fora do MCP, por exemplo.

Por isso, a descoberta precisa acontecer no contexto em que a operação será usada:

• Abilities Explorer: o plugin de IA oferece uma interface para listar, inspecionar e testar abilities.
• REST API: um cliente autenticado pode consultar GET /wp-json/wp-abilities/v1/abilities para descobrir as abilities expostas nesse canal.
• MCP: no servidor padrão, o cliente usa discover-abilities para consultar operações e execute-ability para executá-las. Servidores personalizados podem expor abilities diretamente como tools, resources ou prompts.

O handbook da REST API de Abilities explica os endpoints, a autenticação e o controle com show_in_rest.

O exemplo que transforma API em workflow

Jorge deu um exemplo concreto: um site recebe mais de 100 formulários por dia. Dessa forma, um agente pode classificar as mensagens, identificar leads e sugerir prioridades antes da revisão humana.

Com abilities bem definidas, o workflow pode seguir estes passos:

1. consultar novas submissões;
2. classificar o assunto de cada mensagem;
3. identificar o estágio de cada lead;
4. sugerir uma ordem de atendimento;
5. preparar uma resposta para revisão.

Outra ability pode continuar o processo. Por exemplo, o agente pode criar uma tarefa, atualizar um registro ou gerar um cupom em uma loja. Cada etapa, contudo, respeita as permissões do usuário conectado.

Esse encadeamento mostra por que a Abilities API vai além de IA. Assim, ela cria uma linguagem comum para plugins, automações e interfaces conversarem sem depender de integrações improvisadas.

O plugin AI é a face visível dessa infraestrutura

As APIs criam a base para developers. Já o plugin AI funciona como laboratório de experiências para quem produz e administra conteúdo.

Na demonstração, vimos recursos para gerar texto alternativo, títulos, resumos e imagens. Além disso, o plugin oferece classificação de conteúdo, assistência na moderação de comentários e o Abilities Explorer.

Os módulos são independentes. Para gerar conteúdo, o site precisa ter um AI Connector compatível, autenticado e capaz de realizar aquela operação. Um administrador, um provedor de hospedagem ou uma agência pode configurar as credenciais. Além disso, providers locais também são uma opção.

O plugin é canônico e experimental. Por isso, as funcionalidades recebem feedback antes de qualquer consideração para o Core. A página do plugin no WordPress.org lista português do Brasil entre os idiomas disponíveis.

Atualmente, o plugin AI requer o Block Editor. Ele não oferece suporte oficial ao Classic Editor ou a experiências de edição que não usam blocos.

Por que o WordPress 7.1 é uma release de fundação

No momento desta revisão, o WordPress 7.1 está no Beta 4. A versão final está prevista para 19 de agosto de 2026. Como ainda estamos no ciclo beta, correções podem entrar antes do lançamento.

Na área de IA, a release aprofunda as APIs existentes. wp_get_abilities() ganhou filtros por categoria, namespace e metadados. Além disso, a REST API passou a converter os parâmetros recebidos para os tipos definidos no input_schema.

Connectors ganhou autenticação com nome de usuário e Application Password. Isso amplia os tipos de serviço que podem usar a tela Settings > Connectors, além do fluxo original com API keys.

A mesma cautela aparece na modernização do admin. DataViews cria visualizações interativas de conjuntos de dados. DataForm renderiza formulários a partir de definições declarativas de fields e de uma configuração de layout. A migração acontece aos poucos para não remover botões e extensões injetados por plugins.

Como Jorge resumiu durante a conversa, a funcionalidade continua sendo mais importante do que o visual. Os workflows das pessoas precisam sobreviver à modernização da interface.

Fora da área de IA, ele citou o widget On This Day e o Playlist block. O primeiro recupera posts publicados na mesma data em anos anteriores. O segundo organiza uma coleção de áudios com lista de faixas e visualização da forma de onda.

Embeddings ficaram fora do WordPress 7.1

Embeddings representam conteúdo como vetores numéricos. Eles ajudam a encontrar itens relacionados pelo significado, mesmo quando os textos não usam as mesmas palavras.

Desde 15 de julho de 2026, o PHP AI Client 1.4.0 oferece APIs para gerar embeddings. Porém, essa é apenas a camada de comunicação com os modelos.

A integração correspondente no WordPress Core não entrou no 7.1. Em 31 de julho, o ticket oficial está direcionado ao WordPress 7.2. Portanto, embeddings não fazem parte do WordPress 7.1.

Também vale separar geração de embeddings de busca semântica completa. O PHP AI Client não fornece, sozinho, armazenamento vetorial, indexação ou busca de conteúdo dentro do WordPress.

Como acompanhar e participar

Se você quer explorar agentes de IA no WordPress, comece por uma ability de escopo pequeno e somente leitura. Teste o retorno, revise as permissões e avance para escrita apenas quando o contrato estiver claro.

O plugin AI ajuda a inspecionar essas operações no Abilities Explorer. Para acompanhar as decisões, entre no Slack do projeto WordPress e participe do canal #core-ai. As discussões, reuniões e propostas do time são abertas à comunidade.

Jorge também está disponível pelo perfil no WordPress.org, que reúne seus links e atividades recentes.

O trabalho invisível por trás dos agentes

A parte mais importante da IA no WordPress talvez seja justamente a menos chamativa. Antes de agentes criarem posts, analisarem formulários ou administrarem produtos, o Core precisa definir contratos, permissões e caminhos de compatibilidade.

Esse trabalho não produz apenas uma nova tela. Ele prepara o ecossistema para experimentar sem abandonar sites, plugins e workflows existentes.

É uma estratégia menos chamativa do que colocar um chatbot no painel, mas também mais durável. Quem desenvolve plugins já pode contribuir. Por exemplo, registre uma ability de leitura, teste-a no Abilities Explorer e leve o feedback ao canal #core-ai.

Fontes consultadas

• WordPress 7.1 Beta 4
• Cronograma oficial do WordPress 7.1
• Documentação oficial da Abilities API
• REST API endpoints das Abilities
• Client-side Abilities API no WordPress 7.0
• AI Client no WordPress 7.0
• Connectors API no WordPress 7.0
• Application Password nos Connectors do WordPress 7.1
• Filtros de wp_get_abilities() no WordPress 7.1
• Conversão de inputs REST conforme o schema
• Plugin AI no WordPress.org
• Abordagem do WordPress AI Team
• MCP Adapter no GitHub
• @wordpress/dataviews
• Roadmap oficial do WordPress 7.1
• PHP AI Client 1.4.0
• Ticket de integração de embeddings
• Perfil de Jorge Costa no WordPress.org