Claude tool use e a nova camada de agentes da Anthropic

TL;DR

A Anthropic consolidou o tool use como parte da execução normal de Claude: o modelo pode pedir ferramentas, receber resultados e continuar o raciocínio com base em dados externos. Isso importa porque desloca o foco de respostas isoladas para fluxos em que o modelo age sobre sistemas reais, sem precisar carregar tudo no contexto.

A nova camada de agentes aparece quando essa mecânica ganha escala: descoberta seletiva de ferramentas, orquestração via código e padrões como roteamento e paralelização. Na prática, isso reduz atrito para integrar Claude a APIs, microsserviços e pipelines internos, inclusive em times brasileiros com orçamento e contexto mais restritos.

O que mudou no Claude

O anúncio de tool use como GA deixou explícito que Claude não é só um gerador de texto: ele pode interagir com ferramentas externas por meio da API de mensagens. Em vez de “simular” acesso a um sistema, o modelo produz blocos de tool_use e espera o retorno correspondente, fechando um ciclo de ação e observação documentado em Tool use with Claude.

Isso muda a unidade de trabalho. O desenvolvedor deixa de pensar apenas em prompt e passa a pensar em contrato: qual ferramenta existe, em que formato Claude deve chamá-la e como o resultado volta para o próximo passo. A documentação oficial também mostra controle por tool_choice, permitindo forçar, negar ou deixar o modelo decidir a chamada, como descrito em Tool use overview e em Implement tool use.

Quando o modelo vira um orquestrador

A camada de agentes começa quando Claude deixa de ser apenas o ponto de decisão e vira o coordenador de passos. No texto Building Effective AI Agents, a Anthropic trata tool orchestration como um padrão arquitetural: roteamento, paralelização e composição de tarefas são mecanismos centrais para agentes úteis.

Esse ponto é importante porque muitos sistemas falham não por falta de capacidade do modelo, mas por excesso de contexto e baixa disciplina de execução. Um agente precisa decidir quando consultar uma API, quando esperar uma resposta determinística e quando dividir uma tarefa em partes independentes. É essa camada de coordenação que dá forma ao comportamento “agentic” sem transformar tudo em conversa longa.

Tool Search: descobrir em vez de carregar tudo

Em linhagens tradicionais de tool use, o sistema precisava empilhar no contexto descrições de muitas ferramentas, mesmo quando só uma pequena parcela seria usada. O post Introducing advanced tool use on the Claude Developer Platform propõe o Tool Search Tool para resolver exatamente esse gargalo: em vez de carregar catálogo inteiro, Claude busca on-demand as ferramentas relevantes.

Na prática, isso ajuda quando a organização tem dezenas ou centenas de ferramentas internas. Um catálogo grande é caro de manter no contexto e também aumenta a chance de o modelo escolher mal a interface certa. Com busca de ferramentas, a plataforma tenta reduzir o ruído inicial e trazer só o subconjunto pertinente para a etapa seguinte, o que é especialmente útil em ecossistemas com muitos microsserviços e integrações.

O ganho não é só de custo de tokens. Há também um ganho de operação: se a descrição de uma tool muda, o sistema não depende de um prompt gigantesco sempre atualizado. Em vez disso, o agente consulta o catálogo e trabalha com uma visão parcial, porém mais controlada, do ambiente disponível.

Programmatic Tool Calling e o fim do contexto inchado

A segunda peça da nova camada é o Programmatic Tool Calling, também descrito no post de tool use avançado. A ideia é mover parte da orquestração para o código, em vez de deixar todo o encadeamento acontecer dentro da conversa. Assim, o sistema controla melhor o que entra no contexto e evita que uma sequência longa de chamadas exploda a janela disponível.

Esse padrão é útil em fluxos que dependem de várias ferramentas em cadeia: buscar dados, normalizar, consultar outro serviço, agregar e só então responder. Em vez de despejar tudo na conversa do modelo, a aplicação pode executar etapas intermediárias de forma programática e alimentar Claude apenas com o necessário para a próxima decisão.

Esta seção descreve a versão documentada pela Anthropic no momento do brief. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.

Para times que operam com restrição de custo, esse desenho faz diferença. Menos contexto inútil significa menos tokens queimados, menos latência e mais previsibilidade sobre quanto uma requisição realmente custa. Em ambiente brasileiro, isso pesa ainda mais porque orçamento em BRL e variação cambial tornam qualquer excesso de consumo mais visível na fatura.

Como pensar um agente com ferramentas

O material Building Effective AI Agents também ajuda a sair da visão romântica do agente autônomo. O desenho recomendado é menos “um cérebro faz tudo” e mais “um sistema coordena passos”. Isso inclui roteamento para escolher a ferramenta ou o caminho certo, e paralelização para executar subtarefas independentes ao mesmo tempo.

Esse recorte combina bem com aplicações reais. Se a consulta do usuário pede dados de produto, vendedor e estoque, por exemplo, o agente pode disparar chamadas em paralelo, consolidar os resultados e só então montar a resposta final. Isso reduz a sensação de chat lento e torna a arquitetura mais próxima de um workflow do que de uma sequência interminável de mensagens.

O repositório oficial anthropics/anthropic-tools mostra estruturas e exemplos para conectar Claude a ferramentas fornecidas. Para quem está saindo do experimento e indo para implementação, esse tipo de exemplo ajuda a descolar a teoria de agent engineering da integração concreta com mensagens, entradas estruturadas e resultados de tool.

O que isso significa para aplicações reais

A camada de agentes da Anthropic não elimina o trabalho de engenharia; ela reorganiza onde esse trabalho acontece. O modelo continua importante para raciocinar, interpretar intenção e consolidar evidências, mas a execução passa a depender de contratos claros entre API, ferramentas e código intermediário. Isso tende a favorecer sistemas mais auditáveis do que fluxos em que tudo fica escondido no prompt.

Há também um benefício de manutenção. Quando a aplicação cresce, o problema raramente é “o modelo não sabe responder”; o problema é governança de ferramentas, custo, latência e consistência entre chamadas. Tool Search e Programmatic Tool Calling atacam justamente esses pontos de escala, que aparecem cedo em produto e tarde demais em protótipo.

Por que importa pro dev brasileiro

No Brasil, o problema aparece com contornos concretos: time enxuto, custo em dólar e uso intenso de infra em regiões como us-east-1 por conta de disponibilidade e ecossistema. Quando uma aplicação de agentes precisa chamar várias ferramentas, qualquer uso desnecessário de tokens vira custo recorrente, e qualquer latência extra vira percepção ruim no produto. Isso é diferente de um cenário puramente experimental.

Também existe um componente de governança. Em aplicações que tocam dados pessoais, a LGPD exige cuidado com minimização e finalidade. Uma arquitetura que carrega menos contexto, consulta menos dados por vez e registra melhor as etapas fica mais fácil de justificar em revisão de segurança, privacidade e compliance.

Na prática, isso favorece times brasileiros que constroem automações para atendimento, operações e backoffice. Em vez de tentar enfiar todo o domínio no prompt, vale separar o que é decisão do modelo, o que é busca em ferramenta e o que deve ficar em serviços determinísticos. Esse desenho tende a ser mais barato para manter e mais simples de auditar quando o sistema entra em produção.

Como começar em até uma hora

Se você já usa Claude em algum fluxo interno, escolha um caso pequeno: por exemplo, uma ferramenta para buscar pedidos, outra para consultar status e uma terceira para registrar ação. Depois, veja se o modelo realmente precisa conhecer todas as definições ao mesmo tempo ou se dá para introduzir uma camada de descoberta seletiva.

O passo mais útil é abrir a documentação oficial de tool use, revisar o ciclo tool_use/tool_result e adaptar um fluxo simples no seu serviço. Se o seu stack já tem orquestração em Python ou TypeScript, encaixe a chamada de ferramenta no código e reserve o modelo para a decisão onde ele realmente agrega. Em menos de uma hora, dá para sair do conceito e validar o primeiro circuito real.

Conclusão

A evolução do Claude mostra uma mudança relevante: o centro da integração não é mais só a resposta, mas a capacidade de coordenar ferramentas com menos contexto e mais controle. Tool use, Tool Search e Programmatic Tool Calling formam uma base prática para agentes que precisam conversar com sistemas reais sem virar um bloco monolítico difícil de manter.

Se você quiser aplicar isso no seu projeto, pegue um fluxo simples hoje mesmo, leia a seção de tool use e implemente uma única tool com contrato claro, testando o ciclo completo de entrada, chamada e retorno.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.