A capacidade de um agente invocar ferramentas externas é o que transforma um modelo de linguagem de um gerador de texto em algo que opera sobre o mundo. Pra mim, essa transição do raciocínio pra ação é também o ponto onde a maioria dos sistemas agênticos falha de formas que não aparecem em demo. O modelo decide que precisa buscar dados ou chamar uma API. A decisão pode estar correta. Os parâmetros que ele monta pra chamada podem não estar. E o que acontece entre a intenção do modelo e a execução real da ferramenta é onde os patterns de design precisam existir, porque é ali que a previsibilidade se perde.
O pattern que separa sistemas de produção de protótipos é o contrato explícito entre agente e ferramenta. Em um protótipo, a descrição da tool é uma string vaga, os parâmetros são flexíveis, e o modelo improvisa o preenchimento com base no contexto da conversa. Em produção, cada ferramenta precisa de um JSON schema rigoroso com tipos explícitos e campos obrigatórios marcados como required, além de descrições que não deixem espaço pra interpretação criativa do modelo. A Anthropic e a OpenAI oferecem modos de strict tool use que forçam o modelo a gerar chamadas que respeitam o schema exatamente como definido, usando constrained sampling durante a geração. Na minha avaliação, o efeito prático é a eliminação de uma classe inteira de falhas que vão de parâmetros com tipo errado a campos opcionais preenchidos com valores inventados ou nomes de ferramentas alucinados.
Além do schema, existe a validação semântica. O schema garante que a chamada está bem formada, mas não garante que faz sentido. Um agente que recebe a tarefa de buscar dados de um usuário e monta uma query com um ID que não existe no sistema produziu uma chamada estruturalmente correta e operacionalmente inútil. A validação semântica opera na camada entre a geração da tool call e sua execução, e verifica se os parâmetros referenciam entidades válidas e se os valores estão dentro de faixas aceitáveis antes de qualquer execução. Essa camada é código determinístico, porque o modelo não valida a si mesmo. Um estudo de novembro de 2025 sobre tool-induced reasoning hallucinations (arXiv:2511.10899) descreve o fenômeno de tool-induced myopia, em que modelos com raciocínio mais forte tendem a substituir raciocínio interno por chamadas de ferramentas de forma sistemática, abrindo mão da inferência que fariam se a ferramenta não existisse. A defesa contra isso está na camada de validação que intercepta a chamada antes da execução.
Pra mim, o isolamento de efeitos colaterais por nível de risco é o pattern seguinte, e possivelmente o mais negligenciado. Uma chamada de leitura que retorna dados incorretos causa retrabalho. Uma chamada de escrita que modifica estado causa dano. Uma chamada que dispara uma transação financeira ou envia uma comunicação a um usuário causa dano irreversível. O pattern que funciona em produção classifica ferramentas em níveis de risco e aplica controles proporcionais. Ferramentas de leitura executam diretamente. Ferramentas de escrita passam por confirmação programática com verificação de pré-condições. Ferramentas de alto risco exigem aprovação humana ou operam em modo dry-run antes da execução real. O custo é a latência adicional nos níveis mais altos. O benefício é que o agente pode operar com autonomia nos níveis baixos sem que um erro nos níveis altos vire um incidente.
Um agente com acesso a dez ferramentas e sem restrição de uso tende a invocar ferramentas em excesso, especialmente em chains multi-step. Na minha análise, o custo acumulado vai além dos tokens consumidos pelas descrições de ferramentas no contexto, que já podem ser substanciais quando o agente tem acesso a dezenas de tools via MCP. A qualidade da decisão se degrada à medida que o contexto acumula resultados intermediários. Um orçamento explícito de ferramentas por execução, com limite máximo de invocações, força o agente a priorizar quais ferramentas usar e em que ordem, e cria um mecanismo de interrupção quando o agente entra em loop de tentativa-e-erro.
Quando uma ferramenta falha, o padrão mais comum é retornar a exceção ao modelo como texto e esperar que ele se adapte. Pra mim, uma estrutura tipada com categoria do erro, mensagem legível e um campo que indica se o erro é retentável ou terminal produz resultados melhores. O modelo opera de forma mais previsível sobre erros estruturados do que sobre stack traces, porque a estrutura reduz o espaço de interpretação. O campo de retentabilidade evita que o agente gaste tentativas em erros que não vão mudar com retry, como permissões insuficientes, e ao mesmo tempo permite retry em erros transientes como timeouts ou rate limits.
O que conecta esses patterns é que a confiabilidade do tool use é propriedade da interface entre o modelo e o mundo. O modelo decide. A interface intercepta a chamada antes da execução, valida os parâmetros, e classifica o nível de risco antes de deixar passar. Na minha avaliação, à medida que essa interface se fortalece, até modelos menos capazes operam de forma previsível dentro dos limites impostos, porque a estrutura da camada de validação compensa a tendência do modelo a confabular sobre quais ferramentas usar e como. O investimento de engenharia em tool use confiável está no código que decide se a chamada do modelo merece ser executada.