Como avaliar a nova camada de tool use da Anthropic em 2026
TL;DR
Em 2026, a Anthropic deslocou o centro de gravidade do tool use: não basta chamar uma ferramenta, é preciso avaliar se o agente entrega o resultado esperado. A combinação de Managed Agents, outcomes e graders transforma a avaliação em parte do próprio fluxo de execução, o que reduz a distância entre teste e produção.
Para quem constrói produtos com IA, isso muda a prática diária: você passa a medir qualidade por rubricas, iterar com feedback estruturado e ajustar o esforço de raciocínio conforme a tarefa. O ponto útil não é só “o modelo sabe usar ferramenta?”, mas “ele consegue completar um trabalho com qualidade repetível?”.
O que mudou no tool use da Anthropic
O material de 2026 mostra que a Anthropic expandiu o tool use para além de uma simples chamada de API. A documentação de Managed Agents descreve um fluxo em que você define um outcome, uma rubrica e um grader para comparar o estado atual com o resultado esperado. Isso aproxima a avaliação de um processo de engenharia de software: especificação, execução, validação e nova iteração.
Na prática, essa mudança é importante porque um agente pode até “usar ferramentas” e ainda assim produzir um artefato ruim. A avaliação por outcome força o sistema a responder a uma pergunta mais útil: o trabalho terminou no padrão esperado? Se não terminou, o grader devolve os gaps para a próxima tentativa.
Outcomes e graders como unidade de avaliação
A vantagem de outcomes é que eles tornam explícito o que antes ficava implícito em testes manuais. Em vez de olhar logs soltos, você define critérios observáveis e faz o harness apontar onde o agente falhou. Isso permite comparar versões do fluxo com mais consistência, especialmente quando o agente combina busca, síntese, escrita e decisão.
O modelo de outcomes é útil quando o sucesso não cabe em uma métrica única. Em tarefas de IA aplicada, o que vale é a soma de precisão, cobertura, formatação e aderência ao objetivo.
Essa lógica conversa bem com times que já usam testes automatizados. O diferencial é que agora o “teste” pode avaliar o resultado de uma sequência longa de ações, e não só uma resposta curta. A Anthropic publicou isso na documentação de Define outcomes.
Web search e filtragem dinâmica
Outro ponto relevante é a evolução da web search tool. A documentação indica suporte a filtragem dinâmica com código, o que permite remover ruído antes que o resultado entre no contexto do agente. Isso é valioso em avaliação porque separa dois tipos de falha: recuperação ruim de informação e síntese ruim da informação recuperada.
Ao reduzir contexto irrelevante, você observa melhor onde o agente está errando. Se o problema desaparece quando o ruído cai, a falha é de retrieval. Se continua mesmo com contexto limpo, a falha está na decisão ou na composição da resposta.
Advisor tool e correção intercalada
A advisor tool adiciona outra camada: um executor consulta um advisor no meio da geração para planejar ou corrigir rota. Isso abre espaço para arquiteturas em que um modelo mais barato executa e um segundo modelo ajuda a revisar a estratégia.
Esse desenho é interessante para medir custo e qualidade separadamente. Você pode avaliar se a consulta ao advisor melhora o trajeto sem inflar demais a latência, ou se o ganho de qualidade não compensa o custo extra. Em produtos reais, esse tipo de decisão costuma ser mais relevante do que comparações abstratas entre modelos.
Computer use e o loop de agente
A computer use tool formaliza o loop de agente com screenshots, mouse e teclado. É uma referência importante porque desloca o tool use do texto para a interação com a interface. Em avaliação, isso exige olhar para sucesso operacional: o agente clicou no lugar certo? completou a tarefa? voltou do estado errado sem travar?
Esse tipo de automação é especialmente útil para fluxos internos de QA, cadastro, suporte e operações. Mas, do ponto de vista de avaliação, ela também aumenta a superfície de erro. Por isso, outcome e grader viram quase obrigatórios: sem eles, fica difícil comparar se a automatização de fato entregou resultado confiável.
Como interpretar a avaliação em 2026
O novo recorte de avaliação não trata apenas de benchmark pontual. Ele combina o desempenho do agente, o custo do caminho e a qualidade final do artefato. A própria Anthropic menciona, no material sobre Claude Opus 4.7, controles de esforço como `xhigh`, sinalizando que a relação entre raciocínio, latência e resultado passou a ser um parâmetro explícito de engenharia.
Isso é útil porque muitos times ainda medem IA só por “acertou ou errou”. Em agentes, esse binário é insuficiente. Você precisa medir também quantas tentativas foram necessárias, quanto contexto foi consumido, quanto tempo a execução levou e se a resposta final é auditável.
Esforço, latência e qualidade
A documentação e os relatos de qualidade mostram um trade-off claro: mais esforço pode ajudar em tarefas difíceis, mas aumenta latência. O postmortem da Anthropic sobre Claude Code também registra ajustes de esforço padrão para melhorar a experiência percebida. Isso não é detalhe menor; em sistemas de agente, a experiência do usuário depende muito de não parecer que a interface travou.
Para avaliação, isso significa que a métrica correta não é apenas “qual foi a resposta final”. É preciso registrar se a solução ficou aceitável dentro de um orçamento de tempo e custo. Em produção, esse orçamento costuma ser a verdadeira restrição.
O que medir em um piloto
Se você vai testar uma arquitetura com tool use, comece com critérios simples e observáveis. Por exemplo: taxa de conclusão do outcome, número médio de iterações, tempo total por tarefa, custo por execução e qualidade do artefato final em uma rubrica curta. Depois, compare variações do mesmo fluxo com e sem advisor, com e sem filtragem dinâmica, e com limites diferentes de esforço.
Essas medidas ajudam a evitar conclusões apressadas. Um agente pode parecer “bom” em demo e ainda assim falhar em consistência. A avaliação por outcome reduz esse risco porque tira o foco da impressão subjetiva e leva para um conjunto de critérios repetíveis.
Por que isso importa para times de produto e plataforma
Para times de produto, o ganho está em previsibilidade. Você deixa de depender de relatos soltos de qualidade e passa a ter uma rotina de validação mais parecida com CI/CD. Para times de plataforma, o ganho está na governança: fica mais fácil comparar versões de agentes, acompanhar regressões e justificar quando vale aumentar custo computacional.
Esse ponto é especialmente relevante em empresas brasileiras que operam com margens apertadas e infraestrutura em dólar. Quando o orçamento é em BRL, qualquer aumento de latência ou de chamadas em modelos maiores pesa rápido no custo do mês. Por isso, usar outcomes e esforço controlado ajuda a decidir onde vale pagar mais e onde vale manter o fluxo mais enxuto.
Uma leitura prática do cenário brasileiro
No Brasil, a discussão também cruza com LGPD. Se o agente busca, classifica e resume dados pessoais, você precisa saber exatamente quais informações entram no contexto e por quanto tempo ficam expostas no fluxo. A combinação de rastreabilidade da execução e critérios de avaliação ajuda a reduzir improviso em tarefas que tocam dados sensíveis.
Além disso, muitos times brasileiros ainda operam com squads pequenos e dependem de automação para ganhar escala sem contratar a mesma velocidade de uma big tech. Nesse cenário, ferramentas de avaliação embutidas no workflow ajudam a validar agentes que apoiam suporte, análise documental e operações internas, sem exigir uma equipe enorme de revisão manual.
Como eu avaliaria isso em um projeto real
Um piloto razoável começaria com uma tarefa bem delimitada: por exemplo, um agente que coleta informações, monta um resumo e entrega um artefato final segundo uma rubrica. Depois, eu dividiria o teste em três camadas: recuperação, raciocínio e entrega. A web search tool pode ajudar a controlar o ruído; o advisor pode ajudar a corrigir rota; o outcome verifica se o resultado final ficou dentro do esperado.
Se o fluxo usa versão específica de SDK, API ou CLI, a regra é simples: a avaliação precisa registrar essa versão e ser reexecutável. APIs de IA mudam rápido, então o valor está em conseguir revisar o mesmo caminho depois, não em repetir uma demo que só funciona na memória de quem montou.
Esta seção descreve a versão documentada em 2026 das ferramentas citadas. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
undefined
O exemplo acima não é uma implementação pronta; é só uma forma prática de pensar a avaliação. O que importa é tornar visível o que você quer medir e quais sinais vão mostrar se o agente está melhorando. Sem isso, o debate sobre tool use tende a virar opinião.
Conclusão
O principal recado da Anthropic em 2026 é que tool use maduro não termina na chamada da ferramenta. Ele depende de um ciclo de execução avaliado por outcomes, com observabilidade suficiente para explicar por que o agente chegou ao resultado final. Para equipes técnicas, isso abre caminho para testar agentes como componentes de produto, e não como protótipos de laboratório.
Se você quer aplicar isso no seu contexto, escolha uma tarefa de alto impacto, defina a rubrica em três critérios e rode uma comparação entre dois fluxos: um com contexto limpo e outro com filtragem dinâmica. Em menos de 1 hora, você já consegue ver se a sua dor está na recuperação, na execução ou na avaliação do resultado.
Conteúdos da DIO para quem quer aprofundar
- Nexa - Engenharia de Prompts na AWS com Claude — trilha prática para aplicar engenharia de prompts e usar o Claude 3 em cenários do dia a dia.
- Nexa - Fundamentos de IA Generativa e Claude 3 — introdução sólida à IA generativa, com foco em aplicações reais e serviços AWS.
- Aceleração Microsoft AI Agents — evento prático sobre agentes de IA, automação e criação de fluxos com ferramentas modernas.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
