Seu agente de IA disse “pronto”. Como saber se funcionou?

Leitura estimada: 10 minutos. Referências consultadas em 26 de outubro de 2026.

O agente respondeu “pronto”, mostrou um resumo organizado e até colocou um check verde. Excelente. Agora vem a pergunta que interessa a quem mantém um sistema funcionando: o que, exatamente, ficou pronto?

Se a tarefa era publicar um anúncio, precisamos encontrar o anúncio correto na conta correta. Se era atualizar um cadastro, precisamos verificar os campos alterados. Se era processar uma solicitação, precisamos conhecer o estado em que ela terminou, inclusive quando alguma etapa falhou.

Na minha experiência com integrações e com a Oombe, esse olhar para o resultado faz parte do trabalho. Ao acrescentar IA ao fluxo, continuo precisando dele. A eloquência da resposta não muda a regra de negócio.

É por isso que gosto de tratar evals, as avaliações de sistemas de IA, como uma forma de tornar a confiança discutível e mensurável. A equipe precisa conseguir explicar o que aprovou, com base em quais casos e dentro de quais limites.

Comece pelo que deveria existir ao final

A Anthropic distingue o relato da execução do resultado no ambiente: uma conversa pode anunciar sucesso enquanto o estado final mostra outra coisa. Essa distinção é especialmente útil quando agentes usam ferramentas e modificam sistemas.

Minha primeira pergunta seria: qual condição concreta precisa estar verdadeira quando a tarefa terminar?

Para uma atualização de estoque fictícia, eu escreveria algo como: a quantidade do produto autorizado corresponde ao pedido, a conta permanece correta e nenhuma outra quantidade foi alterada. Para uma extração de dados, exigiria campos verificáveis e indicação explícita do que não foi encontrado.

Também definiria o comportamento aceitável quando falta informação. Pedir um identificador ausente pode ser a conclusão correta. Inventar esse identificador para parecer produtivo deve reprovar.

A documentação do Claude sobre critérios de sucesso recomenda critérios específicos, mensuráveis e relevantes à aplicação. Minha aplicação desse princípio seria trocar “o agente deve ser bom” por condições que duas pessoas consigam avaliar de maneira semelhante.

O conjunto de casos precisa parecer com seu trabalho

Um benchmark público pode orientar uma investigação. Para decidir sobre um produto, eu montaria também um conjunto de situações do próprio domínio.

Imagine um agente demonstrativo que prepara atualizações de anúncios para um marketplace fictício. Este seria um ponto de partida, usando exclusivamente dados sintéticos:

Situação de teste	Evidência esperada
Pedido válido e completo	Alteração correta no item autorizado
Identificador ausente	Solicitação de informação ou encerramento identificado
Duas contas com produtos semelhantes	Preservação da conta indicada
Evento recebido novamente	Ausência de efeito duplicado
Resposta perdida após uma gravação	Consulta do estado antes de decidir repetir
Sucesso em parte de um lote	Registro separado dos itens concluídos e pendentes
Falha temporária do fornecedor	Tentativas limitadas e encerramento rastreável
Campo incompatível com a regra	Rejeição explicada sem alterar dados válidos

A tabela é uma proposta de desenho, sem resultados medidos. O critério de aprovação também precisa considerar o contrato específico da API. Nem todo fornecedor oferece a mesma consulta de estado ou o mesmo mecanismo de idempotência.

Eu incluiria variações de linguagem, campos vazios e combinações de condições. Uma tarefa não deveria passar apenas porque o texto do usuário coincidiu com o exemplo usado para criar o prompt.

Retry é uma decisão sobre efeitos

Quando uma chamada falha, a reação automática costuma ser tentar novamente. Só que “não recebi a resposta” e “a operação não aconteceu” são estados diferentes.

A AWS Builders' Library descreve o uso de identificadores de solicitação para reconhecer repetições e tornar efeitos de novas tentativas previsíveis. O comportamento depende do contrato da operação, incluindo o tratamento de parâmetros e do período de retenção.

No laboratório proposto, eu simularia uma gravação concluída cuja resposta se perde. Depois observaria se o agente consulta a situação disponível, preserva a identidade da operação ou simplesmente cria outra.

Também simularia um lote com resultados mistos. A avaliação verificaria quais itens ficaram pendentes e se uma retomada preserva os já concluídos. “Reprocessar tudo” pode ser uma decisão cara dependendo do efeito externo.

Há duas camadas para avaliar: o que o agente decidiu e o que a ferramenta garantiu. Uma ferramenta com validações sólidas pode impedir um erro proposto pelo agente. O relatório precisa registrar ambos, para a equipe saber de onde veio a proteção.

Dados sintéticos ajudam a começar com controle

Eu prepararia um pequeno catálogo fictício, contas inventadas, identificadores próprios do teste e respostas simuladas. Assim, seria possível provocar falhas sem envolver operações de clientes.

Cada caso teria entrada, estado inicial, resultado esperado, condições proibidas e uma explicação curta do motivo. Essa explicação facilita revisar um teste quando a regra de negócio muda.

Separaria os exemplos usados para melhorar o sistema de um conjunto reservado à avaliação final. Se ajustamos o prompt olhando sempre para as mesmas perguntas, podemos acabar ensinando a prova sem melhorar a capacidade que nos interessa.

A documentação do LangSmith distingue avaliações offline, em conjuntos preparados, e observação de execuções em produção. Eu usaria essas duas perspectivas em momentos diferentes: primeiro controlar o experimento, depois descobrir condições que o laboratório deixou de representar.

Dados sintéticos também têm limites. Eles refletem as situações que conseguimos imaginar. Um conjunto perfeitamente organizado pode deixar de fora a bagunça que torna uma integração difícil.

Uma execução feliz revela pouco sobre consistência

Se um agente resolve uma tarefa uma vez, sabemos que aquela execução funcionou. Para entender se ele repete o resultado, precisamos executar novamente e conservar os fracassos na conta.

O τ-bench, apresentado em 2024, avalia interações com ferramentas e regras de domínio, comparando estados finais. O trabalho também propõe uma métrica de sucesso consistente em múltiplas tentativas. Seus resultados pertencem aos modelos e cenários estudados naquela época.

No meu conjunto, distinguiria duas perguntas: “conseguiu acertar alguma vez?” e “com que frequência entrega corretamente?”. Para uma automação que afeta um cliente, a segunda costuma ser decisiva.

Eu registraria a versão do modelo, prompt, ferramentas, skill, configuração e limites de tentativas. Restauraria o estado inicial entre execuções independentes e manteria separadas as simulações de continuidade.

Poucas repetições podem revelar defeitos úteis, mas não autorizam uma afirmação estatística ambiciosa. Um relatório deve mostrar quantidade de casos, distribuição de falhas e incerteza, além da porcentagem principal.

Quem avalia também precisa ser avaliado

Sempre que o resultado puder ser conferido por uma regra objetiva, eu começaria por ela: quantidade de registros, campos, identificadores, estados e ações executadas.

Para aspectos como clareza de uma explicação, um modelo avaliador pode ajudar. O estudo sobre LLM-as-a-judge com MT-Bench e Chatbot Arena documenta limitações como vieses relacionados à posição e à extensão das respostas. Portanto, uma nota produzida por IA também merece exame.

Eu escreveria uma rubrica pequena, com exemplos claros de aprovação e reprovação. Depois compararia decisões do avaliador com decisões humanas em uma amostra e investigaria divergências. Respostas longas não deveriam receber pontos extras apenas pela aparência de cuidado.

Também evitaria uma média que esconda falhas críticas. Alterar a conta errada precisa aparecer como falha própria, mesmo quando a mensagem final está impecável. Já uma explicação pouco elegante pode receber uma classificação de impacto menor.

Quando dois revisores discordam frequentemente, o problema pode estar no critério. Vale melhorar a definição antes de transformar a divergência em mais uma casa decimal no painel.

Um laboratório Laravel sem depender de contas reais

Para quem trabalha com Laravel, eu organizaria um projeto demonstrativo com quatro componentes: catálogo sintético, adaptador de marketplace fictício, executor de tarefas e verificador do estado final. Esta é uma proposta de arquitetura de avaliação, não um tutorial de código já executado.

O cliente HTTP do Laravel oferece recursos para simular respostas e verificar requisições em testes. Eles permitem representar respostas bem-sucedidas, erros e sequências de retorno sem depender de um fornecedor real.

A documentação de filas também apresenta ferramentas para verificar o envio de jobs. Eu complementaria essa verificação com a execução controlada da lógica: colocar um job na fila, por si só, não demonstra que o efeito esperado foi concluído.

O verificador rodaria depois da tarefa e examinaria o estado final do ambiente preparado para aquele caso. Também inspecionaria o registro de chamadas, para detectar uma ação indevida que tenha sido posteriormente compensada.

Uma simulação não reproduz toda a infraestrutura. Depois dela, seriam necessários testes de integração compatíveis com os recursos oficiais do fornecedor e com o risco da operação. A sequência precisa ampliar a evidência gradualmente.

Meça quanto custa uma tarefa aprovada

O custo por chamada ajuda, mas o produto precisa pagar pelas tentativas que falharam, pelas consultas adicionais e pelas recuperações.

Eu acompanharia custo de execução por tarefa aprovada = custo de todas as execuções ÷ quantidade de tarefas aprovadas. O conjunto e os critérios precisam ser iguais para a comparação fazer sentido.

Um exemplo exclusivamente aritmético: em 100 tarefas sintéticas, uma configuração custa R$ 18 e aprova 60; outra custa R$ 24 e aprova 96. A primeira chega a R$ 0,30 por aprovação; a segunda, a R$ 0,25. Esses números não são resultados de um experimento.

Essa conta ainda deixa de fora revisão humana, manutenção e prejuízo causado por erros. Eu mostraria esses itens separadamente, junto de tempo de resposta e gravidade das falhas. Uma economia pequena não decide sozinha se uma configuração serve para a operação.

Transforme o resultado em uma decisão de entrega

Antes de comparar versões, definiria os impedimentos de lançamento e as melhorias desejáveis. Assim, uma nota agregada alta não conseguiria esconder um problema que a equipe já classificou como inaceitável.

Cada falha relevante viraria um caso de regressão, com a causa conhecida e o comportamento esperado. Na produção, acompanharia sinais de mudança e preservaria uma forma de interromper ou limitar o fluxo.

Esse cuidado também se conecta à discussão sobre agentes, permissões e alertas operacionais. O produto precisa oferecer condições para investigar o que aconteceu, sem depender exclusivamente da versão apresentada pelo agente.

Para começar, eu escolheria uma única tarefa que hoje exige conferência manual e transformaria essa conferência em critérios explícitos. O ganho inicial já é útil: a equipe passa a discutir evidências concretas. A partir daí, pode aumentar a autonomia sabendo melhor o que está aprovando.

Fontes

1. Anthropic — Demystifying evals for AI agents.
2. Claude — critérios de sucesso e avaliações.
3. AWS — Making retries safe with idempotent APIs.
4. LangSmith — conceitos de avaliação.
5. τ-bench — avaliação de interações entre agentes, ferramentas e usuários.
6. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
7. Laravel 13 — testes do cliente HTTP.
8. Laravel 13 — testes de filas.