Claude, tool use e a nova camada de agentes da Anthropic
TL;DR
A Anthropic ampliou o tool use do Claude de um modelo de chamada de funções para uma pilha mais agentic, com descoberta dinâmica de ferramentas, automação por interface e skills reutilizáveis. Na prática, isso abre espaço para fluxos em que o modelo escolhe, combina e executa ações com menos acoplamento ao código da aplicação.
Para quem constrói soluções no Brasil, o impacto aparece em integrações mais rápidas com sistemas legados, operações guiadas por interface e automações sensíveis a custo e latência, especialmente quando o time precisa entregar valor sem refatorar tudo de uma vez. O ponto central não é “um chatbot mais esperto”, e sim uma nova forma de desenhar software orientado a tarefas.
O que mudou no tool use do Claude
No release de tool use GA, a Anthropic tornou geral a capacidade do Claude de conectar ferramentas externas e executar tarefas em vez de só gerar texto, como descrito no anúncio oficial Claude can now use tools. Já o anúncio de advanced tool use adiciona uma camada em que o modelo pode descobrir, aprender e executar ferramentas dinamicamente, em vez de depender apenas de um conjunto fixo pré-configurado Introducing advanced tool use on the Claude Developer Platform.
Esse detalhe importa porque muda a responsabilidade da aplicação. Antes, o desenvolvedor precisava antecipar quase tudo no fluxo de chamada; agora, parte da seleção e encadeamento pode ser conduzida pelo próprio modelo, desde que a superfície de ferramentas esteja bem definida. Isso aproxima o Claude de um executor de tarefas e afasta a ideia de simples gerador de respostas.
Tool use GA: integração explícita com APIs
No nível mais direto, tool use significa conectar o Claude a ferramentas que fazem trabalho real: consultar um CRM, buscar um pedido, registrar uma ação ou transformar dados. O anúncio oficial da Anthropic trata isso como a base para o modelo manipular dados e performar tarefas por meio de ferramentas conectadas Claude can now use tools.
Para times de produto, isso costuma ser o ponto de entrada mais seguro. Você expõe funções com entradas e saídas bem definidas, mantém o controle do que pode ser chamado e mede o comportamento do agente em cenários previsíveis. Em aplicações corporativas, essa abordagem reduz o salto entre protótipo e integração real.
Advanced tool use: descoberta e execução dinâmica
A camada de advanced tool use amplia a autonomia do Claude ao permitir descoberta, aprendizagem e chamada programática de ferramentas, incluindo um fluxo em que o modelo pode usar code execution como ponte de orquestração Introducing advanced tool use on the Claude Developer Platform. Em vez de escolher manualmente cada ferramenta no código da aplicação, você passa a permitir que o agente selecione o caminho mais adequado dentro de um conjunto permitido.
Isso é especialmente útil quando o ambiente muda com frequência. Pense em catálogos grandes de APIs internas, integrações por área de negócio ou rotinas que variam conforme o contexto do usuário. O ganho vem da redução de lógica rígida de roteamento e da possibilidade de o agente adaptar o encadeamento sem reescrever a aplicação a cada novo caso.
Computer use: ação no desktop via visão
O tool de computer use leva a automação para a interface gráfica: o Claude recebe screenshot e controla mouse e teclado para executar ações em ambientes desktop, conforme a documentação oficial Computer use tool. O post oficial que apresentou a abordagem também deixa claro que essa modalidade tem limites e exige cuidado com o ambiente de execução Developing a computer use model.
Na prática, isso abre caminho para operações em sistemas sem API madura, legado web ou ferramentas internas difíceis de integrar de outra forma. Em vez de esperar uma refatoração completa, o time pode automatizar tarefas usando a própria interface já existente. É uma alternativa pragmática para cenários em que o custo de integração tradicional seria alto demais.
Agent Skills: workflows empacotados e reutilizáveis
O repositório oficial de exemplo da Anthropic mostra Agent Skills como pastas com um arquivo `SKILL.md`, carregadas dinamicamente para tarefas especializadas anthropics/skills. A ideia é modularizar conhecimento operacional, para que o agente recupere instruções e rotinas específicas quando precisa executar uma tarefa recorrente.
Isso é interessante porque aproxima o design de agentes de algo que times de engenharia já conhecem: bibliotecas, módulos e componentes reutilizáveis. Em vez de um monólito de prompt, você tem capacidades separadas por domínio, com melhor manutenção e menor chance de acoplar toda a lógica em um único texto gigante.
Como isso aparece em uma arquitetura real
O desenho mais comum para usar essas capacidades combina três camadas. A primeira é a camada de ferramentas explícitas, com funções bem definidas e limites claros. A segunda é a camada de agentes, onde o Claude escolhe quando chamar uma ferramenta, quando encadear passos e quando recorrer a execução programática. A terceira é a camada de apoio, com skills e rotinas que condensam tarefas repetíveis.
Esse arranjo reduz a dependência de pseudo-orquestração espalhada pela aplicação. Em vez de transformar todo fluxo em uma sequência de condicionais no backend, você centraliza as capacidades no contrato do agente e usa logging, auditoria e avaliação para observar o comportamento. Isso é particularmente útil quando o produto precisa escalar de um caso simples para dezenas de variações operacionais.
Esta seção descreve a família de capacidades recentes de tool use do Claude. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Exemplo prático de integração
Se você pensar em uma operação como “buscar um cliente, verificar status, gerar uma resposta e abrir um chamado se houver falha”, o tool use permite modelar cada ação como ferramenta. O Claude pode decidir quais chamadas fazer, em que ordem e com qual contexto, desde que as entradas estejam bem descritas e o ambiente imponha permissões claras Claude can now use tools.
Para quem trabalha com integrações corporativas, o valor está em separar intenção de execução. O usuário pede algo em linguagem natural, mas o sistema converte isso em operações auditáveis, com cada etapa registrada. Essa separação ajuda tanto na confiabilidade quanto na observabilidade do fluxo.
Em uso real, eu começaria pequeno: uma ferramenta de consulta, uma de escrita e uma regra de fallback humana. Depois, com métricas de acerto e erros de roteamento, faria a expansão para discovery dinâmico e skills. Esse caminho diminui o risco de colocar autonomia demais cedo demais.
Por que isso importa pro dev brasileiro
No Brasil, o impacto não é só técnico; ele é econômico e operacional. Muitas empresas ainda têm sistemas legados, integrações improvisadas e uma pressão constante por redução de custo em BRL, enquanto parte da infraestrutura roda em regiões como us-east-1 por padrão de mercado. Nesse cenário, um agente que consegue operar sobre APIs, interfaces e workflows empacotados pode entregar automação sem exigir um projeto grande de substituição de sistema.
Há também um ponto relevante de compliance. Quando o fluxo lida com dados pessoais, a LGPD exige cuidado com base legal, minimização e tratamento adequado. Isso favorece arquiteturas em que o agente tem acesso restrito a ferramentas específicas, em vez de liberdade total sobre dados sensíveis. Em outras palavras: tool use bem desenhado ajuda a automatizar sem transformar o modelo em um ponto cego de governança.
Outro aspecto é o perfil do time. No ecossistema brasileiro, muitos devs entram em IA por bootcamps, estudo autodidata e aplicação direta em produto, sem uma equipe grande de pesquisa por trás. Capacidades modulares como skills e tools encaixam bem nesse contexto porque permitem evoluir por etapas: primeiro uma integração útil, depois automação guiada, depois orquestração mais sofisticada.
Limites e cuidados
Mais autonomia não significa mais confiabilidade por padrão. Tool use, discovery dinâmica e computer use ainda dependem de contratos claros, monitoramento e testes em cenários reais. A própria documentação da Anthropic trata computer use como algo que precisa de atenção ao ambiente, porque a interação por interface é mais frágil do que uma chamada de API bem tipada Computer use tool.
Outro cuidado é evitar enxergar skills como substituto de arquitetura. Elas ajudam a modularizar capacidades, mas não eliminam o trabalho de versionamento, observabilidade e segurança. Se uma skill passa a encapsular uma rotina crítica, ela precisa do mesmo nível de revisão que qualquer outro componente operacional.
Conclusão
O movimento recente da Anthropic mostra que tool use virou uma base de agentes, não um detalhe de implementação. Primeiro veio a conexão a ferramentas; depois, a descoberta dinâmica; depois, a automação por interface; e, por fim, o empacotamento modular com skills. Para quem constrói software, isso significa menos foco em “prompt mágico” e mais foco em contratos, permissões e composição de capacidades.
Se você quiser validar essa mudança na prática, abra a documentação oficial de computer use, crie uma ferramenta simples de leitura no seu backend e implemente um fluxo de teste com logs de cada chamada. Em até uma hora, você consegue montar um protótipo pequeno e enxergar onde o agente ajuda e onde ainda precisa de controle humano.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
