O Agent Plugins 1.0 é um padrão aberto e neutro em relação a fornecedores que empacota as capacidades de um agente de IA (habilidades, servidores MCP, comandos e regras) em um único plugin instalável, para que você o construa uma vez e o execute em ferramentas diferentes, em vez de reconstruí-lo para cada uma. Em agosto de 2026, o GitHub anunciou suporte completo ao padrão no VS Code, no Copilot CLI, no app do Copilot e no seu SDK, em todos os planos do Copilot. O significado direto para o dono de um negócio: o tempo e o dinheiro que você investe para personalizar as ferramentas de IA da sua equipe deixam de ser reféns de uma única plataforma.

Que problema ele resolve de fato?

Nos últimos dois anos, as ferramentas de IA deixaram de ser uma caixa de chat e passaram a ser agentes que leem seus arquivos, chamam seus sistemas e executam etapas reais. Para personalizar esses agentes para a sua empresa, você precisa dar a eles três coisas: instruções escritas explicando como o seu negócio funciona, uma conexão com seus sistemas internos por meio de servidores MCP e regras que os impeçam de ultrapassar sua autoridade.

O problema era que cada ferramenta exigia tudo isso no seu próprio formato. Sua equipe escreve personalizações para uma ferramenta; um ano depois, a empresa decide migrar para algo mais rápido ou mais barato e descobre que todo esse trabalho não é portátil e precisa ser reescrito. Não é apenas um incômodo técnico; é um custo real que se repete a cada troca de fornecedor, e é o motivo pelo qual muitas empresas adiam uma personalização séria por medo de desperdício.

O que um plugin contém na prática?

Um pacote segundo o padrão tem formato simples e é claramente definido. Ele é composto por:

  • Um manifesto plugin.json com o nome do plugin e o número da versão, que é o que torna possível atualizá-lo e acompanhá-lo.
  • Uma pasta de habilidades com as instruções escritas que dizem ao agente como executar uma tarefa recorrente da sua empresa do jeito que você quer.
  • Um arquivo mcp.json que define os servidores MCP que conectam o agente aos seus sistemas reais: estoque, base de clientes, faturamento.
  • Extensões específicas de cada ferramenta colocadas em um namespace separado, para que as partes compartilhadas continuem portáteis mesmo quando um fornecedor adiciona um recurso próprio.

Separar a parte compartilhada da parte específica de cada fornecedor é o que há de mais inteligente no design: não impede nenhum fornecedor de se diferenciar com recursos próprios e não obriga você a perder tudo se mudar de ideia mais tarde.

Por que o dono de um negócio deveria se importar, e não só o desenvolvedor?

A governança é a verdadeira diferença. O padrão é desenvolvido publicamente sob uma licença aberta e supervisionado por um comitê técnico diretor com representantes da Amazon, Microsoft, OpenAI, Cursor e Vercel. Quando empresas concorrentes concordam com um único formato, é um sinal de que esse formato vai sobreviver a mais de um ciclo de produto e de que não se trata da tentativa de uma das partes de prender seus clientes.

Isso importa porque o maior risco ao adotar IA hoje não é técnico, mas contratual. O fornecedor que você escolhe hoje pode aumentar os preços, descontinuar um serviço do qual você depende ou mudar de qualidade. Um padrão aberto não elimina esses riscos, mas reduz o seu custo de saída, e um custo de saída baixo é a carta de negociação mais forte que você tem.

O que isso significa para as empresas na Arábia Saudita?

Com 2026 designado como o Ano da Inteligência Artificial no Reino, muitas empresas entraram em uma fase de experimentação séria depois de anos de demonstrações. O padrão recorrente que vemos é uma empresa que compra assinaturas para a equipe, depois não personaliza nada e acaba com um assistente genérico que sabe tudo sobre o mundo e nada sobre os seus sistemas. O valor real vem da personalização, não da assinatura.

Com um padrão portátil em vigor, a decisão de personalizar ficou muito menos arriscada. Uma empresa pode escrever um plugin interno que explique seu ciclo de aprovações, conectar o agente ao seu sistema de faturamento ou de gestão de pedidos e distribuí-lo para toda a equipe, com a confiança de que o investimento continua válido se ela mudar para outra ferramenta no ano que vem.

Mas observe um ponto essencial: o fato de um pacote ser portátil não significa que o acesso aos seus dados passe a ser permitido. Qualquer plugin que conecte um agente aos seus sistemas internos continua sujeito à Lei de Proteção de Dados Pessoais (PDPL), e você precisa definir com precisão o que o agente pode e não pode ler, e documentar isso.

Passos práticos para começar esta semana

  • Faça um inventário das suas personalizações atuais. Anote o que a sua equipe realmente construiu em instruções, conexões e regras, e identifique onde cada peça está hoje.
  • Comece com uma tarefa recorrente. Não converta tudo de uma vez; escolha um processo diário que consuma tempo de forma visível e empacote-o como um único plugin.
  • Defina as permissões antes de distribuir. Os planos Business e Enterprise incluem configurações centralizadas que controlam quais plugins são permitidos e de quais fontes aprovadas. Configure isso antes que o uso se espalhe, não depois.
  • Documente o que é portátil e o que não é. As partes compartilhadas se movem entre ferramentas; as extensões específicas de cada ferramenta talvez não. Conheça os limites da portabilidade antes de construir uma promessa em cima dela.

A conclusão é que o setor está passando de uma bagunça de formatos concorrentes para um formato compartilhado, e esta é a fase em que investir na personalização de IA se torna uma decisão calculada, e não uma aposta. Na Origami, construímos esses plugins e as conexões com os sistemas reais dos nossos clientes, projetando desde o início para que a propriedade e a flexibilidade fiquem com o cliente, e não com o fornecedor.

Fontes