Claude 3.5 e tool use: o que mudou e como aplicar
TL;DR
As atualizações em torno do Claude 3.5 consolidam o uso de ferramentas como parte central da experiência, com ganhos em tarefas agentic e suporte mais maduro no ciclo de execução via Messages API. Na prática, isso reduz atrito para construir fluxos em que o modelo decide quando chamar uma ferramenta, sua aplicação executa a ação e o resultado volta para uma nova decisão do modelo.
Para times que constroem automações, atendimento, análise de dados ou agentes internos, o recado é simples: o foco saiu de “pedir texto” e foi para orquestrar ações com controle explícito. Isso é especialmente relevante no Brasil, onde muitas equipes precisam equilibrar custo, tempo de implementação e governança de dados, inclusive por conta da LGPD.
O que mudou no ciclo do Claude 3.5
O ponto central do material de base é que a Anthropic tratou o tool use como funcionalidade madura no ecossistema Claude 3, e o ciclo do Claude 3.5 trouxe melhorias voltadas a tarefas agentic e tool use. O anúncio de tool use em disponibilidade geral posiciona a API como mecanismo oficial para integrar ferramentas externas; já o anúncio de Claude 3.5 Sonnet, Claude 3.5 Haiku e computer use associa a família 3.5 a ganhos em tarefas de uso de ferramentas.
Isso importa porque, em vez de um modelo dependendo apenas de prompt e resposta final, a aplicação passa a operar um ciclo: o modelo pede uma ação, o backend executa, devolve o resultado e o modelo segue com a próxima etapa. Esse padrão é comum em APIs de function calling e deixa a lógica de negócio do lado da aplicação, onde há mais controle sobre validação, auditoria e limitação de escopo.
Tool use na Messages API
A Anthropic descreve o tool use como parte da Messages API, com suporte também em integrações como Bedrock e Vertex AI. Para quem desenvolve no dia a dia, a consequência é que a camada de aplicação precisa registrar as tools, interpretar a solicitação do modelo e devolver o resultado no formato esperado pelo fluxo.
Esse desenho é útil quando a tarefa envolve consultar sistemas internos, rodar cálculo, buscar informação atualizada ou disparar automações. Em vez de “inventar” uma resposta, o modelo recebe dados executados em tempo real e pode seguir raciocinando sobre eles.
Melhorias no perfil agentic do Claude 3.5
No material sobre o ciclo 3.5, a Anthropic destaca melhoria em tarefas de coding e em tarefas agentic, incluindo tool use. A leitura prática é que o modelo ficou mais viável para cenários em que a decisão de chamar ferramentas é parte do trabalho, e não um detalhe periférico.
Isso afeta desde análises internas até automações com várias etapas. Por exemplo: interpretar uma solicitação em linguagem natural, consultar uma base, executar uma transformação e devolver um resumo pronto para validação humana.
Computer use como extensão do mesmo raciocínio
O anúncio do Claude 3.5 também introduz computer use como uma habilidade nova, ligada a interações com interfaces de computador. Mesmo quando o seu caso não exige automação de tela, isso mostra para onde o ecossistema está indo: menos dependência de integrações isoladas e mais capacidade de operar tarefas completas com supervisão da aplicação.
Na prática, vale pensar em uma continuidade entre tools discretas e tarefas orientadas a objetivo. O mesmo padrão mental ajuda a desenhar fluxos mais robustos, mesmo que você escolha manter tudo em chamadas explícitas no backend.
Como isso aparece no SDK oficial
O SDK oficial em TypeScript é um bom sinal de como a Anthropic espera que o ecossistema seja integrado. A referência ao tool runner e ao loop de execução indica o fluxo agentic típico: o modelo solicita uma tool, a aplicação executa a função registrada e devolve o resultado até a conversa encerrar.
Esse padrão é especialmente útil quando você quer separar três responsabilidades: interpretação do pedido, execução da ação e governança. Em empresas brasileiras, isso costuma ser valioso porque ajuda a manter o controle técnico e jurídico do que sai da IA, algo ligado diretamente a compliance e à LGPD.
A arquitetura de tool use muda mais a aplicação do que o prompt: o ganho real vem de definir bem as ferramentas, validar entradas e registrar saídas para auditoria.
Onde isso ajuda mais na prática
Se você trabalha com produto, suporte, dados ou automação, o tooling do Claude 3.5 faz sentido em cenários bem concretos. Alguns exemplos: consultar uma base interna antes de responder, preencher um relatório com dados de sistemas diferentes, gerar uma análise a partir de planilhas ou controlar um fluxo que precisa de etapas explícitas para não escapar do escopo.
Em times brasileiros, esse tipo de desenho costuma aparecer em produtos que precisam lidar com orçamento apertado e padronização de processo. Em vez de criar uma integração grande logo no início, é comum começar com um agente simples que consulta uma API, valida regras e só depois cresce para múltiplas tools.
Exemplo de integração em alto nível
Um fluxo comum é: a aplicação expõe uma tool para buscar cliente, outra para calcular benefício e outra para registrar o resultado. O modelo decide a ordem das chamadas e você mantém a política de acesso fora do prompt. Isso facilita revisão de segurança e reduz o risco de o modelo agir fora do caminho esperado.
Na prática, esse desenho funciona bem em áreas como atendimento automatizado, análise comercial, triagem de chamados e assistentes internos para times de engenharia. O ponto não é “ter IA”, e sim usar a IA como orquestradora de etapas com rastreabilidade.
Por que isso importa pro dev brasileiro
Há um motivo concreto para prestar atenção nisso no Brasil: a LGPD exige mais cuidado com coleta, finalidade e tratamento de dados pessoais. Quando você estrutura tool use com validação no backend, fica mais fácil limitar quais dados entram no modelo e quais saem para cada etapa do fluxo.
Além disso, muita operação brasileira ainda convive com sistemas legados, integrações parciais e times enxutos. Nesse contexto, uma arquitetura de tools tende a ser mais viável do que tentar “colar IA em tudo” de uma vez, porque permite entregar valor com fronteiras claras de responsabilidade técnica.
Outro ponto é custo. Em muitos times, o orçamento em BRL e a necessidade de justificar experiments fazem diferença real. Um fluxo de tool use bem recortado ajuda a evitar chamadas desnecessárias e facilita medir o que realmente gera retorno.
Boas práticas para adotar sem retrabalho
Comece pequeno: uma tool para consulta, uma para execução e uma regra de autorização na aplicação. Depois, registre cada chamada e cada retorno para conseguir auditar o comportamento do agente. Isso é importante tanto para segurança quanto para depuração.
Também vale tratar a tool como contrato, não como improviso. Nome, schema de entrada, limites de uso e tratamento de erro precisam ser explícitos. Quanto mais previsível o contrato, menor a chance de o fluxo quebrar quando o modelo fizer uma escolha inesperada.
Se o uso envolver versões de SDK ou API, confira a documentação oficial antes de levar para produção. APIs de IA mudam rápido, e o que funciona hoje pode exigir ajuste amanhã.
Conclusão
As atualizações ligadas ao Claude 3.5 mostram uma direção clara: o valor está menos em gerar texto e mais em executar fluxos com ferramentas, controle e rastreabilidade. Para quem desenvolve no Brasil, isso conversa diretamente com LGPD, custo e necessidade de integrar IA em sistemas que nem sempre foram criados para isso.
Se você quer validar isso em menos de 1 hora, abra o SDK oficial, escolha um exemplo de tool use e adapte uma única tool simples ao seu contexto, como uma consulta a API interna ou uma função de cálculo. Depois, rode o fluxo localmente e observe onde o contrato entre modelo e aplicação ainda precisa ficar mais rígido.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
