Agent Review Tool no Copilot Studio: vale usar agora?

A resposta curta é sim, com uma condição. O Agent Review Tool vale a pena a partir do momento em que um agente do Copilot Studio passa de um único skill isolado para uma configuração distribuída, com múltiplos skills, tools, fontes de conhecimento ou agentes conectados. Nesse ponto, o teste manual na aba Preview deixa de dar cobertura suficiente, porque cada conversa só exercita o caminho escolhido para aquela entrada específica. O Agent Review Tool inspeciona a configuração salva como um todo, não apenas o que foi conversado.

A condição é: a ferramenta está em preview. Isso significa evaluators, pesos de score e apresentação de resultados sujeitos a mudança sem aviso prévio equivalente ao de um recurso GA. Vale adotar agora para times que já sentem dor real de sobreposição de skills, referências ambíguas a tools ou falhas silenciosas que só aparecem em produção. Não vale tratar como processo formal de certificação nem como substituto de um plano de teste representativo. É complementar, e essa distinção sustenta o resto deste artigo.

O problema que aparece quando o agente cresce

Um agente com uma instrução e um skill é fácil de inspecionar a olho. Ninguém precisa de ferramenta para isso. O problema aparece quando o agente cresce, e ele quase sempre cresce. Um skill pode fazer sentido isoladamente e ainda assim sobrepor responsabilidade com outro skill. Um tool pode estar configurado corretamente e ser referenciado de forma ambígua no texto do skill. Uma fonte de conhecimento pode existir sem que nenhum skill dê ao agente instrução suficiente para usá-la.

Nada disso aparece necessariamente na aba Preview. Uma conversa de teste segue um caminho. Se a combinação de entradas que expõe o problema não foi testada, o problema fica invisível até acontecer em produção, geralmente na forma de uma resposta errada, uma escalada que não dispara ou uma referência a uma capacidade que o agente não tem configurada.

O Agent Review Tool, que faz parte do Copilot Agent Kit, existe para dar um método repetível de inspecionar esses riscos antes do release. Ele examina a configuração salva (instruções, skills, tools, fontes de conhecimento, arquitetura de agentes conectados) e produz achados organizados por severidade, que um maker investiga e corrige.

O que o Agent Review Tool realmente revisa

Uma revisão completa abre um workspace com três áreas principais. As duas primeiras são o foco deste artigo, porque concentram a decisão de release. A terceira, custo e eficiência, mistura sinais de atividade observada com faixas de planejamento e merece tratamento separado, porque tem limites de evidência diferentes da revisão de configuração.

• Review findings: achados agrupados por família de regra e severidade (erro, aviso, informativo). Cada achado abre evidência, racional, recomendação e passos possíveis de correção.
• Skill evaluator: qualidade de cada skill individualmente e achados de orquestração entre skills, incluindo sobreposição de responsabilidade.
• Agent map: visão gráfica e em lista de como os skills revisados se relacionam com tools, fontes de conhecimento e outros componentes configurados.

Para agentes movidos pelo harness do GitHub Copilot, o score usa pilares determinísticos, baseados em regra, para prontidão de avaliação e qualidade das instruções, com pilares adicionais quando o agente inclui skills, tools, fontes de conhecimento ou agentes conectados. Achados assistidos por IA aparecem como evidência de apoio, mas não alteram esses pilares determinísticos. Isso importa: um score alto não prova qualidade em runtime, e um score baixo não prova que o agente vai falhar. O score é um resumo. A decisão vem dos achados individuais.

No Skill evaluator, a qualidade de instrução de cada skill é avaliada em quatro dimensões:

Essas quatro dimensões são especialmente relevantes para agentes com skills no formato do harness do GitHub Copilot, porque a qualidade de um skill não depende só do conteúdo do próprio arquivo. Depende também de o agente conseguir distinguir aquele skill de toda alternativa disponível a ele no momento da decisão.

Critério de decisão: quando adotar agora, mesmo em preview

Não existe resposta genérica para “vale usar ferramenta de preview”. Existe um conjunto de condições que, juntas, tornam a resposta sim para o seu contexto específico.

• O agente tem mais de um skill, tool ou fonte de conhecimento em produção ou perto disso. Abaixo desse patamar, a inspeção manual ainda é viável e a ferramenta agrega pouco.
• Você já testa a aba Preview com casos representativos e ainda assim já teve, ou suspeita ter, comportamento inesperado em produção. Isso é sinal de que a cobertura de conversa não está encontrando os problemas de configuração.
• Existe mais de um maker mexendo no mesmo agente ao longo do tempo. Achados como referência ambígua a tool ou skill que menciona capacidade não configurada custam caro justamente quando quem editou não é quem vai depurar.
• O time consegue tratar o score como ponto de partida, não como veredito. Se a cultura interna vai transformar “63%” em critério de aprovação automática sem abrir os achados, a ferramenta perde o valor e vira teatro de governança.
• Você aceita reexecutar a revisão depois de qualquer mudança em skill, instrução ou arquitetura de agente conectado. Uma revisão única, feita uma vez, tem validade curta.

Se as cinco condições forem verdadeiras, vale rodar o Agent Review Tool antes de cada release relevante, mesmo sabendo que evaluators e apresentação podem mudar enquanto o recurso está em preview. O custo de adoção é baixo (é uma ferramenta de inspeção, não altera o agente-fonte) e o retorno aparece rápido em achados concretos, como skill referenciando capacidade inexistente.

Um exemplo ilustra o tipo de achado que a ferramenta encontra e que teste manual dificilmente encontraria sozinho. Em um agente fictício de merchandising visual, um skill de auditoria de exibição tinha dois de cinco passos citando um scorecard de conformidade e um agente de escalonamento regional, nenhum dos dois configurado de fato no agente. O Agent Review classificou isso como erro sob a regra de skill referenciando capacidade que o agente não possui, e o mesmo skill pontuou baixo em acionabilidade. Depois de reescrever o skill para usar apenas capacidades de fato configuradas, a segunda revisão eliminou os erros e a qualidade média de skill subiu de forma expressiva. A cobertura de avaliação, porém, continuou zerada, porque a ferramenta não gera casos de teste automaticamente. Ela aponta o problema; corrigir e testar continua sendo trabalho do maker.

A armadilha: tratar o Agent Review como substituto do teste manual

Esta é a armadilha mais provável para quem adota a ferramenta agora. O Agent Review Tool responde uma pergunta: a configuração salva contém risco de qualidade, clareza, cobertura ou manutenibilidade? A aba Preview e as avaliações de runtime respondem outra pergunta, diferente: o agente se comportou como esperado para estas conversas?

São perguntas complementares, não intercambiáveis. Um agente pode passar em todos os checks determinísticos de configuração e ainda assim responder mal em produção, porque a evidência de configuração não reconstrói o plano de execução em runtime nem prova que um tool, fonte de conhecimento, skill ou agente conectado foi de fato invocado. O Agent map descreve relações autoradas e capturadas na revisão, não execução observada.

O inverso também é verdadeiro e mais perigoso ainda: um achado sumir na segunda revisão não significa que o comportamento em runtime melhorou. Significa que a evidência de configuração que motivou aquele achado foi corrigida. Se você reescreve um skill, resolve o erro de configuração, mas não roda de novo as conversas e avaliações que exercitam aquele skill, você melhorou o resultado da revisão, não necessariamente o agente. Nenhuma correção deveria ser considerada concluída sem esse segundo passo: rodar as conversas mais prováveis de exercitar a mudança, confirmar que roteamento e saídas continuam corretos, e só então reabrir o Agent Review para comparar com a linha de base.

Nenhum dos dois métodos, sozinho, certifica que um agente está pronto para produção. Usados juntos, formam um quadro mais completo do que qualquer um isoladamente.

Quando não usar

Há cenários em que adotar o Agent Review Tool agora não compensa, e vale nomeá-los com a mesma franqueza usada acima.

• Agente simples, com um único skill e sem tools externas. Se toda a lógica cabe em uma instrução e um skill, a inspeção manual já cobre o risco real, e o overhead de rodar e interpretar uma revisão formal não se paga.
• Ambiente regulatório que exige evidência de certificação estável. Como o recurso está em preview, evaluators e critérios de score podem mudar. Se a sua organização precisa documentar um processo de aprovação com critérios fixos e auditáveis ao longo do tempo, um recurso em preview não é a base certa para esse processo ainda.
• Time sem capacidade de agir sobre os achados. Uma revisão que gera 20 achados e nenhuma ação corretiva não é governança, é ruído acumulado. Se não há tempo ou mandato para revisar e corrigir skills depois da análise, a ferramenta só vai gerar uma lista que ninguém lê.
• Expectativa de que o score substitui teste representativo. Se a intenção é usar o percentual do Agent Review como gate único de release, sem rodar avaliações de runtime, isso reintroduz exatamente o risco que a ferramenta foi feita para reduzir: confiar em um número sem evidência comportamental.
• Agente ainda em fase de exploração de escopo. Enquanto instruções e skills ainda estão mudando de forma estrutural, semana a semana, os achados ficam obsoletos rápido demais para justificar o ciclo de revisão. Vale esperar o desenho estabilizar antes de investir tempo na análise formal.

Fechamento: uma ferramenta de investigação, não de certificação

O Agent Review Tool orienta investigação. Ele não certifica um agente como pronto para produção, não modifica o agente de origem, não substitui casos de teste representativos ou revisão humana, e não prova que uma capacidade configurada foi de fato executada em runtime. Suas visões de custo e eficiência também não reportam gasto faturado real nem garantem economia. Entender esses limites é parte de decidir usar a ferramenta bem, não um motivo para evitá-la.

Um agente que se comporta como esperado na aba Preview está pronto para uma revisão mais profunda, não necessariamente para o release. Ferramenta e teste manual resolvem perguntas diferentes, e tratar uma como substituta da outra é a forma mais comum de essa adoção sair pela metade.

Times que constroem e mantêm agentes no Copilot Studio em escala corporativa costumam sentir essa lacuna entre “parece funcionar” e “está pronto para produção” bem antes de terem um processo formal para fechá-la. Se esse é o ponto em que sua operação está agora, essa é justamente a conversa que a Trinapse costuma ter com clientes que gerenciam ciclo de vida de agentes em ambiente corporativo.