Agent Plugins 1.0: O Padrão Que Finalmente Empacota Skills e MCP Juntos

Tem uma pasta no meu repositório interno que eu evito abrir. Ela guarda três versões da mesma skill de revisão de PR: a que roda no agente de codificação que o time usa por padrão, a que roda no assistente da IDE de metade das pessoas e a que colamos no editor de quem migrou no começo do ano. O conteúdo útil — o texto que explica o que olhar num diff, quais convenções do repositório valem, quando escalar para humano — é o mesmo nas três. O que muda é o envelope: nome de arquivo, campo de frontmatter, caminho onde a ferramenta procura, e a maneira de declarar que aquela skill precisa de um servidor MCP no ar para funcionar direito.

O incômodo não é o trabalho de copiar. É que toda vez que alguém melhora a versão de um cliente, as outras duas ficam para trás em silêncio. Não quebra nada, não acende alerta, ninguém abre chamado. Simplesmente, três meses depois, metade do time está sendo revisada por uma versão da regra que a outra metade já abandonou. Foi assim que eu descobri que o problema de portabilidade de skill não é um problema de conveniência de desenvolvedor. É um problema de consistência de comportamento entre pessoas do mesmo time.

Em 6 de agosto a OpenAI Developers anunciou o Agent Plugins, com a especificação 1.0.0 publicada, feita junto com AWS, Cursor, GitHub, VS Code e Vercel — e com o Google publicando sobre o assunto no próprio Developers Blog no mesmo movimento. É um padrão aberto e vendor-neutral que faz uma coisa só: empacota Agent Skills e servidores MCP num único formato distribuível, que qualquer cliente compatível sabe abrir. Onze dias depois, já passei tempo suficiente com a especificação para ter uma opinião formada, e ela é mista.

Este post cobre três coisas: o que o formato é de fato, em nível de estrutura de diretório; o que ele resolve e o que ele deliberadamente não resolve; e o detalhe do anúncio que eu acho mais interessante e que quase ninguém está comentando — quem está no comitê técnico, e quem não está.

O Que Foi Anunciado, E Por Que Não É Mais Um Marketplace

A primeira coisa a esclarecer, porque a palavra "plugin" carrega bagagem: Agent Plugins não é uma loja, não é um runtime e não é um SDK. É um formato de empacotamento. A especificação descreve como organizar um diretório para que ferramentas diferentes consigam ler dele o que sabem ler, e ignorar o resto sem quebrar.

Isso soa modesto porque é modesto de propósito. O 1.0.0 é deliberadamente pequeno. Não há definição de ciclo de vida, não há gerenciador de pacotes canônico, não há modelo de permissão embutido. O que existe é um contrato de descoberta: todo cliente compatível procura um plugin.json na raiz do pacote. Quem suporta Agent Skills vai olhar dentro de skills/. Quem suporta MCP vai ler mcp.json. Ponto.

A lista de quem assinou é o que dá peso ao anúncio. Amazon, Cursor, GitHub, Microsoft com o VS Code, OpenAI e Vercel construíram a coisa em conjunto, e o Google apareceu na sequência com post próprio. Na prática, o formato funciona em ChatGPT, Codex, Cursor, GitHub Copilot, Kiro e VS Code. Não é um consórcio de intenção com nota à imprensa e nenhuma implementação — os clientes que representam a maior parte da superfície diária de trabalho de quem escreve código com IA hoje já leem o formato.

O comitê técnico diretivo inicial reúne pessoas de Amazon, Cursor, Microsoft, OpenAI e Vercel, com Jonathan Hefner, da Vercel, como Lead Core Maintainer. Guarde esse parágrafo, porque volto a ele mais adiante — é a parte do anúncio que mais me fez pensar, e não pelo motivo óbvio.

Vale situar isso no lugar certo do stack antes de continuar. No mapa das cinco camadas que escrevi ontem, Agent Plugins é uma coisa da camada de protocolo — a camada em que a pergunta é se você tem um problema de integração ou de interoperabilidade. Só que ele não é um protocolo no sentido do MCP ou do A2A. Ele não define conversa entre partes. Define empacotamento do que já foi definido em outro lugar. É uma camada acima, e essa distinção decide boa parte do que ele consegue e do que ele não consegue fazer.

A Estrutura Do Formato, Que Cabe Em Uma Tela

O jeito mais rápido de entender o Agent Plugins é olhar o diretório. Não tem truque: é um pacote com um manifesto obrigatório e três coisas opcionais ao redor dele.

meu-plugin/
├── plugin.json              # obrigatório, na raiz
├── skills/                  # opcional
│   ├── revisao-de-pr/
│   │   └── SKILL.md
│   └── migracao-de-schema/
│       ├── SKILL.md
│       └── scripts/
├── mcp.json                 # opcional: servidores MCP declarados
└── com.example.client/      # opcional: namespace de cliente
    └── ...                  # capacidades fora do contrato portátil

O plugin.json na raiz é o único item obrigatório e é o ponto de entrada universal: é o que todo cliente compatível procura primeiro. A pasta skills/ segue exatamente o que a especificação de Agent Skills já define — um subdiretório por skill, cada um com seu SKILL.md, mais os arquivos de apoio que a skill precisar. Nada foi reinventado ali, e essa foi uma decisão inteligente: o formato SKILL.md já era padrão de fato entre agentes de codificação antes de qualquer tratado ser assinado. Formalizar o que já vinha acontecendo custa menos adoção do que propor algo novo e melhor.

O mcp.json declara os servidores MCP de que o plugin depende. É a peça que resolve o problema que mais me incomodava no dia a dia: uma skill que precisa de ferramenta viva para funcionar deixava de ser um arquivo de texto e passava a ser um arquivo de texto mais um pedaço de configuração que morava em outro lugar, com outro ciclo de vida, e que a pessoa que instalava a skill frequentemente não instalava junto. O resultado prático disso era skill que parecia funcionar e silenciosamente não fazia metade do que prometia. Juntar declaração de capacidade e declaração de dependência no mesmo pacote é menos glamouroso do que um protocolo novo e resolve mais problema real.

O quarto item é o que eu acho mais bem pensado: o diretório com namespace do cliente, no formato com.example.client/. É o escape hatch explícito para tudo que está fora do contrato portátil da 1.0. Se um cliente tem uma capacidade própria — algum tipo de hook, algum formato de configuração que só ele entende —, ela mora ali dentro, sob um namespace que identifica de quem é. E a regra que fecha o desenho: clientes ignoram namespaces que não implementam.

Essa última frase parece detalhe de especificação e é decisão de arquitetura. Ela é o que permite que o núcleo seja pequeno sem que o padrão vire uma camisa de força. Sem escape hatch, cada fornecedor com uma capacidade própria teria duas opções: pressionar o comitê para colocar a capacidade dele no núcleo, ou quebrar o formato. Com escape hatch, ele publica no próprio namespace, o mercado decide se aquilo pega, e o que pega tem chance de subir para o contrato portátil numa versão futura. É extensibilidade com caminho de promoção, e é exatamente o mecanismo que faltou em vários padrões que morreram grandes demais na primeira versão.

A Ausência Da Anthropic No Comitê É O Fato Mais Interessante Do Anúncio

Agora a parte que eu não consigo deixar passar. As duas peças que o Agent Plugins empacota vieram da Anthropic. O MCP foi criado lá. O formato Agent Skills também nasceu lá. E a Anthropic não está no comitê técnico diretivo inicial.

Quero ser cuidadoso aqui, porque é fácil escorregar. Não sei por que ela não está. Não tenho fonte sobre convite feito e recusado, sobre convite não feito, sobre conversa que travou, sobre decisão estratégica de qualquer um dos lados. Qualquer pessoa afirmando saber a motivação está inventando. O que eu tenho é o fato: um padrão que empacota duas contribuições da Anthropic foi lançado com um comitê diretivo formado por Amazon, Cursor, Microsoft, OpenAI e Vercel, e ela não aparece nele.

O que dá para dizer com honestidade é o que isso significa em termos de governança, independente do motivo. Quando o criador de uma tecnologia não participa do órgão que decide a evolução do padrão construído sobre ela, aparece uma bifurcação potencial. O MCP evolui num lugar. O Agent Plugins, que depende de como o MCP é declarado e consumido, evolui em outro. Enquanto as duas evoluções caminharem na mesma direção, ninguém sente. No dia em que divergirem — e padrões vivos divergem —, quem paga a conta é quem publicou plugin.

Vale registrar que isso não é anômalo na história de padrões abertos. Tecnologia doada ao ecossistema sendo governada por um comitê que não inclui o autor original acontece o tempo todo, e às vezes é justamente o sinal de que a tecnologia deixou de ser de uma empresa e virou infraestrutura de verdade. Um padrão que só evolui com aprovação de quem o criou não é um padrão aberto, é um produto com documentação pública. Nesse enquadramento, a ausência é evidência a favor da neutralidade do formato, não contra.

Mas tem a leitura oposta, e ela também é defensável. Comitê inicial estabelece precedente. As decisões da 1.1 e da 2.0 vão sair dessas cinco cadeiras, e elas vão decidir coisas como o que sobe do namespace de cliente para o contrato portátil — que é, na prática, decidir qual fornecedor tem sua capacidade proprietária promovida a padrão e qual continua num diretório que os outros ignoram. Isso é poder concreto, não simbólico. E é poder que, no caso específico, está distribuído entre atores que competem diretamente com quem criou as duas peças empacotadas.

Minha leitura pessoal, marcada como leitura e não como fato: para quem toma decisão de arquitetura, a ausência importa menos do que a assimetria que ela cria. Você agora tem uma pilha em que a camada de baixo (o MCP, o formato SKILL.md) evolui sob uma governança e a camada de empacotamento evolui sob outra, sem sobreposição de gente entre as duas. Isso não é motivo para não adotar. É motivo para não assumir que a compatibilidade que existe hoje é uma propriedade permanente do sistema. Fixe versão, teste em mais de um cliente antes de distribuir internamente, e trate "funciona nos seis clientes" como algo que você verifica, não como algo que a especificação promete.

Também acho relevante notar o que o padrão fez com o A2A, que é: nada. Escrevi em A2A, o protocolo horizontal que completa o MCP que a camada de negociação entre agentes com donos diferentes é um problema distinto do de integração com ferramenta. O Agent Plugins 1.0 empacota skills e MCP, e não toca em agente-para-agente. Faz sentido para uma primeira versão minimalista. Mas quem estiver desenhando um sistema em que agentes de times diferentes conversam deve saber que esse pacote não cobre esse caso, e que não há indicação pública de que vá cobrir.

O Que O Padrão Resolve De Verdade

Tirando a política de lado, o ganho técnico é real e é chato no bom sentido. O Agent Plugins acaba com o reempacotamento por ferramenta. Aquela pasta com três versões da mesma skill de revisão de PR passa a ser um diretório só, com um plugin.json, um skills/revisao-de-pr/SKILL.md e um mcp.json declarando o servidor de que ela depende. Quem usa Codex lê. Quem usa Cursor lê. Quem usa Copilot no VS Code lê. Quem usa Kiro lê.

O segundo ganho é menos visível e mais importante: unidade de versionamento. Hoje, quando eu digo que o time usa "a skill de revisão versão 4", essa frase não tem referente único — existe a versão 4 em três dialetos, que divergem no dia em que alguém corrige uma delas. Com um pacote, existe um artefato que se fixa, se assina, se coloca em inventário e se compara. Isso conecta direto com o que argumentei em a corrida dos skills e o risco de segurança dos marketplaces: a mudança mental necessária é parar de tratar skill como arquivo de preferência e começar a tratá-la como dependência de terceiro. Dependência precisa de unidade. Agora tem.

O terceiro ganho é para quem distribui, não para quem consome. Se você mantém uma ferramenta interna de plataforma e quer que os agentes do time saibam usá-la, hoje você escreve a documentação para o agente, escreve o servidor MCP, e depois escreve três guias de instalação diferentes explicando onde cada coisa vai em cada cliente. Com o formato, você publica um pacote. A economia aqui não é de horas de escrita, é de suporte: some a categoria inteira de "instalei e não funcionou" que vem de configuração parcial.

O Que Ele Não Resolve, E Isso Importa Mais

Agora a lista do que a 1.0.0 explicitamente não faz, porque é aqui que vejo mais gente projetando expectativa em cima do anúncio.

Ele não define runtime. Não diz como a skill executa, com que privilégio, em que processo, com acesso a quê. Dois clientes podem ler o mesmo pacote e executar de formas radicalmente diferentes, e ambos estarão em conformidade com a especificação. Isso significa que "funciona no Cursor" não é evidência de que funciona igual no Copilot — é evidência de que os dois conseguiram ler o manifesto.

Ele não define permissão. Não há modelo de capabilities, não há declaração do tipo "esta skill precisa ler o sistema de arquivos e falar com a rede", não há mecanismo para o cliente negar uma parte e permitir outra. Já apontei antes que campos de controle no frontmatter de skill são experimentais e podem simplesmente não ser suportados pelo agente que está rodando — e o modo de falha aí é o pior possível, porque a incompatibilidade solta o freio em vez de travar a roda. O Agent Plugins não conserta isso. Ele empacota o problema junto com a skill.

Ele não define confiança. E este é o ponto que eu gostaria que fosse dito mais alto no noticiário do anúncio: o problema de segurança de supply chain de marketplace continua absolutamente idêntico ao que era em 5 de agosto. Um pacote portátil é um pacote que instala com um comando em seis clientes diferentes, escrito por alguém que você não conhece, contendo instruções em linguagem natural que o seu agente vai seguir e uma declaração de servidores MCP que o seu ambiente vai subir. Formato comum aumenta a superfície de distribuição sem adicionar uma única linha de verificação. É um multiplicador, e multiplicador é neutro quanto ao sinal do que multiplica.

Vale dizer também que padronizar o empacotamento não torna o MCP mais adequado do que ele é. Continuo achando o que escrevi em MCP por default é erro, e quando o protocolo vira overhead: para muita coisa que time coloca atrás de um servidor MCP, uma função direta resolve com menos peça móvel, menos latência e menos superfície. A facilidade de empacotar e distribuir MCP num plugin torna mais provável que alguém adicione um servidor onde não precisava. Ferramenta que reduz atrito de adoção sempre reduz também o atrito de adoção errada.

O que fica dessa lista é uma leitura simples: o Agent Plugins resolve um problema de distribuição, e problemas de distribuição são reais e valem ser resolvidos. Ele não resolve nenhum problema de segurança, nenhum de execução e nenhum de governança do que roda. Quem esperava que um padrão aberto trouxesse junto uma noção de confiança está esperando de um formato de arquivo algo que formato de arquivo não faz.

O Que Eu Faria Com Isso Na Prática

Na segunda-feira, a primeira coisa que eu faria não é migrar nada. É inventariar. Levantar quantas skills o time realmente mantém, quantas cópias divergentes existem de cada uma e quais dependem de servidor MCP para funcionar. Na minha experiência, esse levantamento sempre devolve dois números desconfortáveis: mais skills do que alguém imaginava, e mais divergência entre cópias do que alguém admitiria. Sem esse mapa, migrar para um formato novo é reempacotar bagunça com etiqueta melhor.

A segunda coisa é escolher uma skill — uma só — que seja usada por gente em clientes diferentes, e empacotá-la. Não a mais crítica; a mais compartilhada. O objetivo não é ganhar produtividade nesse primeiro pacote, é descobrir na prática onde os seis clientes divergem no comportamento apesar de lerem o mesmo manifesto. Essa lista de divergências é a informação que vale, e ela não está em nenhuma documentação porque é justamente o que o padrão não especifica.

A terceira é decidir a política de distribuição antes de precisar dela. Plugin de terceiro entra? Se entra, passa por quê? Quem revisa o mcp.json de um pacote antes de ele subir servidor no ambiente de alguém? A resposta pode perfeitamente ser restritiva no começo — só plugins internos, publicados de um repositório nosso, com versão fixada. O que não pode é a resposta ser inexistente na semana em que alguém descobre que dá para instalar um pacote pronto com um comando.

A quarta, e essa é a que eu tenho menos certeza: não fixaria a arquitetura interna do time no formato ainda. A 1.0.0 é pequena de propósito, o que é bom, mas também significa que várias coisas que times usam de verdade vão morar em namespace de cliente por enquanto. Construir sua distribuição interna inteira em cima de um contrato que ainda vai crescer — sob governança de um comitê do qual não participa nem quem criou as peças empacotadas — é apostar em estabilidade que ninguém prometeu. Use para o que ele já resolve bem: distribuição de skill portátil. Deixe o resto onde está por mais um ou dois trimestres.

Conclusão

O que me chama atenção no Agent Plugins não é a ambição, é a falta dela. A especificação é pequena, faz uma coisa, e a coisa que ela faz é a menos glamourosa do problema inteiro: onde os arquivos ficam. Depois de dois anos vendo padrão nascer grande, prometendo resolver orquestração, permissão, confiança e descoberta de uma vez, um formato que só diz "o manifesto vai na raiz e chama plugin.json" me parece mais provável de sobreviver. Padrão que faz pouco tem menos chance de estar errado sobre muita coisa.

Sobre a ausência da Anthropic, fico com uma posição que não fecha. Por um lado, padrão governado por quem o criou não é padrão aberto, e um comitê sem o autor original é a forma normal de uma tecnologia virar infraestrutura comum. Por outro, a governança da camada de baixo e a da camada de empacotamento agora vivem em lugares separados, sem gente em comum, e eu não sei o que acontece na primeira vez em que elas discordarem. Não tenho fonte sobre motivação de ninguém e não vou fingir que tenho. Tenho o fato, tenho a assimetria que ele cria, e tenho a recomendação prática que sai dela: fixe versão e verifique em mais de um cliente, porque a compatibilidade de hoje é uma observação, não uma garantia.

A pergunta que fica comigo é se o problema que este padrão resolve é o problema que estava travando as coisas. Suspeito que não. O reempacotamento por ferramenta era irritante, custava tempo e produzia divergência silenciosa — mas não era o que impedia time de rodar agente a sério em produção. O que impede continua sendo não saber o que a skill de terceiro faz, não ter como limitar o que ela alcança e não ter sinal que avise antes do usuário avisar. Nada disso está na 1.0.0, e nada disso é culpa dela. É só que a parte fácil de padronizar foi padronizada primeiro, como quase sempre acontece, e agora fica mais visível o tamanho da parte que sobrou.

Fontes:

• Agent Plugins Specification — GitHub
• Agent Plugins — Site oficial
• Vercel — Introducing Agent Plugins
• Google Developers Blog — Agent Plugins package your skills, tools, and more
• The Next Web — OpenAI and four rivals just agreed on one standard for AI agents