Agent Plugins: o novo padrão aberto para extensões de agentes de IA

O que o Agent Plugins realmente é

Construo integrações para viver, então minha primeira reação a qualquer padrão novo é verificar quanto dele é especificação de verdade e quanto é comunicado de imprensa. Este aqui é, em sua maior parte, especificação.

O Agent Plugins se descreve como um padrão aberto e neutro em relação a fornecedores para empacotar componentes reutilizáveis que estendem agentes de IA. Na prática, ele padroniza uma única coisa: o formato da pasta. Onde o manifesto fica, quais campos ele pode conter, onde um cliente deve procurar por skills, e onde deve procurar pela configuração do servidor MCP. Tudo o mais, incluindo instalação, marketplaces, permissões e toda a experiência do usuário, fica a cargo de cada cliente.

O menor plugin que faz alguma coisa tem três arquivos:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

E o manifesto pode ter duas linhas:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

É isso. $schema e name são os únicos campos obrigatórios. Todo o resto, version, description, author, homepage, repository, license, keywords, extensions, é opcional.

O problema que ele resolve é chato e real. Cada cliente de agente desenvolveu seu próprio formato de plugin, então a mesma skill precisava ser reorganizada para cada cliente, e um pacote construído para um precisava ser adaptado antes que outro conseguisse carregá-lo. Se você já manteve o mesmo SKILL.md em quatro estruturas de repositório diferentes, já conhece a forma dessa dor. É a mesma fragmentação que tornava incômodo raciocinar sobre os plugins do ChatGPT e os GPTs e Actions alguns anos atrás, só que agora há mais clientes.

O que entra em um plugin, e o que não entra

A versão 1 define exatamente dois tipos de componentes. Skills e servidores MCP. É um número deliberadamente pequeno, e é a decisão de design mais interessante de todo o documento.

Ambos ficam em locais fixos que o manifesto não tem permissão para sobrescrever. As skills ficam em skills/, um subdiretório para cada uma, contendo um SKILL.md. A configuração MCP fica em mcp.json, na raiz. A especificação é explícita: um cliente não deve recorrer mais fundo procurando skills extras, nem deve aceitar configuração MCP declarada inline dentro de plugin.json.

Quanto ao formato do SKILL.md em si, a especificação delega totalmente: as skills devem estar em conformidade com a especificação Agent Skills, que continua sendo a fonte de verdade para o frontmatter e a estrutura de scripts/, references/ e assets/. O Agent Plugins só diz onde encontrá-las.

Aqui está o que viaja e o que não viaja:

Qualquer coisa que um cliente queira adicionar por conta própria entra em um namespace de domínio reverso, seja como uma chave sob extensions no manifesto, seja como um diretório de nível superior chamado com.example.client/. Outros clientes são obrigados a ignorar namespaces que não implementam, sem sequer validar o que há dentro. É uma regra pequena com uma consequência grande: um plugin pode carregar extras específicos de cliente e ainda assim carregar de forma limpa em todos os outros lugares.

O lado do MCP tem mais rigor do que eu esperava. Três transportes são reconhecidos, stdio, streamable-http e o obsoleto sse, e um cliente compatível deve suportar pelo menos um dos dois primeiros. Endpoints remotos devem usar HTTPS, a menos que o host seja loopback. Todo subprocesso stdio recebe as variáveis de ambiente PLUGIN_ROOT e PLUGIN_DATA, e ${PLUGIN_ROOT} e ${PLUGIN_DATA} se expandem dentro de args, env e cwd, mas em nenhum outro lugar. A contenção de caminhos é aplicada em toda parte, então um command como ../bin/server é inválido, e não apenas desencorajado.

O isolamento de falhas é a parte com a qual eu realmente contaria em produção. Uma entrada MCP quebrada desativa aquele servidor, não o plugin. Um SKILL.md malformado pula aquela skill, não a pasta. Já um plugin que falha na validação de esquema do manifesto é rejeitado por completo, e nenhum de seus componentes roda. Esses limites estão detalhados um a um, o que é um bom sinal de que foi escrito por pessoas que já lançaram esse tipo de coisa antes. Quem já depurou uma integração MCP carregada pela metade vai apreciar essa precisão.

Quais partes da sua extensão realmente viajam

Em vez de descrever a divisão de novo, aqui está a mesma informação para você mexer. Escolha um componente e veja se ele sobrevive a uma mudança entre clientes.

Quem está realmente por trás disso

Padrões vivem ou morrem pela sua governança, então essa é a seção que eu leio primeiro.

O Technical Steering Committee tem cinco pessoas, cada uma nomeada como indivíduo com uma afiliação anexada, em vez de uma empresa ocupando um assento:

O anúncio da Vercel credita um grupo um pouco mais amplo, citando Amazon Web Services, Anysphere, GitHub, Microsoft, OpenAI e Vercel como tendo desenvolvido o padrão juntos.

A carta tem três cláusulas que valem a pena ler duas vezes. Nenhum fornecedor único pode controlar a maioria dos assentos de Core Maintainer. Todos os papéis de governança são ocupados por indivíduos, e nenhum assento é reservado para empresas. E o nome, os logotipos, os domínios e as organizações do GitHub ficam em confiança sob uma entidade neutra designada pelo comitê, sem que nenhum fornecedor possa reivindicar controle exclusivo da identidade do projeto.

O rastro documental confirma isso. O repositório foi incubado em vercel-labs/open-plugin-spec e agora fica sob uma organização separada, agentplugins, com o texto da especificação sob CC-BY-4.0 e o código sob Apache 2.0. Se a alegação de neutralidade algum dia deixar de valer, o licenciamento significa que o projeto pode ser bifurcado em vez de capturado. É praticamente o mesmo manual que a indústria seguiu com o trabalho do agentic commerce protocol, e é um sinal melhor do que um comunicado de consórcio sem repositório por trás.

A ausência com o formato da Anthropic

A Anthropic não aparece na lista de mantenedores, e o Claude Code não está entre os clientes de lançamento citados pela Vercel. Isso vale a pena ponderar, porque o Claude Code é onde acontece atualmente uma parcela muito grande da criação real de plugins, e porque o Agent Skills começou lá.

Os formatos são parecidos, mas não compatíveis. A estrutura de plugin documentada da Anthropic coloca o manifesto em .claude-plugin/plugin.json e a configuração MCP em .mcp.json, ambos caminhos ocultos, enquanto o Agent Plugins usa plugin.json e mcp.json visíveis na raiz. O Claude Code também traz tipos de componentes que o padrão não cobre de forma alguma, e a mesma forma aparece de novo no formato do plugin Cowork e nos plugins de IDE.

Essas são diferenças de caminho de arquivo, o tipo de incompatibilidade mais fácil de corrigir que existe. Um plugin já poderia carregar os dois manifestos hoje sem muito drama. Mas até que alguém faça esse trabalho, um autor que mira nos dois ecossistemas continua mantendo duas estruturas, que é exatamente o problema que o padrão se propôs a eliminar. Eu não leria essa ausência como uma rejeição, e não há declaração pública em nenhum dos dois sentidos. Eu leria isso como algo inacabado.

Vale notar que o mesmo padrão está se repetindo em outros lugares. A Atlassian oferece skills de agente Rovo, a ServiceNow oferece suas próprias skills de agente, e a Freshworks oferece uma biblioteca de skills pré-construídas. Nenhuma delas está no escopo de uma especificação voltada para agentes de codificação, mas é a mesma ideia empacotada de cinco formas diferentes, o que mostra o quão inicial tudo isso ainda é.

O que a versão 1.0.0 deliberadamente deixa de fora

Essa é a seção que eu gostaria que um revisor de segurança lesse antes de qualquer pessoa instalar qualquer coisa.

Os mantenedores são refrescantemente diretos sobre as lacunas. Um documento dedicado de future considerations lista, como coisas que a v1.0.0 não define:

• Um modelo de confiança, sistema de permissões ou sandboxing. Sem declarações de capacidade, sem fluxos de consentimento, sem níveis graduais de confiança.
• Verificação de proveniência. Sem checagem de assinatura, sem atestado ligando um plugin publicado ao seu repositório de origem.
• Tratamento de segredos. A especificação proíbe credenciais em env e nos headers HTTP, e não oferece nenhuma alternativa portátil.
• Controles empresariais. Sem listas de permissão, sem listas de bloqueio, sem registros com escopo de organização, sem substituições de política centralizadas.
• Trilhas de auditoria. Sem um esquema de eventos padrão para instalação, ativação, atualização ou desinstalação.
• Resolução de dependências. Plugins não podem declarar dependências de outros plugins.

A especificação de fato traz regras reais de segurança onde consegue: os caminhos devem permanecer dentro da raiz do plugin, endpoints MCP que não sejam loopback devem usar HTTPS, cabeçalhos configurados não devem ser encaminhados através de um redirecionamento para uma origem diferente sem autorização explícita do usuário, e clientes não devem buscar um esquema pela rede enquanto carregam um plugin. Tudo isso é sensato. Mas também é tudo sobre o pacote, não sobre o que esse pacote tem permissão para fazer depois.

Então a leitura honesta é esta. O Agent Plugins resolve a distribuição. Ele não resolve a confiança. Um servidor MCP dentro de um plugin pode iniciar um processo arbitrário com seu ambiente, e o padrão não diz nada sobre se isso deveria ser permitido. Se isso é adequado ou não depende inteiramente de em qual cliente você o instala e de quais controles de permissão esse cliente por acaso traz. Do lado do Claude Code, isso significa controles de administrador e settings.json; em outros lugares, significa o que aquele fornecedor decidiu.

O que isso significa se você compra agentes de IA em vez de construí-los

A maioria das pessoas lendo sobre uma especificação de plugins são desenvolvedores. Mas o efeito de segunda ordem recai sobre qualquer um que esteja avaliando agentes de IA para uma função de negócio, e o suporte é o caso mais claro.

O argumento de venda de um formato de plugin portátil é que sua extensão não fica refém de um único fornecedor. Isso é real, e é um bom motivo para preferir clientes que o adotam. Também é mais limitado do que parece, porque a portabilidade do pacote não é a portabilidade do resultado. O fato de o seu SKILL.md se mover de forma limpa entre dois clientes não significa que o agente se comporte da mesma forma em ambos, que tenha as mesmas permissões de ferramentas, ou que resolva a mesma proporção de tickets. Esse último número é o que paga o projeto, e é nisso que um agente de IA para atendimento ao cliente realmente é julgado.

Vejo o mesmo raciocínio se repetir constantemente em conversas sobre construir versus comprar. Um líder de engenharia com quem trabalhamos resumiu essa conta melhor do que eu conseguiria:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

Esse é um líder de engenharia que administra uma base de conhecimento com mais de 300 artigos no Confluence e no Telegram, e que escolheu comprar em vez de construir. Um padrão reduz o custo de montar as peças. Ele não faz nada quanto ao custo contínuo de possuir o resultado, e é aí que esses projetos realmente ficam caros.

As três perguntas que eu faria a qualquer fornecedor, com ou sem padrão:

1. Consigo exportar o que ensinei a ele? Prompts, regras, lógica de escalonamento. Se a resposta for não, um formato de plugin portátil não muda nada sobre o seu lock-in.
2. Quem decide o que ele pode tocar? Como a v1 não define nenhum modelo de permissões, essa é uma resposta que varia por cliente, e você deveria obtê-la por escrito antes que qualquer coisa chegue a uma fila em produção. Para equipes reguladas, isso se encaixa diretamente na sua revisão de privacidade de dados.
3. Consigo testá-lo contra o meu próprio histórico antes de ele entrar no ar? Uma simulação contra cenários escritos por alguém não é o mesmo que um teste real sobre os seus próprios tickets passados.

Essa terceira pergunta é a que eu não comprometeria. Já vimos um bot de voz confiante dar respostas erradas silenciosamente, o que explica exatamente por que toda implantação na eesel é simulada primeiro contra tickets históricos, em vez de simplesmente ligada e observada.

Experimente a eesel para um suporte que se conecta ao que você já usa

A eesel pega a mesma ideia que o Agent Plugins está perseguindo, encontrar você onde você já trabalha, e a aplica ao helpdesk. Ela se conecta ao Zendesk, ao Freshdesk e ao Gorgias, além de Slack, Confluence e o resto da sua base de conhecimento interna, depois redige ou resolve a partir do que aprende ali.

O diferencial é a terceira pergunta acima. Antes de a eesel responder a um único ticket em produção, você a executa sobre o seu próprio histórico de tickets e vê o que ela teria dito, em quais tickets, com qual confiança. Depois você escolhe quais tipos de ticket ela tem permissão para tocar. É grátis para experimentar, e a configuração leva minutos, não um trimestre.

Para onde isso vai a partir daqui

Minha leitura depois de um dia com a especificação: o formato é pequeno o suficiente para ser adotado rapidamente, a governança é mais forte do que a da maioria dos padrões em sua primeira versão, e a história de segurança é um buraco deliberado com um roteiro anexado. Uma especificação mínima que é lançada vence uma abrangente que ainda está em debate, e o Agent Plugins é claramente a primeira.

As duas coisas que eu ficaria de olho. Se a Anthropic vai convergir, já que a lacuna é basicamente dois caminhos de arquivo e o equivalente aos tipos de componentes extras de todo um ecossistema. E se a v1.1 vai trazer um modelo de permissões antes que alguém lance um plugin que faça todo mundo desejar que ele já existisse.

Se você está escolhendo ferramentas de agente de IA agora, seja um agente de codificação como o Cursor ou uma CLI agêntica, trate o suporte ao Agent Plugins como um sinal levemente positivo sobre a postura de um fornecedor em relação ao lock-in. Depois trate as respostas dele sobre permissões e testes como o que realmente decide a questão.