Escolher métricas para avaliar agentes B2B antes do piloto

Uma empresa anuncia que vai pilotar agentes de IA e, na mesma semana, quatro pessoas abrem a discussão sobre qual modelo usar, qual framework de orquestração, qual runtime. Ninguém pergunta a mesma pergunta uma vez sequer: o que significa, para esta operação, um agente "funcionando"? É essa pergunta que decide o piloto. E é a que quase nunca é feita.

A primeira decisão do piloto não é técnica

A primeira decisão de um piloto de agentes B2B é escolher o que medir, não qual framework ou qual modelo. Quem pula direto para a escolha de tecnologia está respondendo uma pergunta que ainda não foi formulada, e descobre isso no fim do trimestre, quando tem um agente rodando e nenhuma régua para dizer se valeu. O custo do piloto não é o token. É o teste que termina sem um número do qual discordar ou concordar.

Quem sente esse custo primeiro são três pessoas: o líder de operações, que precisa justificar a cabeça adicionada ou a cabeça que não foi adicionada; o responsável por RevOps, que herda o agente sem saber contra qual meta ele roda; e o líder de tecnologia, que vira o dono de um sistema cujo "sucesso" ninguém definiu. As três juntas são a razão de metade dos pilotos morrer em silêncio. Não porque o agente falhou. Porque não existia acordo prévio sobre o que contaria como sucesso.

Existe um número que ilustra a assimetria: benchmarks públicos de agentes são abundantes, mas o relatório que importa para o CFO, o que conecta o agente ao resultado do negócio, é uma régua que a própria operação precisa produzir. Ela não vem pronta de fornecedor nenhum. Essa lacuna é o assunto inteiro deste post, e o leitor que a ignora pilota às cegas.

A armadilha mais elegante é a seguinte. O time técnico escolhe métricas que sabe medir bem: latência, custo por token, taxa de tarefa completada. O time de negócio escolhe métricas que soam bem em reunião: "mais eficiência", "menos retrabalho". Os dois conjuntos não se falam, e o piloto termina com uma lista de números que todos reconhecem como verdadeiros e nenhum reconhece como decisivos. É o ponto onde o projeto começa a apodrecer sem dar erro nenhum.

O que um benchmark de domínio realmente prova

Um benchmark de domínio prova que um agente consegue transformar uma tarefa real e privada em um deliverable correto dentro de um ambiente controlado, corrigido critério a critério por um juiz de LLM. Essa é uma prova importante, e é tudo o que ela é. Ela não diz nada sobre o que acontece quando aquele agente encosta na operação de verdade, com dado sujo, exceção não documentada e prazo real.

A classe de avaliação tem uma forma específica. O agente lê documentos de caso em um ambiente sandboxado, executa uma tarefa de múltiplas etapas e produz um deliverable de verdade: um memorando, um disclosure schedule, um resumo de depoimento. Não é resposta de trivia, não é turno único de chat. É trabalho composto, avaliado de ponta a ponta.

Cite o exemplo concreto. O Harvey LAB-AA, a implementação da Artificial Analysis do Legal Agent Benchmark da Harvey, roda agentes contra 120 tarefas privadas de prática jurídica distribuídas por 24 áreas. Cada tarefa é corrigida criterion a criterion por um único juiz de LLM, uma rubrica que pontua cada critério em separado em vez de dar uma nota única compassiva. O que se mede ali é capacidade: a distância entre o deliverable produzido e o padrão esperado para aquele critério específico.

O que a lista de avaliações da Artificial Analysis reúne é exatamente essa família: LAB-AA, AA-Briefcase, AA-Analyst, GDPval-AA v2, Terminal-Bench. Benchmarks de domínio que provam que agentes produzem deliverables reais, multi-etapa, em sandbox. E param ali, na borda da sandbox.

Aqui está a confusão que custa caro. Uma organização lê "o agente venceu em um benchmark de domínio" e traduz como "o agente vai entregar valor no meu fluxo". A tradução é incorreta. O benchmark mede se a tarefa foi concluída dentro de um critério acordado. Ele deliberadamente não mede se concluir aquela tarefa daquele jeito vale dinheiro para alguém. Duas coisas diferentes, e a segunda é a que paga o projeto.

Por que tarefa concluída não é valor entregue

Tarefa concluída e valor entregue não são a mesma coisa, e a distância entre elas tem um nome: o benchmark-to-production gap. Um benchmark mantém o dado limpo, o ambiente controlado e o critério de correção fixado por um juiz. A produção joga dado sujo, sistema parcialmente integrado e um critério de sucesso que muda conforme a semana. A lacuna não é um detalhe de implementação. É o buraco onde os pilotos caem.

O benchmark assume três condições que a operação real quebra uma a uma. Primeira, input limpo: o documento que o agente lê no benchmark está completo e bem rotulado. Na produção, o mesmo documento chega pela metade, em vinte formatos, com um anexo que ninguém pediu. Segunda, escopo conhecido: cada tarefa do benchmark tem começo e fim definidos. Na produção, o trabalho chega em bola, com dependências que ninguém listou. Terceira, critério estável: o juiz LLM usa a mesma rubrica em todas as tarefas. Na produção, o que é "bom" muda quando a meta do trimestre muda.

O exemplo torna isso concreto. Um agente jurídico avaliado e validado para redigir memorandos pode pontuar alto no LAB-AA porque o benchmark entrega a ele um conjunto de documentos limpo e um pedido bem delimitado. No ambiente de um escritório real, o mesmo agente recebe um e-mail com dez anexos, um cliente que mudou de ideia no meio do caminho e um sócio que quer a resposta "com mais contexto". A capacidade está lá, provada pelo benchmark. O valor, não. Ele depende de fatores que o benchmark nunca prometeu cobrir.

Há um segundo custo escondido nessa confusão, e ele é de natureza contábil. Quando a régua do piloto herda a régua do benchmark, mede-se a média de acerto da tarefa e chama-se isso de retorno. O que fica de fora é a parte da operação que o agente não tocou, a que precisou de conserto humano, a que gerou retrabalho silencioso. Exatamente a parte que decide se o agente economiza cabeça ou apenas a desloca de lugar.

Por isso a primeira régua sozinha, a de capacidade, produz um número que todos elogiam e ninguém usa para decidir nada. Ela responde "o agente sabe fazer?". A pergunta que o CFO faz é outra: "quanto a empresa ganha por semana com o agente fazendo?". As duas exigem instrumentos diferentes, arquitetados em momentos diferentes, e quase ninguém separa os dois.

Como montar a régua antes do piloto

Montar a régua antes do piloto significa empilhar duas camadas diferentes de medição e, em seguida, medir a distância entre elas. A primeira camada é a capacidade do domínio, aferida por um benchmark do tipo que a Artificial Analysis documenta. A segunda é o valor de negócio da própria operação, definido pela métrica que importa para aquela rotina específica. O piloto só começa quando as duas existem e a lacuna entre elas é conhecida.

A ordem importa mais do que o conteúdo de cada camada. Quem monta a régua de valor depois de rodar o agente está medindo o que já aconteceu, sem ter estabelecido antes contra o que. É como escolher a meta de vendas no fim do mês: toda conclusão será retrospectiva e nenhuma decisão terá ficado mais fácil. A régua precisa existir antes, e ser escrita em algum lugar que o time possa disputar.

A tabela abaixo desenha a separação entre os dois tipos de métrica, porque é a fronteira que decide quase tudo:

A sequência de montagem tem quatro passos, e nenhum deles é opcional. Primeiro, estabeleça a baseline de capacidade usando um benchmark de domínio relevante para a área. Segundo, escreva a régua de valor de negócio da própria operação: o tempo de ciclo, o retrabalho, o custo por entrega, o tempo até resposta. Terceiro, meça a lacuna entre as duas camadas: onde o agente é capaz mas o fluxo real o derruba, é ali que mora o projeto de integração. Quarto, fixe os critérios de aceite do piloto em cima dessa lacuna, com número, dono e data.

O terceiro passo é o que separa um piloto maduro de um teste de curiosidade. A capacidade alta e o valor baixo, no mesmo agente, indicam que o problema está na integração e não na tecnologia: o agente sabe, só não chega ao lugar onde sabe. A capacidade baixa e o valor alto indicam que o problema está no agente, e nenhum ajuste de processo vai salvar. Sem medir as duas camadas, o time confunde os dois diagnósticos e conserta o lado errado.

É nesse desenho, e não em nenhum número de leaderboard, que entra o Nexforce Agents. A régua do piloto é definida antes de qualquer execução, e a execução acontece de forma sandboxed e rastreável, via Nexforce Work e Nexforce Code. O que o benchmark documenta como capacidade, o Nexforce Agents deixa rodar dentro da operação com um registro do que aconteceu em cada etapa, para que a lacuna entre as duas camadas apareça como dado e não como suspeita.

O contra-argumento mais forte

O contraponto mais forte é simples: bastam os benchmarks, porque valor de negócio é complicado demais para medir com rigor, então o melhor uso do tempo é rodar o agente e ver o que acontece. É um argumento honesto, defendido por gente séria, e tem um apelo real quando o trimestre está apertado e ninguém quer parar o projeto para desenhar régua. Ele cai numa conta que a própria proposta esconde.

O raciocínio por trás é: medir capacidade é barato, medir valor é caro, logo medir só capacidade é o caminho racional. A falha está na premissa de que não medir valor custa zero. Não medir valor adia o custo para o fim do piloto, quando a decisão de escalar, manter ou matar o agente precisa ser tomada com base em um número que não existe. O custo não desapareceu. Foi empurrado para o ponto onde dói mais.

Existe uma segunda camada no contra-argumento, e é a mais sedutora. "Grandes empresas decidiram na base do benchmark e funcionou." Isso confunde correlação com queima de capital. Uma organização com orçamento folgado pode pilotar às cegas e sobreviver, porque o erro é amortecido pelo resto da operação. A empresa média que roda agentes B2B não tem esse colchão, e é para ela que a régua importa. Para quem tem dinheiro de sobra, qualquer metodologia de avaliação parece burocracia; para quem não tem, é o que impede o teste de virar prejuízo.

A resposta definitiva ao contra-argumento é empírica, e já foi dita aqui: a lacuna entre capacidade e valor não descreve uma dificuldade de medição, descreve o próprio trabalho de integrar o agente à operação. Quem se recusa a medir a lacuna não está economizando o esforço de avaliar. Está escolhendo não saber onde o agente vai falhar, e descobrir da pior forma, com o sistema em produção e o resultado no resultado do trimestre.

O que muda para quem adota agentes hoje

A crença que precisa mudar é uma só: parar de pilotar às cegas. Quem adota agentes hoje, ou planeja adotar, deve parar de começar a conversa pela tecnologia e começar pela régua. O framework e o modelo vêm depois, e a escolha deles fica obviamente mais fácil quando existe um critério de sucesso já escrito que os dois precisam satisfazer. Um agente só é uma decisão de produto quando existe uma métrica de valor ao lado dele; sem ela, é experimento.

A mudança tem uma consequência organizacional concreta e desconfortável. Alguém do lado do negócio precisa sentar com o lado técnico antes do primeiro token do piloto. Não depois. E precisa sair dessa reunião com a régua de valor escrita, com dono e prazo. A maioria dos pilotos pula essa reunião porque ela é a parte chata, a que exige dizer, em números, o que "funcionou" significa. É justamente a parte que o benchmark não pode fazer por ninguém.

Olhando para o que já está publicado por aqui, a fronteira fica mais nítida. O gateway de modelos em escala e o custo operacional de um gateway de IA em produção tratam da infraestrutura sobre a qual agentes rodam; a economia por roteamento de modelos trata de custo por token. Nenhum deles é a régua de qualidade e valor de um agente de trabalho. Essa régua é outra camada, e é o território que este post ocupa.

O ponto de aterrissagem é honesto. O benchmark de domínio responde se o agente sabe fazer; a régua de negócio responde se aquilo vale dinheiro na sua operação. As duas precisam existir antes do piloto, e a distância entre elas é o mapa do trabalho de integração. Um time que monta as duas camadas e mede o gap está pilotando com os olhos abertos. O resto está apostando, e chamando a aposta de estratégia.

FAQ

Qual é a diferença entre benchmark de domínio e métrica de valor de negócio?

O benchmark de domínio mede se o agente concluiu uma tarefa real contra um critério acordado, em ambiente sandbox e com dado limpo. A métrica de valor de negócio mede se ter aquele trabalho feito gerou resultado mensurável na operação real, como menos tempo de ciclo ou menos retrabalho.

Preciso medir o benchmark-to-production gap no meu piloto?

Sim. A lacuna entre a capacidade provada pelo benchmark e o valor medido na operação é o próprio mapa do trabalho de integração. Sem ela, o time não distingue um problema de integração de um problema de agente.

Benchmarks de agente como o LAB-AA servem para escolher meu agente?

Servem para calibrar a capacidade técnica antes de o agente tocar a operação. O que eles não fazem é dizer quanto valor aquele agente entrega no seu fluxo específico, que é a pergunta que decide o piloto.

Quando devo definir a régua, antes ou depois de rodar o agente?

Antes. Definir a régua de valor depois de rodar o agente transforma toda conclusão em retrospecto, sem um critério prévio contra o qual decidir. A régua escrita com dono e prazo precisa existir antes do primeiro token do piloto.

O Nexforce Agents ajuda a medir valor ou só a executar?

O Nexforce Agents é onde a régua definida antes do piloto é executada de forma sandboxed e rastreável, via Nexforce Work e Nexforce Code. A medição de valor continua sendo uma régua que a própria operação precisa produzir.

Referências e Leitura Complementar

• Artificial Analysis: avaliações de agentes: reúne benchmarks de domínio multi-etapa, incluindo o Harvey LAB-AA (Legal Agent Benchmark), com tarefas privadas corrigidas criterion a criterion por juiz LLM.
• Nexforce Agents: a unidade de agentes de IA para operações B2B, com Nexforce Work e Nexforce Code.
• Model Router em escala: a infraestrutura de modelos sobre a qual os agentes rodam.
• Custo operacional de um gateway de IA em produção: o custo e a latência da camada de gateway em produção.
• Modelo mais barato não é modelo mais barato: a economia por roteamento de modelos.

A régua é o piloto

A pergunta que abre este post, "o que significa um agente funcionando?", não tem resposta técnica. Tem resposta de negócio, e ela precisa ser escrita antes de qualquer framework. A decisão de medir capacidade e valor em duas camadas, e de olhar a distância entre elas, é a primeira decisão de qualquer piloto sério. Quem a toma cedo ganha um piloto que termina com um número do qual discordar ou concordar. Quem não a toma termina com um agente rodando e uma pergunta sem resposta, e aí o projeto morre devagar, sem nunca dar erro.