Anthropic Claude e o salto no uso programático de tools
TL;DR
O release de advanced tool use do Claude, anunciado pela Anthropic em 24 de novembro de 2025, adicionou três capacidades práticas para cenários com múltiplas ferramentas: descoberta dinâmica de tools, carregamento sob demanda e execução via code execution como caller. Na prática, isso reduz sobrecarga de contexto e abre espaço para integrações mais moduladas, desde automação interna até agentes que precisam escolher ferramentas em tempo de execução.
Para times que já sofrem com catálogos grandes de APIs, a mudança não é só de ergonomia. Ela afeta arquitetura: você pode expor menos superfície de ferramentas por interação, controlar melhor o que entra no contexto e rastrear com mais clareza de onde partiu cada `tool_use`.
O que mudou no release
A Anthropic descreveu o novo pacote como advanced tool use, com foco em permitir que o Claude descubra, aprenda e execute tools de forma mais dinâmica. O ponto central aqui é simples: em vez de carregar tudo de uma vez, o modelo pode localizar o que precisa no momento certo.
Na doc oficial de programmatic tool calling (Claude Platform Docs), a Anthropic também explicita o campo `caller`, o que ajuda a distinguir chamadas diretas de chamadas orquestradas por code execution. Isso não é detalhe cosmético; é o tipo de observabilidade que facilita auditoria e debug em fluxos agentic.
Esta seção descreve a versão documentada pela Anthropic para advanced tool use e programmatic tool calling. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Tool search: descoberta em vez de catálogo gigante
O anúncio de advanced tool use introduz uma abordagem de tool search para descobrir ferramentas relevantes em runtime. Em vez de empilhar dezenas ou centenas de definições na conversa, o Claude pode consultar um mecanismo de busca de tools e seguir só com o subconjunto útil para a tarefa atual.
Isso é especialmente relevante quando o ambiente tem múltiplos sistemas legados, serviços internos e integrações de parceiros. Em vez de forçar toda a taxonomia de APIs para dentro do contexto, você deixa a seleção acontecer mais tarde, quando a intenção do usuário já está mais clara.
Por que isso importa
O ganho não é só latência. Catálogos enormes competem por contexto com instruções, histórico de conversa e saídas intermediárias. Ao adiar a seleção, você preserva mais espaço para raciocínio útil e reduz a chance de o modelo se perder em ferramentas periféricas.
Na prática, isso conversa bem com plataformas que expõem muitos endpoints parecidos: pagamentos, CRM, suporte, analytics, automação interna. O modelo responde melhor quando enxerga menos ruído e mais relevância.
Defer loading: carregar só quando precisar
Outra peça do release é o defer loading. O padrão é declarar ferramentas com carregamento adiado e expandir apenas as que realmente forem necessárias no fluxo.
Esse tipo de estratégia ajuda quando a definição da tool é grande, quando há dependências de esquema pesadas ou quando você quer reduzir a pressão sobre o contexto inicial. Em vez de tratar o catálogo como uma lista fixa, você passa a tratá-lo como uma coleção sob demanda.
Isso também melhora manutenção. Times que versionam muitas integrações conseguem reorganizar suas tools sem obrigar cada conversa a carregar o universo inteiro de capacidades desde o primeiro turno.
Programmatic tool calling e o campo caller
Nas docs de programmatic tool calling, a Anthropic mostra que cada `tool_use` pode carregar um campo `caller`, indicando se a execução veio de uma chamada direta ou de um ambiente de code execution, como `code_execution_20260120`. Isso dá mais nitidez para rastreamento e para políticas de controle em ambientes com automação complexa.
Para equipes de infraestrutura e plataformas internas, esse detalhe muda o tipo de observabilidade que você consegue montar. Fica mais fácil distinguir um tool call originado por prompt de um tool call que nasceu dentro de uma rotina programática intermediária.
Code execution como orquestrador
O anúncio e a documentação destacam compatibilidade com code execution como pré-requisito para esse formato de chamada. A ideia é permitir que o ciclo de execução, validação e retorno aconteça no ambiente de execução, com menos ida e volta desnecessária entre camadas de orquestração.
Em cenários multi-tool, isso pode cortar passos intermediários. Em vez de o modelo precisar pedir, esperar e reenfileirar várias etapas manualmente, parte da coordenação ocorre mais perto da execução real.
O que muda para integrações reais no dia a dia
Se você mantém um agente para suporte interno, busca em base de conhecimento, geração de relatórios ou automação de tarefas, a mudança principal é arquitetural. Você pode separar descoberta, carregamento e execução em fases distintas, o que deixa o desenho mais próximo de um sistema de plugins do que de um prompt monolítico.
Isso também favorece testes. Ao enxergar o `caller` e ao modularizar o carregamento das tools, fica mais simples simular caminhos específicos, medir custo por etapa e entender onde o fluxo está gastando contexto demais.
Outro efeito importante é a governança. Em ambientes corporativos, deixar o modelo descobrir ferramentas dinamicamente sem controle seria perigoso. Com `defer_loading`, seleção explícita e observabilidade por caller, dá para desenhar limites mais claros entre o que pode ser exposto e o que deve permanecer oculto.
Por que importa pro dev brasileiro
No Brasil, esse tipo de mudança pesa mais porque muitos times trabalham com orçamento em BRL e com margens apertadas para consumo de contexto e chamadas por IA. Reduzir tool definitions carregadas à toa pode significar menos custo operacional em um cenário em que o dólar impacta diretamente a conta do mês.
Além disso, LGPD e auditoria interna contam bastante em empresas brasileiras, especialmente em bancos, varejo e SaaS que lidam com dados pessoais. Um fluxo que registra melhor de onde partiu cada tool call tende a ser mais fácil de defender em revisão de segurança e governança, principalmente quando o time precisa explicar por que certa automação acessou um sistema sensível.
Para equipes no Brasil, há também a questão da topologia de infraestrutura. Muita operação fica concentrada em regiões como `us-east-1`, e cada ida e volta extra entre modelo, orquestrador e ferramentas aumenta latência percebida pelo usuário. Diminuir essa fricção ajuda bastante em atendimentos e automações com SLA apertado.
Como pensar adoção sem complicar a pilha
O melhor caminho costuma ser começar pequeno: pegue um caso com poucas tools, implemente descoberta tardia e observe como o contexto se comporta. Depois, se houver ganho claro, leve a mesma lógica para catálogos maiores.
Se você já trabalha com APIs internas, vale mapear quais ferramentas são realmente candidatas a uso frequente e quais devem ficar atrás de uma etapa de busca. A regra prática é manter o modelo o mais próximo possível do subconjunto necessário para cada tarefa.
Também vale revisar telemetria. Se o sistema já consegue capturar `tool_use`, `caller`, tempo de execução e falhas por tool, você ganha uma base melhor para comparar o pipeline antigo com o novo.
Conclusão
O release de advanced tool use do Claude não é só um anúncio de recurso; ele empurra a arquitetura de agentes para um modelo mais modular, observável e barato em contexto. Para times que já operam muitas integrações, a combinação de descoberta dinâmica, defer loading e programmatic tool calling resolve parte do atrito que sempre existiu entre “ter muitas tools” e “conseguir usá-las sem inflar tudo”.
Se você quiser validar isso em menos de 1 hora, abra a documentação oficial de programmatic tool calling, escolha um fluxo interno com duas ferramentas e desenhe uma versão mínima com descoberta tardia para comparar tempo de resposta e quantidade de contexto carregado.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
