SKILL.md no Copilot Studio: vale entender antes de migrar?

Vale entender o SKILL.md, mas isso não é razão para migrar sua operação de Copilot Studio amanhã. O formato é relevante porque padroniza como um agente descreve “como fazer” uma tarefa, de um jeito que pode ser reaproveitado entre agentes e, em tese, entre plataformas diferentes. Para quem tem topics em produção numa cooperativa de crédito, esse é um conceito que vale dominar antes de qualquer projeto novo de agente, mas aplicar sem critério é o erro mais comum que estamos vendo.

A tese deste texto é direta: SKILL.md compensa quando há lógica repetida entre múltiplos agentes e uma equipe capaz de versionar esse comportamento como código. Não compensa, e pode até piorar a operação, quando a lógica que você quer extrair é, na verdade, um fluxo determinístico com etapas obrigatórias, como acontece em concessão de crédito com alçada ou em checagem de PLD. Skill não substitui topic. Skill é outra coisa, e confundir os dois é a armadilha que este post existe para expor.

O que muda de fato no Copilot Studio

A nova experiência do Copilot Studio troca o modelo centrado em topics, gatilhos e ramificação de conversa por um modelo centrado em capacidades do agente. Em vez de desenhar cada caminho possível da conversa, você descreve o que o agente sabe, o que ele pode fazer e com quem ele pode colaborar, e um orquestrador de agentes decide em tempo de execução como combinar essas peças para responder ao pedido do usuário.

Essas peças têm nomes específicos: Tools para ações externas (abrir chamado, consultar um sistema de crédito, atualizar CRM), Knowledge para fundamentação em dados confiáveis (política de crédito vigente, manual de PLD, base de produtos), Connected Agents para delegar trabalho a agentes especializados, Memory para continuidade por usuário, e Skills para comportamento reutilizável escrito em Markdown. É esse último bloco que interessa aqui.

Um ponto que costuma passar despercebido: a nova experiência roda em paralelo à clássica, não em cima dela. Um agente construído com topics não vira automaticamente um agente com skills, e o caminho inverso também não existe. São duas plataformas convivendo, não uma migração incremental. Isso muda o cálculo de quando vale investir tempo entendendo o formato novo.

O que é o SKILL.md dentro do Copilot Studio

Um SKILL.md tem uma estrutura simples: um cabeçalho em YAML com nome e descrição, seguido de um corpo em Markdown com o procedimento em si. A descrição não é comentário para humano lerem, é metadado de roteamento. O orquestrador examina apenas nome e descrição de cada skill disponível, e só carrega o corpo completo quando a descrição bate com o pedido do usuário. Isso evita que um agente com dez skills carregue dez conjuntos completos de instruções em todo turno, apenas dez descrições curtas.

O que torna isso mais interessante do que uma feature isolada é a origem do formato. O Copilot Studio não inventou o SKILL.md, ele adotou um formato aberto que já existe no GitHub Copilot e nos agentes da Anthropic. Na prática, uma skill escrita para um procedimento interno, como resumir uma reclamação de associado de forma padronizada, pode em tese ser reutilizada em outro runtime de agente compatível. É esse ponto que justifica chamar skills em markdown de padrão portátil, e não apenas de recurso de produto.

Vale uma reserva de cautela aqui: portável não é sinônimo de gratuito. Cada skill carregada consome espaço no contexto e tem custo de processamento. Times que já testaram esse modelo no ecossistema mais amplo de Microsoft AI relatam que nem toda skill disponível compensa ficar ativa por padrão, o ganho de reuso precisa ser medido, não presumido.

O critério: quando vale extrair uma lógica para SKILL.md

Este é o núcleo da decisão. Três condições precisam ser verdadeiras ao mesmo tempo para que valha a pena investir em skills reutilizáveis hoje.

• Existe lógica repetida entre agentes. Se sua cooperativa opera um agente de atendimento ao associado, um agente de suporte interno de TI e um agente de apoio ao comitê de crédito, e os três precisam classificar risco ou resumir um caso de forma parecida, essa é uma lógica candidata a virar skill. Se você tem um único agente, o ganho de reuso é zero.
• Há uma equipe capaz de governar isso como código. Skills em Markdown vivem bem em repositório versionado, revisadas por pull request, com dono definido. Sem esse hábito, um conjunto de arquivos SKILL.md soltos vira tão difícil de manter quanto instruções gigantes dentro de um único agente, só que espalhadas.
• A lógica é procedimento, não controle de fluxo. “Como resumir um incidente” é procedimento. “Em que ordem validar a alçada de aprovação de crédito” é controle de fluxo. Só o primeiro tipo se beneficia do formato de skill.

Quando as três condições se confirmam, o próximo passo natural é mapear qual arquitetura de agentes faz sentido: um agente orquestrador com Connected Agents especializados compartilhando as mesmas skills de expertise, por exemplo uma skill de classificação de risco usada tanto pelo agente de atendimento quanto pelo agente de comitê de crédito.

A armadilha: achar que skill substitui topic sem redesenho

O erro mais comum que vemos agora é pegar a lógica de um topic inteiro, incluindo validações obrigatórias e chamadas de sistema, e colar dentro de um arquivo SKILL.md esperando que o comportamento se mantenha idêntico. Não se mantém, porque skill e topic resolvem perguntas diferentes.

Uma skill responde “como fazer” uma tarefa. Ela não garante “quando” essa tarefa deve ocorrer, nem “se” uma etapa obrigatória foi de fato executada antes de prosseguir. Esse controle de sequência e obrigatoriedade continua sendo trabalho de um fluxo determinístico, seja um topic clássico, seja um flow chamado como Tool. O orquestrador agente é bom em decidir qual skill usar diante de um pedido ambíguo, mas ele não substitui uma trilha de auditoria com registro de cada etapa executada, algo que qualquer área de compliance de cooperativa vai exigir.

Um exemplo concreto do setor: na abertura de conta, a checagem contra listas de sanções e a validação de PLD não podem ser “sugeridas” por instrução textual dentro de uma skill. Precisam ser chamadas obrigatórias, com registro de execução, ainda que o agente use uma skill para redigir a comunicação final ao associado. Misturar as duas coisas no mesmo arquivo de instruções é o jeito mais rápido de perder rastreabilidade justamente onde ela é mais cobrada.

A tabela abaixo ajuda a separar o que vai para cada componente, e é o exercício mais útil antes de escrever a primeira linha de um SKILL.md.

Quando não vale a pena, ainda

Existe um cenário onde entender SKILL.md é útil como cultura técnica, mas aplicar agora seria prematuro. Vale reconhecer esses casos antes de abrir um projeto.

• Agente único, escopo estreito. Uma cooperativa com um só agente de FAQ para associados não tem lógica repetida para reaproveitar. O overhead de manter um repositório de skills não se paga.
• Processo sob fiscalização direta com exigência de trilha determinística. Fluxos regulatórios, como PLD ou concessão de crédito com alçada formal, precisam de log de execução passo a passo. Skill não fornece isso da mesma forma que um flow com registro de cada etapa. Redesenhar esse tipo de processo em torno de uma skill é trocar controle por flexibilidade no lugar errado.
• Time sem prática de versionamento. Se ninguém na equipe revisa mudanças em Git nem tem processo de aprovação de conteúdo, skills soltas viram cópias divergentes do mesmo conhecimento, exatamente o problema que o formato promete resolver.
• Migração de topics em produção só por moda. Se seus topics atuais funcionam e não há reuso real a ganhar, redesenhar tudo em torno de SKILL.md antes de medir o benefício é custo sem retorno. Migração de topics deveria ser motivada por lógica duplicada observada, não por acompanhar lançamento de plataforma.

Vale registrar também que essa lógica não é exclusiva do setor financeiro. Uma indústria com agentes de manutenção preventiva e de controle de qualidade enfrenta a mesma pergunta: a lógica de diagnóstico se repete entre esses agentes, ou cada um tem contexto suficientemente distinto para justificar instrução própria? A resposta muda o investimento.

O que fazer com os topics que já estão em produção

Não force conversão. O primeiro passo é auditoria, não reescrita. Liste quais topics, em quais agentes, carregam um procedimento que se repete em mais de um lugar. Separe, dentro de cada topic, o que é “como fazer” do que é “quando e sob quais condições fazer”. Só a primeira parte é candidata a virar skill.

Comece pequeno e mensurável: extraia um ou dois procedimentos claramente reutilizáveis, como a lógica de classificação de risco de uma reclamação ou o padrão de resumo executivo de um caso de ouvidoria, escreva o SKILL.md com nome e descrição precisos (lembre que a descrição é metadado de roteamento, uma descrição vaga produz ativação imprevisível), e teste isso em um agente piloto na nova experiência, mantendo o restante do fluxo determinístico exatamente como está hoje. Meça se o agente piloto realmente ficou mais fácil de manter antes de expandir para outros agentes de produção.

Trate isso como decisão de arquitetura de agentes, com dono definido e revisão de mudança, não como configuração de feature. Skills não fazem parte do maker que testa rápido e publica, fazem parte de quem vai manter aquele comportamento nos próximos dois anos, em múltiplos agentes.

A decisão em uma frase

Entenda o SKILL.md agora, porque ele tende a virar o vocabulário comum de reuso de comportamento entre agentes, dentro e fora do Copilot Studio. Aplique quando houver lógica repetida entre agentes, uma equipe disposta a versionar esse comportamento como código, e clareza de que aquilo é procedimento, não controle de fluxo regulatório. Fora dessas três condições, continue com topics e espere a maturidade da sua operação, não a data de lançamento da plataforma, indicar o próximo passo.

É esse tipo de decisão de arquitetura, entre manter o modelo clássico, adotar o novo e redesenhar lógica de negócio em torno de skills, que costuma render mais conversa do que qualquer tutorial de configuração. A Trinapse acompanha cooperativas de crédito e indústrias nessa avaliação, desde o mapeamento do que já está em produção até a decisão de o que vale migrar primeiro.