Avaliação de agentes: o que medir além da resposta final

Um manual de avaliação diria para conferir a nota da prova, e todo agente tiraria dez. A pergunta que nenhum avaliador de resposta final faz é como o agente chegou lá: se conferiu o pedido antes de reembolsar, se chamou a ferramenta que tinha o direito de chamar. O desfecho certo disfarça o caminho errado, e o comprador sênior de agentes B2B, o CTO ou o head de produto que coloca o sistema em produção, precisa de uma régua que meça o que aconteceu no meio do caminho, não apenas o que chegou ao fim.

Um agente pode acertar a resposta e errar o caminho

Um agente acerta a resposta final e segue a operação por um caminho que nenhum evaluador de desfecho enxerga: chamar a ferramenta errada, omitir a chamada que validaria o passo, insistir num erro que nunca iria corrigir. A indústria já acena para onde a avaliação está indo. Em agosto de 2026, uma das principais camadas de agregação de modelos publicou uma metodologia que manda avaliar o agente pelos prompts que recebe, pelas ferramentas que chama e pela resposta que entrega em cada etapa, tornando o eval uma verificação de percurso, não um boletim de desfecho. Nota dez não é agente seguro.

Quem sente o custo da régua cega não é o time que escreve o prompt. É o dono do processo que descobre, numa segunda-feira de pico, que o agente de suporte vinha autorizando o que nunca devia autorizar, sem que a nota de resposta final baixasse uma milésima por causa disso. Para o CTO e o head de produto que jogam o agente contra a operação real, o que está em jogo não é a média de acerto. É o incidente que um eval só de resposta não evita porque nem chega a olhar para ele.

O que se arrisca ao dar a nota só na resposta

Dar a nota só na resposta final arrisca o tipo de falha que não aparece como resposta errada: violação de permissão, chamada indevida de ferramenta com acesso sensível, execução custosa que ninguém autorizou. Um eval de resposta final captura o desfecho errado e é estruturalmente cego à falha que é roubada ou perigosa. Quando um agente emitia reembolsos sem conferir se aquele pedido tinha direito a eles, o desfecho, o e-mail de confirmação de estorno, saía correto e legítimo; foi a classe de falha, o processo de autorização de um agente de suporte emitindo reembolso sem checar o pedido, que nenhuma nota de resposta podia ver. Num ambiente B2B, o mesmo padrão se repete com acesso a dado de cliente, com uma ordem de compra, com um pagamento. O número cego custa caro.

O que a régua cega não vê é cara por uma razão contábil simples. O custo de revisar o caminho antes da produção é uma linha pequena e mensurável em horas de quem arquiteta o eval. O custo do caminho não inspecionado é um incidente de produção, uma violação de guardrail, um retrabalho em cima de uma execução que ninguém autorizou, e ele aparece no momento em que o agente já roda em escala, com o fluxo dependendo dele. É por meio desse custo diferido que a decisão de escalar ou abortar um piloto, a que a leitura de ROI antes de escalar o piloto resolve pela régua financeira, encontra o processo antes de tocar a planilha. Adiar a medição do caminho não apaga o custo. Transfere-o para o trimestre em que ele dói mais, quando a saída é desligar o agente ou pagar a conta do incidente.

Claim 1: o tool-path é onde a resposta certa esconde a falha

O tool-path, a sequência de chamadas de ferramenta que o agente fez e, com a mesma importância, as que evitou ao não fazer, é o primeiro lugar onde a resposta final mente. Uma avaliação honesta de um agente precisa registrar a chamada feita e a chamada que deveria ter sido feita, porque a falha de processo geralmente não está no que o agente executou mal, e sim na chamada que ele omitiu por inteiro.

Um eval que só pontua a resposta final passa por cima do exemplo real mais barato: o agente de suporte que emite reembolso sem conferir o pedido. A resposta final, o estorno confirmado, está correta, e o evaluador de resposta dá nota dez. Só uma assertion que exige a chamada lookup_order antes da chamada de reembolso prova a falha, porque é a ausência da chamada lookup_order no tool-path, não a presença de uma resposta errada, que revela que o agente autorizou o que não devia.

A chamada evitada tem peso próprio e costuma ser a mais difícil de avaliar, porque exige especificar o que o agente não deveria fazer. Não basta saber que ele chamou a ferramenta certa. O comprador precisa declarar quais ferramentas estão fora de alcance daquele agente e verificar, execução a execução, que ele não as tocou. O vocabulário do perímetro é hoje padronizado por protocolos de conexão; o protocolo MCP e o Gateway de Agentes descrevem o que conecta o agente às ferramentas externas e o que ele tem o direito de chamar, que é a fronteira onde a chamada evitada se torna observável e auditável. É sobre esse direito, e não sobre o preço de um token, que o tool-path precisa falar. A chamada omitida é a falha.

Claim 2: a mudança de score precisa ser atribuível, ou o KPI mente

Sem fixar o teste, uma mudança de score não diz o que mudou. Se o agente melhorou de 10% numa execução para 11% na seguinte, o responsável precisa poder dizer a que se atribui a diferença, se ao modelo que subiu, ao prompt de turno pré-resposta, ao harness que passou a tolerar um formato novo ou à ordem da chamada de ferramenta. Um KPI sem atribuição é um número que todos elogiam e ninguém consegue reproduzir nem explicar no dia seguinte. Reproduzir é a prova do número.

O harness é o aparelho de teste que segura o agente enquanto ele roda, e a estabilidade dele é pré-condição de qualquer leitura. Quando o harness muda junto com a execução, o avaliador não sabe se o mérito é do agente ou do gabarito. A frase que separa um eval de engenharia de um dashboard decorativo é curta: pin do harness antes de pinar o agente. Primeiro se congela o ambiente, a versão do harness, o conjunto de casos, o ponto de corte, e só então a variação de score passa a ser atribuível ao que foi alterado de propósito.

As duas ambições do eval, o que ele confere hoje e o que ele passaria a conferir, ficam claras num contraste direto de escopo:

Enquanto o eval de resposta entrega um veredito sobre o desfecho, o eval de percurso entrega uma atribuição. É a diferença entre saber que a nota subiu e saber por que a nota subiu, e é só a segunda que permite a um time decidir com confiança o que sobe para produção.

Claim 3: falha, autocorreção e recuperação são sinal

O comportamento de falha de um agente diz mais sobre ele do que a taxa de acerto. Um agente que chama a ferramenta errada, percebe o erro, corrige o passo e segue a execução é um agente de uma natureza. Um agente que erra a chamada e repete o mesmo caminho até gerar um retrabalho ou bater num limite é outro, e os dois podem entregar a mesma resposta final no fim. Avaliar só o acerto apaga exatamente a diferença entre eles, que é a diferença entre um sistema que se recupera e um que exige socorro constante.

Dois agentes de processamento de pedido erram a chamada que atualizaria o status de um item no mesmo dia. Um detecta o desvio, reverte o passo, chama a ferramenta certa e encerra a tarefa com o registro correto. O outro insiste, repete a chamada errada três vezes, estoura um limite de tentativas e deixa a tarefa pela metade. O eval de resposta final vê os dois como sucesso, porque ambos terminaram com a mensagem de conclusão. O eval que mede falha, autocorreção e recuperação separa os dois com precisão: a assinatura de cada execução está nos turnos intermediários, não na última linha.

O custo dessa separação aparece na operação real, não no teste. O agente que se corrige sozinho consome horas de retrabalho quase nulas e sobrevive a exceções não documentadas. O que insiste no erro vira um gerador silencioso de trabalho humano de conserto, exatamente o retrabalho que a régua de autonomia e decisão de agentes na empresa precisa considerar quando define o limite em que a autonomia exige supervisão verificável. Um agente que só acerta quando supervisionado não é autônomo, é um prompt com aprovação humana grudada, e o comportamento de falha é o que revela em qual dos dois a empresa apostou. Supervisão não é autonomia.

Claim 4: o eval é um teste de regressão em CI, não um benchmark descartável

A régua de resposta final tem o DNA de um benchmark de pesquisador: roda-se uma vez, registra-se um número, arquiva-se. O eval que funciona em produção tem o DNA de um teste de regressão: cada bug vira uma assertion coberta, entra na suíte, e passa a rodar a cada nova versão do agente, bloqueando a regressão antes que ela chegue à operação. É a diferença entre medir e vigiar, e é a segunda que protege uma carga de produção ao longo do tempo. Medir uma vez não vigia nada.

Um bug documentado vira um teste percentual da mesma forma que um bug de código comum vira um teste unitário. Depois do agente de suporte emitir reembolso sem conferir, a correção verdadeira não é só mudar o prompt e torcer. É escrever a assertion que exige a chamada lookup_order no tool-path e deixá-la na suíte para sempre. A partir dali, qualquer release que reintroduza o caminho sem conferência falha na porta, antes de encostar no cliente, e o mesmo teste re-roda automaticamente quando um modelo novo sobe na base do agente, porque um modelo melhor pode trazer um caminho pior.

Contra a intuição de que avaliar assim é caro demais para o dia a dia: rodar a suíte de regressão leva minutos, roda sem humano no fluxo e converge para o custo de um conjunto de testes tradicional depois de poucas semanas de bugs virarem cobertura. O custo real do benchmark descartável não está no momento em que ele roda, e sim no buraco que deixa no meio, cada release entre o rodar-e-arquivar esconde quantas regressões atravessaram o agente sem teste que as pegasse. Para o time que coloca o agente em produção, o eval como teste de regressão deixa de ser uma campanha e vira parte do custo normal de manter software, e é também onde se conecta a um runtime agêntico que os devs já usam em CI, com o Nexforce Code dando a contrapartida de execução headless para rodar a suíte em cada release.

O contra-argumento mais forte contra avaliar o caminho

O contraponto mais forte é que benchmarks e scores de resposta bastam, porque avaliar o caminho é caro demais e é detalhe de engenharia que não muda a decisão do negócio. É um argumento sério, defendido por gente experiente, e tem apelo real quando o trimestre aperta. Ele cai numa premissa que a própria proposta esconde: a de que não avaliar o caminho custa zero.

O raciocínio por trás é de escala e de simplicidade. Benchmark é barato e corre em horas, e o score de resposta responde em linha o que o líder quer ouvir. Avaliar tool-path, permissão, recuperação e regressão parece um projeto que atrasa o piloto. A falha está em confundir o que é caro de implementar com o que é caro de ignorar. Confundir os dois custa produção. O custo do caminho não inspecionado não aparece na linha do orçamento de eval; aparece como incidente em produção, como violação de permissão, como execução que ninguém autorizou saindo do workspace do agente, exatamente o pior momento para descobrir, quando a operação já depende do sistema.

O que o argumento do "detalhe de engenharia" esquece é que a fronteira de permissão não é uma sutileza técnica, é a definição operacional da confiança. Definir quais ferramentas um agente pode chamar, quem aprova cada execução e como ele se recupera de erro é decidir quanto da operação ele toca sem humano. É sobre esse limite, e sobre como uma guarda verificável impede o agente de cruzar o perímetro de que dispõe, que trata a discussão de contenção de agentes em runtime. Chamar isso de detalhe é dizer que a cadeia de autorização da empresa é detalhe, e nenhum CTO repetiria isso em voz alta sobre um pagamento.

O que muda e onde o caminho se torna observável

O que muda quando o eval olha o caminho é que a conformidade deixa de ser uma esperança e vira uma propriedade verificada da execução. O teste de resposta pergunta se a resposta está certa. O eval de percurso pergunta se o agente tinha o direito de percorrer aquele caminho, se tocou só as ferramentas permitidas, se recuperou dos erros e se a mudança de comportamento entre versões foi intencional. A tabela abaixo separa o que cada régua cobre antes da produção, porque essa fronteira é o que decide o risco que a empresa assume:

A leitura honesta da tabela é que o eval de resposta não é inútil, ele é incompleto na dimensão exata em que a operação corre perigo. Completar essa dimensão é uma responsabilidade do comprador antes da produção, não uma cortesia do fornecedor do agente, e três passos a tornam executável. Só o caminho fornece essa prova.

1. Declarar a permissão de cada agente por escrito, dizendo quais ferramentas ele pode chamar e quem aprova o quê.
2. Transformar cada falha documentada em uma assertion coberta que permaneça na suíte de regressão.
3. Rodar essa suíte a cada release e sempre que um modelo novo subir na base, tratando o caminho violado como bloqueio e não como alerta.

É nesse desenho, e não em nenhum número de leaderboard, que a tarefa de avaliar o caminho pousa no Nexforce Agents. A camada de execução do agente no workspace, onde aprovações e permissões são camadas delimitadas, é o lugar em que a frase "toda chamada de ferramenta é observável e aprovável" deixa de ser retórica e vira conformidade de permissão antes de agir, com execução sandboxed contida, como traz o Nexforce Work. O custo por sucesso de um agente e a leitura de qual caminho custa mais caro dependem de rastrear o consumo do agente na camada de modelo em que ele roda, a camada Router da Nexforce como infraestrutura, embora o sujeito destas linhas permaneça o agente e a execução, não a tabela de preço por token. O comprador que arquiteta o eval como teste de regressão compra, no fim, um sistema cujo custo e cuja conformidade podem ser nomeados antes da produção, e só assim são decidíveis.

Perguntas frequentes

Por que um eval de resposta final não basta para um agente em produção? Porque ele só confere o desfecho e é cego ao processo. Um agente pode acertar a resposta final e ter percorrido um caminho errado, chamando ferramentas que não devia ou omitindo a chamada que validaria o passo. A nota fica perfeita no exato momento em que a operação deveria ter sido interditada. Certo na letra, perigoso no percurso.

O que é tool-path e por que importa avaliá-lo? O tool-path é a sequência de chamadas de ferramenta que o agente fez e as que evitou. Importa porque a falha de processo costuma estar na chamada omitida, não na resposta errada. Um agente de suporte que emite reembolso sem conferir o pedido recebe nota dez no desfecho e só é pego por uma assertion que exige a chamada lookup_order.

Como transformar um bug de agente em teste de regressão? Guardando a falha documentada como uma assertion coberta na suíte. O bug vira teste, entra na suíte e passa a rodar a cada release do agente e sempre que um modelo novo subir. Qualquer release que reintroduza o caminho violado falha na porta, antes de encostar na operação.

O que significa fixar o harness na avaliação de agentes? Significa congelar o ambiente de teste, a versão do harness, o conjunto de casos e o ponto de corte antes de medir o agente. Só com o harness fixado uma mudança de score se torna atribuível ao que foi alterado de propósito, o modelo, o prompt ou a chamada, e o KPI deixa de ser um número sem dono.

Onde a conformidade de permissão de um agente se torna observável? Na camada de execução do agente no workspace, onde aprovações e permissões são camadas delimitadas e cada chamada de ferramenta é aprovável antes de agir, com execução contida de forma sandboxed. É onde o caminho que um eval de resposta não enxerga vira dado verificável antes da produção. Só aí a permissão tem prova.

Referências e Leitura Complementar

• Leitura acompanhante Nexforce sobre a régua de escala: o ROI antes de escalar o piloto e, na fronteira do cluster, os critérios técnicos de avaliação de agentes B2B antes do piloto.

CLOSING

O comprador de agentes B2B que tira a nota só da resposta final está medindo a exibição que o agente escolheu mostrar, não a operação que ele percorreu. A régua de percurso, com o tool-path chamado e evitado, o harness fixado, a recuperação de erro e a regressão em CI, é o que transforma a conformidade de permissão em propriedade verificada e o bug em teste que nunca mais deixa de rodar. Antes de colocar o próximo agente em produção, o CTO deveria responder a uma pergunta que nenhum score de resposta resolve: se a operação só descobrisse o caminho que esse agente percorreu depois do primeiro incidente, em qual versão dele a empresa estaria apostando hoje. Nomear o caminho antes, no tool-path declarado e na suíte de regressão, é a diferença entre descobrir a falha como teste e descobri-la como incidente.