Skills no Copilot Studio: pare de criar um agente por tarefa

O agente que cresce até parar de funcionar

Um LLM lida bem com o caso genérico. O problema começa quando a tarefa depende de algo que só existe dentro da sua organização: o processo de aprovação de reembolso, a regra fiscal daquela região específica, o passo a passo que o time de suporte segue para triar um incidente. Isso o modelo não infere sozinho. Alguém precisa escrever.

A resposta mais comum até pouco tempo era empilhar tudo nas instruções do agente. Funciona no começo. Depois de algumas dezenas de regras, exceções e casos especiais, as instruções viram um bloco único, difícil de revisar, difícil de versionar, e presente em todo turno de conversa, mesmo quando 90% daquele conteúdo não tem nada a ver com a pergunta feita. O agente fica mais lento, mais caro e, em vários casos, menos preciso.

O Copilot Studio introduziu um jeito diferente de organizar esse conhecimento situacional: Skills. A ideia não nasceu ali. Vem do formato aberto Agent Skills, criado pela Anthropic e já adotado por agentes de codificação. O Copilot Studio trouxe o mesmo conceito para dentro da experiência moderna de orquestração.

O que é uma Skill, na prática

Uma Skill é um conjunto de instruções, com um nome e uma descrição, que o agente carrega sob demanda, apenas quando a conversa cai naquele cenário específico. Nada mais. Pode vir acompanhada de recursos, como exemplos, modelos de documento ou scripts, mas o núcleo é sempre instrução textual.

A diferença para uma instrução fixa está no momento em que o conteúdo entra em contexto. As instruções gerais do agente ficam sempre carregadas, em todo turno. Uma Skill não. Por padrão, o orquestrador mantém em vista apenas o nome e a descrição de cada Skill registrada, como uma espécie de índice. Quando a pergunta do usuário corresponde a uma delas, aí sim ele traz o conteúdo completo daquela Skill para o contexto da conversa.

Isso vale também para conhecimento e ferramentas: o Copilot Studio já registra fontes de conhecimento e ações do mesmo jeito, só a metadata fica sempre visível, o conteúdo completo entra quando é chamado. Skills seguem essa mesma lógica de carregamento tardio, aplicada a instruções procedimentais.

Como o orquestrador decide o que carregar

O fluxo, resumido, é este: o usuário faz uma pergunta, o orquestrador avalia as descrições disponíveis (conhecimento, ferramentas, Skills), identifica qual delas corresponde ao pedido, e só então carrega o conteúdo integral daquele item específico para formar a resposta. As instruções gerais do agente são a exceção, elas entram sempre, por inteiro, em todo turno.

Dez Skills registradas custam dez descrições curtas em contexto, não dez blocos completos de instrução. Isso é o que mantém a janela de contexto enxuta mesmo quando o agente cobre muitos cenários diferentes.

Por que isso importa para quem constrói agentes

Quatro ganhos aparecem quando você quebra instruções em Skills, e vale separar o que é estrutural do que depende do seu caso de uso.

• Manutenção. Em vez de um bloco de instrução que só cresce, cada Skill é uma unidade autocontida. Você revisa, versiona e corrige uma de cada vez, sem reler o resto. Isso é estrutural, vale para praticamente qualquer agente.
• Gestão de contexto. O conteúdo completo só entra quando é relevante. Também estrutural, e é o motivo pelo qual agentes com muitas Skills não ficam necessariamente mais lentos ou mais caros por isso.
• Precisão. Uma Skill pode carregar orientação detalhada de uso de ferramenta: qual ação chamar, quais parâmetros preencher, como validar o retorno, o que fazer quando a consulta vem vazia. Com um conjunto grande ou sobreposto de ferramentas, trazer essa orientação só quando é necessária tende a reduzir erro de chamada. Isso depende do seu caso, então avalie, não presuma.
• Velocidade e custo. Uma Skill empurra o agente para o caminho certo em vez de deixá-lo reconstruir o raciocínio do zero. Menos buscas de conhecimento, menos chamadas de ferramenta, menos voltas de raciocínio, significa menos idas e vindas antes da resposta final, o que reduz latência e o consumo de créditos por conversa. Também depende do caso, avalie antes de assumir o ganho como garantido.

Manutenção e gestão de contexto valem quase sempre. Precisão e velocidade são reais, mas específicas do seu agente. Meça, não assuma.

Como criar e adicionar uma Skill no Copilot Studio

Skills ficam na aba Skills do agente. Hoje há duas formas de adicionar uma: criar do zero, ou fazer upload de uma Skill já existente.

Criar do zero pede três campos, e são os três que importam: nome, descrição e instruções. Simples assim.

O upload aceita um arquivo SKILL.md isolado, ou um .zip que empacota o SKILL.md junto com recursos adicionais, como scripts que a Skill referencia durante a execução.

Uma vez adicionada, a Skill passa a fazer parte do agente. Ela é escopada àquele agente específico e viaja com ele: se o agente entra em uma solução do Power Platform, a Skill vai junto no ciclo de ALM, sem configuração extra.

O formato SKILL.md e o padrão aberto

Como o Copilot Studio segue o formato aberto Agent Skills, uma pasta de Skill pode carregar mais do que instrução de texto:

minha-skill/
├── SKILL.md       # metadados + instruções
├── scripts/       # código executável, opcional
├── references/     # documentação de apoio, opcional
└── assets/         # modelos e templates, opcional

O SKILL.md traz nome, descrição e o corpo de instrução no front matter e no texto. Um exemplo mínimo, ilustrativo:

---
name: Triagem de Elegibilidade de Licença
description: >
  Use para dúvidas de elegibilidade de licença médica ou maternidade
  e documentação exigida. Não use para folha de pagamento
  ou adesão a benefícios.
---

Ao receber um pedido de triagem de licença:
1. Identifique o tipo de licença solicitado.
2. Verifique os documentos mínimos exigidos para esse tipo.
3. Consulte a ação `verificar_elegibilidade` com o ID do colaborador.
4. Se faltar documento, liste exatamente o que falta antes de prosseguir.

Note o cuidado em escapar caracteres especiais como &, < e > se você for colar exemplos assim direto em um editor que renderiza HTML, o WordPress inclusive. Um < solto quebra a formatação do bloco.

O Copilot Studio já suporta essa forma completa: instruções, referências, templates e scripts, tudo carregado sob demanda quando a Skill é selecionada. Vale registrar dois pontos sobre como isso funciona hoje, porque muda a forma como você planeja reuso:

• Distribuição ainda é por agente. Ecossistemas de agentes de codificação já permitem distribuir Skills como plugins entre produtos e ambientes. No Copilot Studio, por enquanto, a Skill é escopada ao agente e viaja com ele pela solução, não existe ainda um catálogo compartilhado entre agentes ou tenants. É o estado atual do recurso, não o desenho final, um modelo mais próximo de catálogo está em desenvolvimento.
• Uma Skill pode apontar para as ferramentas do agente, sem se vincular a elas. Além de rodar scripts empacotados, uma Skill pode referenciar ações, flows, conectores e servidores MCP que já existem no agente. É um apontamento fraco, não uma vinculação: a Skill diz “use a ação de consulta de pedido aqui”, mas se o agente não tiver essa ferramenta, a instrução simplesmente não se cumpre, e mesmo quando a ferramenta existe, o orquestrador ainda decide se segue o apontamento ou não.

A parte que a maioria erra: escrever a descrição como sinal de roteamento

Você não chama uma Skill diretamente. O orquestrador escolhe, com base no nome e na descrição, quando a conversa corresponde àquele cenário. Essa escolha acontece antes de qualquer instrução ser lida, e é por isso que a qualidade da descrição decide se a Skill vai funcionar ou não.

O erro mais comum é tratar nome e descrição como documentação para humanos. Não são. São o sinal que o mecanismo de roteamento usa para decidir. Trate como tal:

• Nomeie de forma específica. “Triagem de Elegibilidade de Licença” roteia melhor que “Ajuda de RH”. O segundo é vago demais para servir de critério de decisão.
• Diga quando usar e quando não usar. “Use para elegibilidade de licença e documentação exigida. Não use para folha de pagamento nem adesão a benefícios.” A negativa importa tanto quanto a afirmação, porque evita que a Skill errada dispare em cima de um assunto vizinho.

Uma descrição precisa dá ao orquestrador um alvo de roteamento claro. Uma descrição vaga, do tipo “ajuda com questões de RH”, convida a Skill errada a disparar, ou nenhuma a disparar. Um teste prático: se dois construtores razoáveis discordariam sobre quando aquela Skill se aplica, a descrição ainda não está específica o suficiente.

A vista de raciocínio do agente, dentro do próprio Copilot Studio, é a principal superfície de depuração aqui. Se uma Skill dispara com frequência demais, a descrição provavelmente está ampla demais. Se ela nunca dispara, a descrição está estreita demais ou não usa as palavras que os usuários realmente digitam nas perguntas.

Instrução fixa, Skill ou agente separado: o critério

Antes de decidir entre instrução e Skill, uma coisa já ficou resolvida: existe ali algo que o agente não consegue inferir sozinho. Se uma ferramenta ou fonte de conhecimento está bem descrita, o agente costuma deduzir como usá-la só pela descrição, e isso nem precisa virar texto. O que sobra, contexto organizacional, convenção interna, dado proprietário, regra de negócio, é a parte que realmente precisa ser escrita. A única pergunta que falta responder é onde colocar esse texto.

Quando manter na instrução geral

Se a orientação vale em toda conversa, em todo cenário, ela pertence às instruções do agente. Tom de voz, papel do agente, restrições de segurança sempre ativas, tudo isso é válido 100% do tempo, então deve estar sempre em contexto. Não faz sentido transformar isso em Skill, porque uma Skill existe justamente para carregar algo só quando é preciso, e isso aqui é preciso sempre.

Quando transformar em Skill

Se a orientação só se aplica a um cenário específico, mantê-la fora do contexto padrão e carregá-la apenas quando o cenário aparece é exatamente o papel de uma Skill. Pense nela como qualquer uma destas formas, dependendo do trabalho que o agente precisa fazer:

• Manual de referência, quando o agente precisa entender um modelo de dados proprietário que o LLM não conhece de outra forma.
• Especialista sob demanda, para uma área de conhecimento estreita que só aparece ocasionalmente, como regra fiscal de uma região específica.
• Playbook, quando existe um conjunto conhecido de jogadas para uma situação recorrente, como classificar e rotear um chamado de suporte.
• Procedimento operacional padrão, quando uma tarefa precisa ser feita sempre da mesma forma, dentro de política, como um reembolso com limite de aprovação.
• Checklist, quando certas etapas não podem ser puladas, como validações antes de criar um registro.
• Protocolo, para regras firmes em um caso sensível, como o que fazer diante de um incidente de segurança suspeito.
• Runbook, para uma tarefa operacional com passos definidos e tratamento de falha conhecido.
• Template, quando a saída precisa seguir uma estrutura fixa, como um relatório em formato padronizado.

O fio comum entre todas essas formas: é orientação específica de contexto, que o LLM não deduz sozinho, escrita uma vez e trazida à tona só quando o cenário aparece. Conhecimento dá fato ao agente, ferramenta dá alcance, Skill dá o saber-fazer situacional para usar os dois bem. E é importante lembrar que uma Skill orienta, não amarra: o modelo continua lendo a situação e decidindo se segue a Skill à risca ou adapta. Esse julgamento é o motivo de usar um LLM em primeiro lugar, a Skill só garante que a expertise certa esteja disponível na hora certa.

Quando vale um agente separado

Antes de existir Skill no Copilot Studio, o instinto padrão para cada tarefa distinta era criar mais um agente especializado: um para redefinição de senha, outro para aprovação de solicitação de software, outro para triagem de incidente. Na maioria das vezes isso não são três agentes, é um agente de suporte de TI com três Skills. Se o mesmo agente atende o mesmo público e compartilha o mesmo limite de conhecimento, a Skill é a unidade de modularidade certa: você não está construindo mais um agente para manter, está ensinando ao que já existe mais uma forma de trabalhar.

Dois sinais ainda apontam para um agente separado, e não para mais uma Skill:

• A capacidade se sustenta sozinha. Um assistente de RH e um agente de suporte de TI não são um agente com duas Skills. Eles atendem públicos diferentes, ficam atrás de limites de segurança diferentes, e cada um faz sentido como agente independente que alguém usaria sozinho. Quando a capacidade é assim, autônoma, o caminho é construir o agente. Autônomo não é o mesmo que reutilizável: compartilhar uma Skill entre agentes é outra discussão, e é justamente o tipo de coisa que um catálogo de Skills, quando existir de forma mais madura no produto, deve endereçar.
• Um agente já assumiu ferramentas demais. Há indício de que a precisão pode cair conforme mais coisa é carregada no contexto de um agente, e um conjunto de ferramentas crescente faz parte dessa carga. A partir de certo ponto, empilhar mais Skills não resolve, só adia o problema. Quando você bate nesse teto, dividir o trabalho em um agente separado e delegar a ele tende a funcionar melhor do que continuar empilhando tudo em um só. Como sempre, valide isso no seu próprio agente em vez de assumir.

Skill como superfície de confiança

Porque uma Skill molda o comportamento do agente e pode empacotar script executável, ela é uma superfície de confiança, não apenas um pedaço de texto. Qualquer Skill que você não escreveu, seja de origem comunitária, gerada por IA ou reaproveitada de outro ambiente, merece o mesmo tratamento que código de terceiro: revise antes de adicionar. Procure por instrução de injeção de prompt, orientação para uso indevido de ferramenta, e qualquer coisa que não corresponda ao que a descrição da Skill promete fazer.

Em ambientes com governança de agentes já estabelecida, esse é o ponto natural para trazer a revisão de Skill para dentro do mesmo processo de aprovação que já existe para conectores e fluxos do Power Automate. Não trate como exceção.

O que levar disso

Skills ainda são um recurso recente no Copilot Studio, e deliberadamente enxuto no que entrega hoje. Mas a lógica por trás já vale internalizar: mantenha nas instruções o que é verdadeiro em toda conversa, e mova para Skills tudo que é situacional, seja um manual de referência, um checklist, um runbook ou um playbook, para que o agente traga isso à tona só quando o cenário exigir.

Na prática, a decisão entre instrução, Skill e agente novo é onde a maioria dos projetos de automação com IA desperdiça esforço, construindo agentes demais ou instruções monolíticas de menos manutenção. Se sua operação já tem vários agentes que na verdade atendem o mesmo público com o mesmo limite de conhecimento, vale mapear isso antes de criar o próximo. É um dos pontos que costumamos revisar com clientes que estão estruturando governança de agentes no Copilot Studio.