Claude Sonnet 5 e tool use em fluxos agentic

TL;DR

Claude Sonnet 5 altera o jeito de construir fluxos agentic porque ativa adaptive thinking por padrão, muda o controle de profundidade para effort e quebra combinações antigas de parâmetros que antes passavam sem erro. Na prática, isso obriga o time a revisar orquestração de ferramentas, validação de respostas estruturadas e defaults do SDK antes de tratar a migração como um simples upgrade de modelo.

O que mudou no Sonnet 5

O anúncio oficial do modelo descreve o Sonnet 5 como um drop-in upgrade do Sonnet 4.6, mas a documentação também deixa claro que a superfície operacional mudou. A página de visão geral informa que o modelo foi lançado em 2026-06-30 e que já nasce com adaptive thinking habilitado por padrão, além de suporte a recursos de tool use e computer use no Claude API.

Isso importa porque, em sistemas agentic, o comportamento do modelo não é só uma questão de resposta final. Ele afeta como o orquestrador decide quando chamar ferramenta, quanto contexto preservar entre passos e como interpretar saídas estruturadas sem misturar raciocínio com texto visível.

Adapters e wrappers precisam de compatibilidade por modelo

A mudança mais perigosa para quem mantém gateways, routers e abstrações de IA é presumir que Sonnet 4.6 e Sonnet 5 aceitam a mesma configuração. A documentação What’s new in Claude Sonnet 5 relata três mudanças de comportamento relevantes: adaptive thinking on by default, falha com código 400 em chamadas que tentam usar manual extended thinking no formato antigo e rejeição de temperature, top_p e top_k quando não estão nos defaults esperados.

Em outras palavras, um wrapper que faz normalização global de sampling params pode quebrar justamente no caminho agentic, onde cada chamada precisa obedecer ao regime do modelo escolhido. Se o objetivo é estabilidade, o roteamento precisa ser por família e por versão, não só por nome genérico de “Claude”.

Esta seção descreve a versão 5 de Claude. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.

Adaptive thinking muda a forma de planejar loops de ferramentas

No Sonnet 5, o thinking adaptativo passa a ser o padrão. A documentação de extended thinking e a visão geral do modelo mostram que isso conversa diretamente com o que o artigo chama de fluxos agentic: o modelo pode gastar parte da cota em raciocínio interno antes de decidir por uma chamada de ferramenta ou por uma resposta textual.

Isso altera o desenho do loop. Em vez de pensar em “perguntar, receber, agir”, o orquestrador precisa considerar ciclos mais longos, em que o modelo pode avaliar mais de uma rota de tool use antes de expor a próxima ação. O guia de effort desloca o controle para níveis como high e xhigh, o que é útil quando a tarefa exige exploração maior, como busca, síntese de evidências e depois edição ou teste.

Na prática, isso favorece pipelines do tipo: localizar evidência, ler detalhes, decidir entre ações possíveis, e só então executar. Para tarefas determinísticas, a tendência é baixar effort; para tarefas com incerteza, vale subir effort e aceitar mais custo por turno. O ganho não vem de “pensar mais sempre”, mas de calibrar a profundidade ao tipo de passo do agente.

Planejamento de ferramentas fica mais explícito

Com thinking por padrão, convém separar o que é planejamento do que é execução. Um agente que precisa consultar documentação, abrir um arquivo, comparar duas respostas e depois consolidar a saída deve tratar cada ferramenta como fase observável do fluxo, não como detalhe implícito do prompt.

Isso também reduz um erro comum em integrações: achar que a ferramenta foi chamada quando, na verdade, o modelo apenas descreveu a intenção em texto. A documentação de troubleshooting recomenda atenção a tool call leaks, em que a chamada aparece no texto visível em vez de virar uma saída estruturada. Nesse caso, a ferramenta não executa e o texto residual ainda polui o histórico.

Como construir loops agentic mais robustos

Em um fluxo real, o validador do orquestrador precisa ser tão importante quanto o prompt. Se uma resposta deveria conter uma chamada estruturada a ferramenta, mas veio como texto comum, a camada de controle deve detectar a discrepância e bloquear a próxima etapa. Isso evita que o agente siga “alucinando execução” enquanto nada foi realmente rodado.

Outra proteção prática é separar a memória do agente em camadas. O histórico de raciocínio e os resultados de ferramentas são úteis, mas devem ser comprimidos com critério quando o contexto cresce. O Sonnet 5 anuncia contexto de 1M tokens por padrão e saída máxima de 128K, o que reduz a pressão imediata por compactação, mas não elimina a necessidade de poda e sumarização em loops longos.

Para times que usam MCP, browser use ou computer use, o ponto principal é manter contratos estáveis entre ferramenta e modelo. Quanto mais o agente depende de múltiplas chamadas, maior a chance de um campo fora do padrão quebrar a sequência inteira.

Em agentes long-horizon, a estabilidade do formato conta menos que a estabilidade do contrato. Se o contrato muda, o orquestrador precisa validar mais cedo e falhar mais claramente.

Exemplo de checklist operacional

Validar se o modelo ativo aceita os parâmetros enviados pelo gateway.
Checar se a resposta contém tool use estruturado, não só texto com intenção de chamar ferramenta.
Separar turnos de planejamento, execução e consolidação.
Restringir sampling defaults por versão do modelo.
Registrar quando o effort sobe para tarefas que exigem exploração mais longa.

O que isso muda para times que mantêm agentes em produção

O primeiro impacto é de engenharia de plataforma. Quem tem um gateway interno precisa versionar comportamento por modelo, porque Sonnet 5 responde diferente de Sonnet 4.6 na mesma superfície de API. O segundo impacto é de observabilidade: logs precisam distinguir falha de tool use, retorno textual e resistência do modelo em produzir a estrutura esperada.

O terceiro impacto é de custo. Quando o effort sobe, o modelo tende a gastar mais raciocínio antes da resposta, e isso afeta latência e orçamento. Em fluxos agentic bem instrumentados, essa troca faz sentido, mas precisa ser explicitada para não virar “modelo ficou caro” sem diagnóstico.

Também vale revisar prompts que dependem de instruções implícitas. Se antes o agente sozinho “descobria” quando chamar uma ferramenta, agora o fluxo deve ser mais rigoroso sobre critérios de acionamento, formato de saída e tratamento de erro. O modelo ficou mais capaz de raciocinar, mas isso não substitui contrato de integração.

Por que isso importa pro dev brasileiro

No Brasil, esse tipo de mudança pesa mais porque muita operação roda com margem curta de custo e com infraestrutura hospedada fora do país. Um agente que passa a usar mais contexto, mais esforço e mais chamadas de ferramenta pode aumentar de forma sensível a conta em dólar de um time que já lida com orçamento em real e variação cambial. Em stacks comuns no mercado BR, a combinação de AWS em regiões fora do país com observabilidade em ferramentas terceiras torna qualquer mudança de comportamento do modelo uma decisão de plataforma, não só de prompt.

Há também o componente regulatório. Se o agente manipula dados pessoais, logs de tool use e documentos internos, a adoção precisa respeitar a LGPD, especialmente quando o fluxo grava contexto demais ou replica dados sensíveis entre ferramentas. Em times brasileiros que atendem varejo, bancos, saúde ou setor público, validar retenção, minimização e rastreabilidade deixa de ser luxo e vira requisito de arquitetura.

Conclusão

Claude Sonnet 5 não muda só a linha do modelo; ele muda o contrato mental de quem orquestra agentes. Adaptive thinking por padrão, effort como dial principal e quebra de compatibilidade em parâmetros antigos forçam uma revisão do loop de ferramentas, da validação de saída e dos defaults de integração.

Se você mantém um agente em produção, a ação mais útil em até uma hora é abrir o arquivo de configuração do seu gateway, comparar o payload enviado hoje com as regras do Sonnet 5 e remover qualquer parâmetro de sampling ou thinking que ainda dependa do comportamento do Sonnet 4.6. Depois, rode um teste simples de loop com uma ferramenta e confirme se a saída vem como estrutura, não apenas como texto.

Conteúdos da DIO para quem quer aprofundar

AWS - Agentes de IA em Campo — trilha com foco em agentes de IA e práticas de implementação em cenários reais.
Michael Page - Criando Seu Primeiro Agente de IA — apresenta fundamentos para sair da automação simples e montar um agente funcional.
Universia - Fundamentos de IA Generativa 2026 — cobre conceitos-base que ajudam a entender capacidades e limites de modelos generativos.
Santander- Excel com IA e Claude — mostra aplicações práticas de Claude em automação e produtividade com dados.
Aceleração: AI Reports com Excel, GPT Agents e Claude Code — une agentes, Claude e produtividade em um cenário orientado a relatório.

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