Agent Plugins 1.0: um formato de pacote para todo agente de IA

O que é o Agent Plugins? O Agent Plugins 1.0 é um padrão de empacotamento aberto e neutro em relação a fornecedores — publicado em 6 de agosto de 2026 — que reúne Agent Skills e configurações de servidores MCP em um diretório portátil que qualquer cliente de agente compatível consegue carregar. Um plugin é uma pasta com um manifesto plugin.json obrigatório, uma pasta skills/ opcional com Agent Skills e um mcp.json opcional que declara servidores MCP. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro e VS Code oferecem suporte desde o lançamento.¹²

Seis empresas que competem entre si todos os dias entregaram uma resposta comum para um problema que todo usuário de agentes já sentiu: a extensão que você construiu para um cliente de agente não funciona no seguinte. A Vercel iniciou a proposta e desenvolveu a especificação com Amazon, Anysphere (criadora do Cursor), GitHub, Microsoft e OpenAI;² no mesmo dia, o Google anunciou que está entrando para o grupo de mantenedores principais e construindo suporte nos próprios produtos.⁶ O resumo de uma linha do site oficial: “um formato de pacote portátil para componentes reutilizáveis que estendem agentes de IA”.¹

O nome da empresa que criou as duas camadas empacotadas aqui não está na lista de mantenedores. Essa ausência é metade da história — e a segunda metade deste artigo.

TL;DR: o Agent Plugins 1.0 padroniza a camada de empacotamento em torno de duas especificações que já existiam — Agent Skills e o Model Context Protocol — e não substitui nenhuma delas: apenas fixa onde cada uma mora dentro de um diretório compartilhável.¹ Um plugin é uma pasta: plugin.json para a identidade, skills/ para as skills, mcp.json para os servidores, além de pastas de namespace em domínio invertido para os extras de cada cliente. A versão 1 é deliberadamente um piso de interoperabilidade: a especificação não define semântica portátil para instalação, registros, permissões, procedência, segredos ou OAuth; tudo isso continua sob responsabilidade de cada cliente.¹² O Codex entregou o suporte entre as versões v0.146.0 e v0.147.0.⁴ A Anthropic, que criou o Agent Skills e o MCP, não está entre os mantenedores — o Claude Code mantém o próprio formato de plugins.³⁷⁸

Principais conclusões

• Desenvolvedores solo: escreva suas skills como Agent Skills padrão (uma pasta com um SKILL.md) e elas já serão o substrato portátil; embrulhá-las em um plugin é questão de um manifesto. Pare de manter uma cópia por cliente.
• Líderes de equipe: o padrão cobre empacotamento, não distribuição nem política. Seu registro, seu mecanismo de atualização e sua estratégia de lista de permissões continuam sendo decisões de cada cliente — inclua isso no orçamento antes de prometer internamente um “escreva uma vez, rode em qualquer lugar”.
• Engenheiros de segurança: a versão 1 não define camada de procedência nem de permissões, e também não define camada de assinatura — a decisão de confiança passa inteiramente para a sua revisão no momento da instalação. A portabilidade amplia o raio de alcance dos ataques por skill envenenada.

O que foi lançado

Em 6 de agosto de 2026, a Vercel publicou o Agent Plugins 1.0.0, uma especificação aberta que ela iniciou e desenvolveu com Amazon, Anysphere, GitHub, Microsoft e OpenAI.² A especificação normativa vive em um repositório público cuja lista de mantenedores abrange Amazon, Cursor, Microsoft, OpenAI e Vercel,³ e o Google anunciou no dia do lançamento que está entrando nesse grupo como mantenedor principal, com o suporte já chegando às suas próprias ferramentas de agentes.⁶

A lista de clientes disponíveis no dia do lançamento abrange as maiores superfícies do ecossistema: VS Code, Cursor, GitHub Copilot, ChatGPT e Codex, além do Kiro.¹² O suporte na CLI do Codex na verdade veio antes do anúncio público: a v0.146.0 (29 de julho) adicionou os manifestos do Agent Plugins e a publicação de plugins no espaço de trabalho, e a v0.147.0 (7 de agosto) fechou o ciclo com a instalação portátil de plugins e a busca em catálogos locais, pessoais, de espaço de trabalho e remotos.⁴

O escopo está dito na própria linha de abertura da especificação: ela “define a Especificação canônica do Agent Plugins v1.0.0 para empacotar componentes reutilizáveis que estendem agentes de IA em plugins distribuíveis”.¹ Empacotamento — não uma nova linguagem de skills, não um substituto para o MCP. Os dois formatos subjacentes mantêm as próprias especificações; este padrão apenas fixa onde eles moram dentro de um diretório que o cliente consegue descobrir.

A anatomia de um plugin

Um plugin é um diretório com um arquivo obrigatório e três superfícies opcionais:¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

O plugin.json é um manifesto de esquema fechado. Os campos de primeiro nível permitidos são exatamente dez: $schema, name, version, description, author, homepage, repository, license, keywords e extensions — e a especificação é rigorosa com todo o resto: “Os clientes DEVEM reportar e ignorar cada campo desconhecido e DEVEM continuar carregando o plugin se o manifesto atender no restante a esta seção”.¹ O campo name aceita caracteres alfanuméricos minúsculos, hifens e pontos, com o primeiro e o último caractere alfanuméricos e sem hifens ou pontos consecutivos.¹

A pasta skills/ guarda Agent Skills exatamente como elas já existem: “Cada diretório filho imediato que contenha um caminho chamado exatamente SKILL.md e que resolva para um arquivo comum é tratado como uma skill”.¹ O mcp.json declara servidores MCP; um cliente que ofereça suporte a servidores MCP de plugins “DEVE oferecer suporte a pelo menos um entre stdio e streamable-http” e DEVERIA oferecer suporte aos dois, com sse opcional — e a especificação permite explicitamente que um cliente que só lide com skills seja conforme sem oferecer suporte a nenhum servidor MCP.¹

Diretórios em domínio invertido como com.example.client/ guardam comportamentos específicos de cada cliente, com a regra de portabilidade escrita em linguagem normativa: “Um cliente DEVE ignorar entradas de manifesto de namespaces que ele não implementa, sem validar o conteúdo dos valores delas”.¹

Esse último mecanismo pesa mais do que parece. Os componentes que mais variam entre clientes ficam cercados fora do núcleo portátil: comandos, hooks, agentes, regras e servidores LSP são os exemplos que a própria especificação dá de tipos de componentes que “continuam específicos demais de cada cliente para um contrato portátil estável” e ficam fora do formato v1 até que seus formatos convirjam.¹ O núcleo portátil são as skills mais as configurações de MCP, ponto final.

O que a versão 1 deixa de fora de propósito

A especificação padroniza a menor coisa que poderia funcionar. Ela não define semântica portátil para instalação, registros, permissões, procedência, segredos ou OAuth — cada um desses pontos continua sob responsabilidade do cliente¹² — e também não define camada de assinatura. O caminho de expansão dos mantenedores é conservador por escolha: um tipo de componente só entra no núcleo portátil quando as implementações convergem o bastante para defini-lo com precisão.¹

Leia isso como física de coalizão, não como timidez. Seis empresas — cinco delas entregando clientes de agentes com formatos de plugins incompatíveis — conseguiram concordar sobre onde os arquivos moram; não conseguiram concordar, ainda, sobre como os hooks disparam, como os comandos se registram ou de quem é o modelo de permissões que vence. Então o padrão congelou a camada em que o comportamento já havia convergido (skills são pastas de markdown, MCP é um protocolo de comunicação) e cercou dentro de namespaces tudo o que segue em disputa. É um piso de interoperabilidade, e pisos são úteis justamente porque todo mundo consegue ficar em pé sobre eles.

O custo desse piso: o “construa uma vez, rode em qualquer lugar” vale para o pacote, não para a experiência. Um plugin se instala em qualquer lugar; o que ele consegue fazer ainda varia por cliente, e como ele é instalado, atualizado e considerado confiável depende inteiramente de cada cliente.

O buraco em forma de Anthropic

Aqui está a parte estranha. O Agent Skills — o formato de pastas de instruções que o padrão empacota — é uma criação da Anthropic, anunciada em outubro de 2025.⁸ O Model Context Protocol também, aberto pela Anthropic em novembro de 2024.⁷ As duas camadas sob este padrão de empacotamento vieram do único grande fornecedor de ferramentas de agentes cujo nome não aparece em lugar nenhum da lista de mantenedores.³

O Claude Code mantém o próprio formato de plugins — o próprio manifesto, as próprias fontes de marketplace, o próprio empacotamento de hooks e comandos — e nada do que foi anunciado em 6 de agosto muda isso. A ponte, por enquanto, corre em uma direção só: o Codex traz uma fonte de marketplace do Claude Code (v0.146.0), e seu comando /import migra para o Codex as configurações do Claude Code, os servidores MCP, os plugins, as sessões, os comandos e as memórias com escopo de projeto.⁴

Na prática, a costura é mais estreita do que o organograma sugere, e o motivo é o substrato: uma skill é uma pasta com um SKILL.md, em todo ecossistema. As skills que você escreve para o Claude Code são o mesmo artefato que um Agent Plugin carrega. O que não viaja é o invólucro — o manifesto de plugins do Claude Code de um lado, o plugin.json do outro — e os componentes específicos de cada cliente (os hooks acima de tudo) que cada ecossistema mantém nativos. Se você mantém skills hoje, já está escrevendo a camada portátil; a divergência está no empacotamento, não no conteúdo.

Se a Anthropic vai acabar adotando o formato, publicando um equivalente ou deixando a ponte em mão única é a pergunta em aberto que este lançamento propõe. A composição da coalizão — todos os grandes fornecedores de clientes de agentes, menos um — faz a trajetória do padrão de empacotamento depender menos dos seus méritos técnicos do que da decisão da autora ausente das suas duas camadas subjacentes sobre se vale a pena ficar em pé nesse piso.

A questão de cadeia de suprimentos que ninguém padronizou

Um formato de pacote portátil sem camada de procedência também é um formato de ataque portátil. A versão 1 deixa procedência e permissões sob responsabilidade de cada cliente e não define ferramentas de assinatura ou validação,¹ o que significa que a decisão de confiança mora inteiramente no momento da instalação, cliente a cliente, usuário a usuário.

Isso importa mais neste mês do que no anterior. Pesquisas recentes sobre ataques no nível da skill — o ElasticBack é o exemplo mais nítido — demonstram backdoors condicionais plantados em um único documento de skill e descrevem as skills de agentes como “uma cadeia de suprimentos emergente na qual uma única skill envenenada pode comprometer de forma persistente todo agente que a instalar”.⁵ A portabilidade multiplica isso: o mesmo plugin envenenado agora se instala em seis clientes em vez de um, e o escopo do padrão deixa a detecção para a revisão que cada cliente (ou cada usuário) fizer.

Fiz o argumento completo antes de este padrão existir em Skills de agentes precisam de gerenciadores de pacotes: o contexto de agente virou uma cadeia de suprimentos de software, e instalá-lo com segurança exige o maquinário que os ecossistemas de pacotes já aprenderam a construir — manifestos, arquivos de lock, instalações com escopo, portões de revisão e reversão. O Agent Plugins 1.0 entrega o manifesto e para por aí; o resto dessa lista é exatamente o que a v1 deixa para os clientes. Inspecione o que você instala; o formato não vai fazer isso por você. (Uma armadilha vizinha, vinda de As skills que meu agente não conseguia ver: os agentes carregam as descrições das skills sob um orçamento de contexto rígido, e as skills entregues por plugins entram nesse mesmo catálogo — a portabilidade acrescenta skills a uma fila que já trunca em silêncio.)

O que fazer hoje

Se você usa o Codex: o padrão já está aí. codex plugin expõe a instalação portátil do Agent Plugins, e a busca de plugins cobre catálogos locais, pessoais, de espaço de trabalho e remotos desde a v0.147.0.⁴ As equipes podem publicar plugins no próprio espaço de trabalho em vez de montar um marketplace público.

Se você usa o Claude Code: nada muda no seu formato de plugins. Continue escrevendo suas skills como pastas de skills padrão — essa é a camada portátil — e trate o invólucro como descartável. Se você também usa o Codex, a fonte de marketplace do Claude Code e o /import levam a sua configuração existente para lá.⁴

Se você usa VS Code, Cursor, Copilot, ChatGPT ou Kiro: você está na lista de clientes do lançamento; como os plugins se instalam é a experiência do seu cliente, porque o padrão deliberadamente não especifica isso.¹

Se você publica ferramentas para desenvolvedores: o manifesto é pequeno o bastante para ser adotado em uma tarde, e o repositório da especificação é público.³ A decisão interessante não é se você vai ler o plugin.json — é quais dos seus componentes você cerca dentro do seu namespace de domínio invertido, porque essa fronteira é a declaração de fato do que você considera portátil.

Perguntas frequentes

O Agent Plugins substitui o MCP ou o Agent Skills?

Não. O trabalho declarado da especificação é “empacotar componentes reutilizáveis que estendem agentes de IA em plugins distribuíveis”¹ — as skills mantêm o formato SKILL.md, os servidores MCP mantêm o protocolo deles, e o padrão apenas fixa onde os dois moram dentro de um diretório compartilhável.

Um plugin pode levar hooks, comandos slash ou agentes personalizados?

De forma portátil não, e não na v1. A especificação cita comandos, hooks, agentes, regras e servidores LSP como exemplos de tipos de componentes que “continuam específicos demais de cada cliente para um contrato portátil estável” — fora do formato portátil até que seus formatos convirjam. Um cliente pode carregá-los dentro do seu diretório de namespace em domínio invertido, e os clientes DEVEM ignorar namespaces que não implementam.¹ O núcleo portátil são as skills mais as configurações de MCP.

Por que a Anthropic não faz parte do padrão?

Nem a especificação nem a coalizão disseram. O que é público: a lista de mantenedores abrange Amazon, Cursor, Microsoft, OpenAI e Vercel, mais o Google entrando no lançamento,³⁶ enquanto a Anthropic — criadora tanto do Agent Skills quanto do MCP⁷⁸ — está ausente, e o Claude Code mantém o próprio formato de plugins. A ponte prática hoje está do lado do Codex: a fonte de marketplace do Claude Code e a migração via /import.⁴

É seguro instalar Agent Plugins de terceiros?

O formato não te ajuda a decidir: a versão 1 deixa permissões e procedência sob responsabilidade de cada cliente e não define ferramentas de assinatura ou validação.¹ Trate um plugin como qualquer código a que você concede os seus privilégios. A pesquisa sobre backdoors no nível da skill (ElasticBack) mostra que um único documento de skill envenenado pode comprometer condicionalmente todo agente que o instalar, e a portabilidade multiplica a base instalada.⁵

Referências