Anthropic tool use e Claude Agent SDK em 2026
TL;DR
Em 2026, o foco da Anthropic saiu do “chamar ferramenta por ferramenta” e foi para a orquestração do agente como unidade de produto: o Claude Agent SDK assume o loop, aplica permissões e integra ferramentas embutidas, hooks e MCP. Para times que já trabalham com automação e dados, isso muda a forma de construir agentes porque desloca o esforço de plumbing para governança, contexto e desenho de fluxo.
Na prática, o ponto central não é só “o modelo usa ferramentas”, mas quem controla quais ferramentas, quando e com que limites. Isso importa bastante em cenários corporativos, especialmente no Brasil, onde LGPD, auditoria e a preferência por fluxos com aprovação explícita pesam na adoção.
O que mudou no tool use da Anthropic
A visão apresentada pela Anthropic separa dois caminhos: no Client SDK, você implementa o loop de chamada de ferramentas; no Agent SDK, o próprio Claude conduz esse ciclo de forma autônoma, dentro do conjunto de capacidades permitido. A documentação oficial do Claude Agent SDK mostra essa mudança de foco: menos código de orquestração no cliente e mais controle declarativo sobre o que o agente pode fazer.
Essa abordagem aparece com clareza no ecossistema de ferramentas permitidas. Em vez de uma integração genérica, você declara `allowed_tools` e deixa o agente decidir entre ações como leitura, edição, busca, shell e outras ferramentas suportadas. O valor aqui é simples: o modelo deixa de ser apenas um gerador de texto e passa a operar como um executor guiado por regras.
Allowed tools como contrato, não detalhe de implementação
O ganho prático de `allowed_tools` é que a superfície de ação vira contrato. Se o agente só pode ler arquivos, editar determinados trechos e executar comandos em sandbox, você já reduz espaço para comportamento indesejado antes mesmo da primeira chamada ao modelo. A quickstart oficial mostra exatamente esse padrão com exemplos de permissões e edição automática.
Esse ponto parece óbvio, mas resolve uma dor recorrente em agentes: quando o modelo tem liberdade demais, o custo de revisão sobe e a confiabilidade cai. Com contrato explícito, o time consegue pensar em política de execução do mesmo jeito que pensa em permissões de banco ou escopos de API.
Governança: permission_mode, sandbox e can_use_tool
O conjunto de controles de execução é uma das partes mais relevantes do SDK. A documentação de Python do Agent SDK reference e a quickstart mostram mecanismos como `permission_mode`, sandbox e `can_use_tool`, que permitem aprovar, negar ou restringir ações sensíveis.
Isso é especialmente útil em fluxos que tocam arquivo local, comandos de sistema ou integrações externas. Em vez de confiar apenas na intenção do modelo, o aplicativo pode impor regra: certos comandos precisam de confirmação, outros rodam apenas em sandbox, e alguns nunca saem do conjunto aprovado.
Um exemplo de política de execução
Se o agente recebe permissão para editar código, mas não para executar comandos fora do sandbox, ele continua produtivo sem virar caixa-preta operacional. A mesma lógica vale para ambientes internos de empresas brasileiras que lidam com dados pessoais, contratos ou bases financeiras sob LGPD: a política de ferramenta precisa ser tão explícita quanto a política de acesso ao dado.
Esta seção descreve a versão atual do Claude Agent SDK e de suas APIs públicas. Ferramentas de IA mudam rápido — confira o changelog e a documentação oficial antes de adotar em produção.
Hooks, subagentes e MCP
Outro ponto importante no desenho da Anthropic é que o agente não vive isolado. A documentação do SDK menciona hooks, que permitem interceptar pontos do ciclo antes do uso de ferramenta, e também a integração com MCP, útil para conectar recursos externos de maneira padronizada.
Na prática, hooks funcionam como pontos de observação e controle. Você pode registrar métricas, impor regras de negócio ou bloquear ações em momentos específicos do loop. Já MCP ajuda a reduzir a fragmentação de integrações, algo valioso quando o agente precisa falar com múltiplos sistemas internos sem virar um emaranhado de conectores sob medida.
Subagentes para divisão de trabalho
O suporte a subagentes reforça a ideia de especialização. Em vez de um agente tentar resolver tudo, você divide responsabilidades: um subagente pesquisa, outro resume, outro valida. Essa divisão costuma melhorar manutenção, porque cada parte ganha escopo menor e ferramentas mais previsíveis.
Essa estratégia também conversa bem com squads brasileiras que já trabalham com fronteiras claras entre produto, dados e infraestrutura. Quando o agente segue a mesma estrutura do time, a adoção fica menos abstrata e mais próxima dos handoffs que já existem no dia a dia.
Tool search e programmatic tool calling
No texto de engenharia da Anthropic sobre advanced tool use, dois padrões se destacam: Tool Search e Programmatic Tool Calling. O primeiro ajuda o modelo a encontrar a ferramenta certa sem entupir o contexto com catálogo inteiro; o segundo permite que o agente escreva/execute código para chamar ferramentas e só traga de volta o que importa.
Essas ideias atacam um problema bem concreto: contexto é finito e caro. Quanto mais ferramentas você coloca na conversa, maior o risco de confundir seleção, inflar tokens e perder precisão. Buscar e chamar sob demanda mantém o fluxo mais enxuto.
Por que isso importa para pipelines reais
Em automações com muitos sistemas, a diferença entre “listar tudo” e “descobrir sob demanda” é grande. Um agente que decide entre dezenas de ferramentas precisa de menos ruído e mais estrutura. O Tool Search reduz a necessidade de stuffing; o Programmatic Tool Calling desloca parte da complexidade para uma execução mais controlada.
Para times que fazem integrações com ERPs, CRMs, bases analíticas e mensageria, isso significa menos contexto desperdiçado em catálogo e mais atenção ao objetivo da tarefa. É um detalhe arquitetural, mas muda custo e confiabilidade.
Como isso se aplica na prática
Se eu tivesse que resumir o valor do Claude Agent SDK em uma frase, seria esta: ele trata o agente como um runtime governado. Você não está só enviando prompts para um modelo; está configurando capacidades, limites e pontos de interceptação para que o sistema opere com previsibilidade.
Isso combina muito bem com fluxos típicos de engenharia de software. Por exemplo: ler um repositório, propor correção, abrir edição, validar em sandbox e submeter a revisão humana. O SDK empacota essa sequência em uma camada mais próxima de produto do que de experimento.
Onde o dev brasileiro sente o ganho
No contexto brasileiro, há um motivo extra para isso importar: muitas empresas ainda operam com times enxutos, orçamentos em BRL e exigências de conformidade ligadas à LGPD. Isso pede automação com trilha de auditoria, escopos claros e menos improviso operacional. Um agente com `permission_mode`, sandbox e hooks conversa melhor com essa realidade do que uma automação solta.
Além disso, em boa parte dos produtos SaaS no Brasil, a operação roda em regiões fora do país e a equipe precisa provar controle sobre acesso, edição e execuções. Quando a latência, o custo e a auditoria entram na conta, o desenho do agente deixa de ser só uma questão de produtividade e vira decisão de arquitetura.
O que observar antes de adotar
Ainda que o SDK simplifique bastante o lado da orquestração, ele não elimina o trabalho de design. Você ainda precisa responder perguntas como: quais ferramentas entram em `allowed_tools`, quais ações pedem aprovação, o que fica em sandbox e como registrar decisão do agente.
Também vale tratar versionamento como parte do projeto. APIs de agente mudam rápido, e a combinação de hooks, permissões e ferramentas embutidas pode evoluir com frequência. O caminho seguro é começar pequeno, validar em uma tarefa real e só depois ampliar o escopo.
Critérios práticos para um piloto
- Escolha uma tarefa repetitiva e bem delimitada.
- Limite o agente a poucas ferramentas no início.
- Ative sandbox e revisão manual para comandos sensíveis.
- Registre cada uso de ferramenta e cada decisão de permissão.
- Meça tempo economizado, taxa de retrabalho e falhas de execução.
Conclusão
O Claude Agent SDK sinaliza uma virada importante no modo de construir agentes: menos loop manual no cliente e mais controle declarativo sobre capacidade, segurança e observabilidade. Na prática, isso ajuda a transformar tool use em componente de produção, e não apenas em demo de laboratório.
Para começar em menos de 1 hora, abra a quickstart oficial, copie o exemplo com `allowed_tools` e `permission_mode`, e adapte para uma tarefa pequena do seu projeto — por exemplo, leitura de arquivos ou revisão assistida em um repositório interno.
Conteúdos da DIO para quem quer aprofundar
- CI&T - Do Prompt ao Agente — trilha para sair do básico de IA e aprender a aplicar agentes em tarefas reais do dia a dia de desenvolvimento.
- Aceleração Microsoft - Azure AI Agents — mentorias e prática para criar, orquestrar e governar agentes em um contexto enterprise.
- Aceleração: AI Reports com Excel, GPT Agents e Claude Code — conteúdo focado em construir agentes de IA para análise e apresentação de dados com Excel e Claude Code.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
