Chamadas Avançadas de Ferramentas Que Reduziram os Custos do Meu Agente de IA pela Metade

Eu estava olhando meu dashboard do Langfuse às 23h de uma quinta-feira quando notei algo que me fez fechar meu laptop e me afastar da mesa. Uma única execução de agente -- uma tarefa, uma consulta de usuário -- havia queimado 76.000 tokens e feito 56 chamadas separadas de ferramentas. A pior parte? Ainda assim errou a resposta. Perdeu dois membros da equipe que tinham excedido seus limites de orçamento, e o cliente ia ver aquele relatório pela manhã.

Esse agente tinha acesso a 60 ferramentas em dois servidores MCP. Cada uma dessas definições de ferramentas era carregada na janela de contexto no início de cada conversa. Treze mil tokens desaparecidos antes do agente sequer começar a pensar na tarefa real. Eu tinha construído o que pensei ser um sistema capaz. O que eu realmente tinha construído era uma fornalha de tokens com um problema de precisão.

A solução veio de dois recursos que eu estava ignorando na documentação da Anthropic há semanas: busca de ferramentas e chamadas programáticas de ferramentas. O que aconteceu depois que os implementei é a razão pela qual estou escrevendo este post. Mas a verdadeira história não é sobre economizar tokens -- é sobre uma mudança fundamental em como penso sobre arquitetura de agentes.

O Problema do Qual Ninguém Fala Até a Conta Chegar

Aqui está o cenário que a maioria dos desenvolvedores de agentes de IA conhece intimamente, admitam ou não. Você começa a construir um agente. Ele precisa ler arquivos, consultar bancos de dados, chamar APIs, talvez interagir com GitHub ou Slack. Cada capacidade significa outra ferramenta. Seu primeiro protótipo tem 8 ferramentas e funciona lindamente. Contexto limpo, respostas rápidas, resultados precisos.

Aí chegam as solicitações de funcionalidades. O agente precisa lidar com agendamento de calendário. Adicione três ferramentas. Precisa criar tickets no Jira. Mais duas ferramentas. Integração com Slack? Mais cinco. Antes de perceber, você está em 35, 40, 60 ferramentas -- e seu agente desenvolveu um transtorno de personalidade. Escolhe a ferramenta errada metade do tempo, alucina valores de parâmetros e custa três vezes o que você orçou.

Bati nessa parede com força em um projeto para um cliente que queria um agente de operações unificado. O agente precisava de acesso aos repos do GitHub, workspace do Notion, canais do Slack, calendário e uma API de inventário customizada. Sessenta ferramentas no total quando você contava tudo dos dois servidores MCP.

Três coisas estavam me matando:

Só as definições de ferramentas consumiam aproximadamente 13.000 tokens por conversa. Isso é espaço de janela de contexto que poderia ter sido usado para raciocínio real. No Claude 3.5 Sonnet, isso não é trivial -- e em conversas mais longas, eu estava raspando nos limites de contexto antes do agente terminar seu trabalho.

As saídas intermediárias das chamadas sequenciais de ferramentas estavam poluindo o contexto. Quando o agente precisava verificar orçamentos de uma equipe, ele chamava "obter membros da equipe", depois chamava "obter despesas" para cada pessoa, depois chamava "obter orçamento por nível" para o cargo de cada pessoa. Cada resposta despejava JSON cru no contexto. Quando chegava ao último membro da equipe, os dados anteriores estavam sendo empurrados para fora da faixa de atenção efetiva.

A precisão na seleção de ferramentas se degradava à medida que a contagem de ferramentas subia. Com 60 definições de ferramentas no contexto, o modelo tinha que analisar todas elas cada vez que decidia qual ferramenta usar. Imagine dar a alguém um cardápio de 60 páginas em um restaurante e esperar que peça rápida e corretamente. Mesmo problema.

Tentei as soluções óbvias. Melhores descrições de ferramentas. Menos ferramentas com mais parâmetros. Categorizar ferramentas em grupos. Nenhuma resolveu o problema fundamental: definições demais carregando cedo demais, e dados intermediários demais se acumulando rápido demais.

Então encontrei os dois recursos que mudaram tudo sobre como construo agentes.

Busca de Ferramentas: Carregando o Que Você Precisa, Quando Precisa

O conceito por trás da busca de ferramentas é tão simples que é quase ofensivo que eu não tenha pensado nisso sozinho. Em vez de carregar todas as 60 definições de ferramentas no contexto no início, você adia a maioria. O agente recebe um pequeno conjunto de ferramentas essenciais mais uma ferramenta especial: a própria ferramenta de busca de ferramentas. Quando o agente precisa de uma capacidade que não tem atualmente, ele busca a ferramenta certa por palavra-chave ou nome, carrega apenas o esquema dessa ferramenta e prossegue.

A matemática é convincente. Minha configuração de 60 ferramentas consumia cerca de 13.000 tokens em definições de ferramentas. Depois de implementar a busca de ferramentas e carregar apenas 12 ferramentas essenciais antecipadamente, esse número caiu para 6.300 tokens. Quase metade da sobrecarga de definições, eliminada.

Mas a economia de tokens nem foi a melhoria mais importante. A precisão na seleção de ferramentas subiu dramaticamente. Quando o agente tem apenas 12 ferramentas no contexto em vez de 60, ele escolhe a certa mais consistentemente. É a mesma razão pela qual um artesão focado com 5 ferramentas na bancada trabalha mais precisamente do que um cercado por 50 -- menos ruído, melhor sinal.

Veja como o fluxo de trabalho funciona na prática. Digamos que o agente precise listar commits recentes de um repositório GitHub. Com a abordagem tradicional, as ferramentas do GitHub MCP já estão carregadas -- todas as 35, consumindo cerca de 26.000 tokens (embora versões mais novas do MCP tenham reduzido isso para cerca de 4.000 tokens, o que é uma melhoria massiva da qual falarei depois). O agente tem que escanear cada uma para encontrar a ferramenta certa, depois descobrir os parâmetros corretos.

Com busca de ferramentas, essas ferramentas do GitHub não estão carregadas de jeito nenhum. O agente reconhece que precisa de dados de commits, chama a ferramenta de busca com uma consulta como "list commits", recebe de volta a ferramenta específica que precisa e carrega apenas esse esquema. Uma ferramenta. Algumas centenas de tokens. E uma vez que essa ferramenta está carregada, ela permanece no contexto para quaisquer chamadas subsequentes -- sem carregamentos repetidos, sem tokens desperdiçados.

Quero ser específico sobre como isso funciona porque os detalhes de implementação importam. A ferramenta de busca aceita uma consulta por palavra-chave ou um nome direto de ferramenta. A busca por palavra-chave é difusa -- você pode buscar "slack message" e ela retornará ferramentas relevantes do Slack classificadas por relevância. A seleção direta usa um prefixo "select:" quando você sabe exatamente qual ferramenta quer. Ambas as abordagens carregam as ferramentas retornadas imediatamente, então não há um processo de duas etapas de buscar e depois carregar separadamente.

Uma coisa que aprendi da pior maneira: você precisa pensar cuidadosamente sobre quais ferramentas ficam no conjunto "sempre carregado" versus quais são adiadas. Ferramentas que o agente usa em quase toda conversa devem ficar carregadas. Ferramentas que só são necessárias para tarefas específicas devem ser adiadas. Errar nessa divisão significa que seu agente perde tempo buscando ferramentas comuns ou ainda carrega definições demais antecipadamente.

Para meu agente de operações, mantive ferramentas core como leitura de arquivos, chamadas básicas de API e a própria ferramenta de busca no conjunto sempre carregado. Todo o resto -- operações do GitHub, mensagens do Slack, gerenciamento de calendário, consultas do Notion -- foi adiado. O agente aprendeu a buscá-las naturalmente, e o fluxo da conversa mal mudou da perspectiva do usuário.

Isso resolveu o problema de inchaço de definições. Mas eu ainda tinha o problema de saída intermediária -- todo aquele JSON cru de chamadas sequenciais de ferramentas se acumulando no contexto. Para isso, eu precisava do segundo recurso.

Chamadas Programáticas de Ferramentas: Escreva Código, Não Cadeias de Chamadas

É aqui que as coisas ficam genuinamente interessantes e, honestamente, um pouco alucinantes se você vem construindo agentes da maneira tradicional.

A chamada padrão de ferramentas funciona assim: o LLM decide que precisa de dados, faz uma chamada de ferramenta, recebe o resultado, processa, decide que precisa de mais dados, faz outra chamada de ferramenta, recebe aquele resultado, e assim por diante. Cada chamada e cada resposta vive no contexto da conversa. Para tarefas simples com duas ou três chamadas, está tudo bem. Para tarefas complexas que requerem dados de dezenas de fontes, é um desastre.

As chamadas programáticas de ferramentas invertem o modelo. Em vez de fazer chamadas individuais de ferramentas pela conversa, o agente gera um script de código -- Python, tipicamente -- que lida com todo o fluxo de trabalho programaticamente. O script roda em um ambiente sandboxed, faz todas as chamadas necessárias de ferramentas internamente, processa os dados com lógica de código real e retorna apenas o resultado final ao contexto da conversa.

Deixe-me mostrar a diferença com um exemplo concreto que realmente aconteceu no meu projeto de conformidade orçamentária.

A tarefa era direta: verificar se as despesas de algum membro da equipe excediam seu orçamento autorizado para seu nível de cargo. Três ferramentas estavam disponíveis: obter membros da equipe (retorna uma lista de pessoas e seus cargos), obter despesas (retorna dados de gastos para uma pessoa específica) e obter orçamento por nível (retorna o teto de orçamento autorizado para um cargo).

Com a chamada tradicional de ferramentas, o agente chamou "obter membros da equipe" primeiro. Recebeu uma lista de, digamos, 15 pessoas. Depois chamou "obter despesas" para a pessoa um. Recebeu seus dados de gastos. Chamou "obter orçamento por nível" para o cargo da pessoa um. Comparou os números. Passou para a pessoa dois. Chamou "obter despesas". Chamou "obter orçamento por nível". E assim por diante. Cinquenta e seis chamadas de ferramentas no total. Cada resposta -- 15 registros de membros da equipe, 15 relatórios de despesas, 15 consultas de orçamento -- ficou no contexto da conversa, consumindo tokens.

O resultado? Aproximadamente 76.000 tokens consumidos. E o agente perdeu um membro da equipe que tinha excedido seu orçamento, provavelmente porque quando processou as últimas pessoas, a atenção aos dados anteriores tinha se degradado. A atenção da janela de contexto não é uniforme -- modelos prestam menos atenção à informação no meio de contextos longos, e minhas chamadas sequenciais de ferramentas tinham criado exatamente as condições onde essa fraqueza morderia.

Com chamadas programáticas de ferramentas, a mesma tarefa parecia completamente diferente. O agente analisou o que precisava realizar, depois gerou um script Python. O script chamou "obter membros da equipe" uma vez, iterou pela lista programaticamente, chamou "obter despesas" e "obter orçamento por nível" para cada pessoa dentro de um loop, comparou os valores em código e retornou um resumo limpo de quem excedeu seu orçamento e por quanto.

Os números contam a história. O uso de tokens caiu para algo entre 45.000 e 58.000 tokens em múltiplas execuções. As chamadas de ferramentas foram de 56 para entre 4 e 12. E a precisão? Perfeita. O código não tinha problemas de degradação de atenção. Um loop for processa o décimo quinto item exatamente tão bem quanto o primeiro.

Devo ser honesto sobre algo, porém. A abordagem programática não foi perfeita de primeira toda vez. Nas minhas execuções de teste, o agente às vezes gerava código que tinha bugs na primeira tentativa. Um nome de variável errado, uma verificação de null faltando, uma suposição incorreta de estrutura de dados. O sandbox retornava um erro, e o agente analisava o erro, corrigia o código e tentava novamente. Esse ciclo iterativo faz parte do design, não é um defeito. O desenvolvimento real de software funciona exatamente assim -- escreva, execute, depure, refine.

Algumas execuções levaram duas iterações, algumas levaram quatro. Mas mesmo com a sobrecarga de iteração, o uso total de tokens e as chamadas de ferramentas foram substancialmente menores que a abordagem tradicional. E a precisão foi consistentemente melhor porque a lógica de comparação vivia em código real em vez de na memória de trabalho do LLM.

Essa natureza iterativa é realmente uma das coisas que mais aprecio nesta abordagem. Espelha como eu trabalho como desenvolvedor. Não escrevo código perfeito na primeira tentativa. Escrevo algo razoável, testo, conserto o que quebra e itero. As chamadas programáticas de ferramentas dão ao agente o mesmo fluxo de trabalho, e acontece que LLMs são surpreendentemente bons em depurar seu próprio código gerado quando recebem mensagens de erro claras do sandbox.

A Arquitetura de Sandbox Que Torna Isso Seguro

Agora, se você acabou de ler aquela seção e seus instintos de segurança se ativaram, ótimo. Deixar um agente de IA gerar e executar código arbitrário é o tipo de coisa que mantém engenheiros de segurança acordados à noite. A arquitetura por trás desse recurso é o que o torna viável para uso em produção, e entendê-la é essencial antes de implementar qualquer coisa.

O sistema usa contêineres Docker sandboxed. Cada execução de código roda dentro de um contêiner isolado sem acesso à internet. O script Python gerado não pode alcançar o mundo exterior, não pode acessar o sistema de arquivos do host, não pode ler variáveis de ambiente do host e não pode fazer nada que um script malicioso gostaria de fazer.

Mas espere -- o script precisa chamar ferramentas. Precisa acessar APIs. Como faz isso sem acesso à internet?

É aqui que entra a ponte de ferramentas, e é uma peça de arquitetura inteligente. O sandbox tem acesso a um único endpoint: o servidor ponte de ferramentas rodando no host (ou em um contêiner sidecar). Quando o script Python dentro do sandbox precisa chamar uma ferramenta -- digamos, "obter despesas" de um membro da equipe -- ele faz uma requisição à ponte de ferramentas. A ponte autentica a requisição usando um ID de sessão, verifica se a chamada de ferramenta é permitida, executa a chamada real à API em nome do sandbox e retorna o resultado.

A propriedade de segurança crítica aqui é que o código do sandbox nunca vê credenciais de API, tokens ou segredos. A ponte de ferramentas mantém todo o material de autenticação. O sandbox só conhece o endpoint da ponte e seu ID de sessão. Se o código gerado fosse de alguma forma malicioso ou vazasse, nenhuma credencial ficaria exposta.

Configurei meu sandbox usando o repositório GitHub LLM sandbox, que abstrai a maior parte da complexidade de gerenciamento do Docker. Suporta Python nativamente e lida com o ciclo de vida do contêiner, captura de saída e limpeza. Para equipes rodando isso em produção, recomendo fortemente adicionar o GVisor sobre o isolamento padrão do Docker. Contêineres Docker compartilham o kernel do host, o que significa que um exploit de kernel poderia teoricamente escapar do sandbox. O GVisor fornece uma camada adicional de isolamento interceptando chamadas de sistema através de seu próprio kernel em espaço de usuário, reduzindo significativamente essa superfície de ataque.

Uma coisa que não apreciei até construir: a abordagem de sandbox é agnóstica à linguagem em princípio. O repo LLM sandbox suporta múltiplas linguagens, então você poderia fazer seu agente gerar JavaScript, Go ou até shell scripts dependendo da tarefa. Na prática, fiquei com Python porque LLMs geram o melhor código Python -- viram a maior quantidade de dados de treinamento em Python, e a sintaxe do Python torna mais fácil para o modelo expressar lógica procedural.

Projetando Ferramentas Que Não Desperdiçam Seu Orçamento de Contexto

A busca de ferramentas e as chamadas programáticas resolvem dois problemas principais: inchaço de definições e inchaço de saídas intermediárias. Mas há uma terceira camada de otimização que quase passei batido, e fez uma diferença maior do que eu esperava: o design das ferramentas em si.

Quando conectei pela primeira vez o servidor MCP do GitHub ao meu agente, o conjunto completo de 35 ferramentas consumia cerca de 26.000 tokens em definições. Isso é absurdo. A versão mais nova do mesmo servidor MCP entrega funcionalidade equivalente em aproximadamente 4.000 tokens. A diferença? Descrições mais enxutas, parâmetros consolidados e remoção de variantes redundantes de ferramentas.

Se você está construindo ferramentas customizadas para seus agentes, cada token na definição da sua ferramenta conta. Reduza as descrições à informação essencial. Use nomes de parâmetros claros e concisos dos quais o modelo possa inferir o uso. Remova campos que o agente raramente usa -- você sempre pode adicioná-los de volta com busca de ferramentas se necessário.

E aqui vai uma dica que melhorou dramaticamente a precisão do meu agente com manuseio de parâmetros: inclua exemplos de uso de ferramentas. Fornecer um único exemplo de uso correto de ferramenta -- mostrando os valores esperados para cada parâmetro -- elevou minha precisão de parâmetros de aproximadamente 72% para cerca de 90%. Isso não é uma melhoria menor. É a diferença entre um agente que na maioria das vezes funciona e um que funciona de forma confiável.

Pense nos exemplos de uso de ferramentas como prompting multi-shot para chamadas de ferramentas. Quando o modelo vê um exemplo como {"date": "2026-01-15"}, ele entende que o formato esperado é ano-mês-dia. Sem esse exemplo, ele poderia gerar "January 15, 2026" ou "01/15/2026" ou "15-01-2026" -- todas representações válidas de data, mas apenas uma corresponde ao que a API espera. Um único exemplo elimina essa ambiguidade quase completamente.

Agora trato a otimização de definições de ferramentas como uma tarefa de engenharia de primeira classe, não como uma reflexão tardia. Antes de adicionar qualquer ferramenta a um agente, pergunto: Quantos tokens essa definição consome? Posso tornar a descrição mais curta sem perder clareza? Incluí um exemplo de uso? Essa ferramenta pode ser adiada atrás da busca, ou precisa estar sempre carregada?

Essas perguntas economizam milhares de tokens por conversa, o que se compõe em dinheiro real ao longo de milhares de execuções de agentes.

Unindo Tudo: A Arquitetura Que Realmente Vai para Produção

Aqui é onde amarro os fios, porque esses recursos não são interruptores independentes que você liga. Funcionam melhor como camadas em uma arquitetura deliberada.

Camada 1: Busca de ferramentas para gerenciamento de definições. Adie tudo que não é necessário em toda conversa. Mantenha seu conjunto sempre carregado pequeno e focado. Deixe o agente descobrir ferramentas especializadas sob demanda. Isso lida com o inchaço de definições.

Camada 2: Chamadas programáticas de ferramentas para fluxos de trabalho complexos. Qualquer tarefa que requer iterar sobre dados, comparar valores de múltiplas fontes ou fazer mais de cinco chamadas sequenciais de ferramentas é candidata para execução programática. Envie esses fluxos de trabalho para o sandbox. Isso lida com o inchaço de saídas intermediárias e melhora a precisão para tarefas pesadas em dados.

Camada 3: Exemplos de uso de ferramentas para precisão de parâmetros. Toda ferramenta que aceita formatos de parâmetros não óbvios -- datas, enums, IDs, objetos aninhados -- recebe pelo menos um exemplo de uso na sua definição. Isso lida com o assassino silencioso de precisão que a maioria dos desenvolvedores nem mede.

Quando apliquei as três camadas ao meu agente de operações, os resultados foram contundentes. Conversas que costumavam consumir mais de 80.000 tokens caíram para a faixa de 35.000-50.000. Contagens de chamadas de ferramentas para tarefas complexas foram de 40-60 para 5-15. Erros de parâmetros essencialmente desapareceram. E o agente começou a lidar com tarefas corretamente na primeira tentativa que antes precisavam de intervenção humana para completar.

Mas quero ser claro sobre algo: isso não é de graça. Implementar busca de ferramentas requer repensar sua organização de ferramentas e decidir o que adiar. Chamadas programáticas requerem configurar e manter uma infraestrutura de sandbox. Exemplos de uso de ferramentas requerem testes para encontrar os exemplos certos que realmente melhoram a precisão. Cada camada adiciona complexidade de implementação.

Minha recomendação é adicioná-las incrementalmente. Comece com busca de ferramentas se você tem mais de 15-20 ferramentas. Adicione chamadas programáticas quando identificar fluxos de trabalho específicos onde chamadas sequenciais de ferramentas estão causando problemas de precisão ou custo. Adicione exemplos de uso a qualquer ferramenta onde você está vendo erros de parâmetros nos seus logs.

O Que Errei e o Que Faria Diferente

Quero compartilhar três erros que cometi durante essa transição porque acho que são erros que a maioria vai cometer.

Primeiro, adiei agressivamente demais com busca de ferramentas. Movi quase tudo para trás da busca, incluindo ferramentas que o agente usava em 80% das conversas. O resultado foi que a maioria das conversas começava com o agente imediatamente buscando ferramentas que quase sempre precisava. Ainda funcionava, mas o passo de busca adicionava latência e uma pequena quantidade de tokens. Tive que ajustar o conjunto sempre carregado ao longo de cerca de duas semanas monitorando padrões reais de uso para encontrar o ponto ideal.

Segundo, assumi que chamadas programáticas sempre seriam mais baratas. Para tarefas simples com duas ou três chamadas de ferramentas, a sobrecarga de gerar código, levantar um sandbox e executar o script na verdade custa mais do que simplesmente fazer as chamadas diretamente. Chamadas programáticas brilham quando a abordagem tradicional requereria mais de aproximadamente cinco chamadas sequenciais. Abaixo desse limiar, o método tradicional é mais simples e frequentemente mais barato.

Terceiro, subestimei quanto tempo passaria escrevendo bons exemplos de uso de ferramentas. Um exemplo ruim é pior que nenhum exemplo porque pode enganar o modelo. Eu tinha uma ferramenta onde forneci um exemplo com uma data no formato "2025-12-01", mas a API na verdade esperava timestamps Unix. O modelo seguiu fielmente meu exemplo e enviou datas formatadas, que a API rejeitava toda vez. Testar seus exemplos contra a API real é inegociável.

Há também uma lição arquitetônica mais ampla que ainda estou processando. Esses recursos me empurraram a pensar em agentes menos como chatbots que por acaso usam ferramentas e mais como sistemas de orquestração que por acaso usam LLMs. O trabalho do agente não é ter uma conversa -- é decompor uma tarefa, selecionar a estratégia de execução certa para cada subtarefa e montar resultados. A busca de ferramentas é sobre carregamento dinâmico de capacidades. As chamadas programáticas são sobre execução eficiente. Quando você enquadra assim, esses não são recursos específicos do Claude. São padrões de design que se aplicam a qualquer framework de agentes.

Fazendo Isso Funcionar Além do Claude

Mencionei que esses são padrões de design, não apenas recursos do Claude, e quero ser específico sobre isso porque importa.

Busca de ferramentas é fundamentalmente um padrão de carregamento preguiçoso. Se você está construindo agentes no LangChain, CrewAI ou qualquer framework customizado, pode implementar o mesmo conceito. Mantenha um registro de ferramentas disponíveis com metadados leves. Dê ao seu agente uma função de "buscar ferramentas" que consulte o registro por palavra-chave. Carregue esquemas de ferramentas no prompt apenas quando são selecionados. Os detalhes de implementação diferem, mas a arquitetura é portável.

Chamadas programáticas de ferramentas são um padrão de geração e execução de código. Qualquer framework de agentes pode ser estendido para gerar scripts Python, executá-los em um sandbox e canalizar resultados de volta. A abordagem de sandbox baseada em Docker funciona independentemente de qual LLM você está usando. A arquitetura da ponte de ferramentas é agnóstica ao modelo -- é apenas um servidor HTTP que faz proxy de chamadas API autenticadas.

Até exemplos de uso de ferramentas são portáveis. Todo LLM se beneficia de ver valores de exemplo para parâmetros. Seja usando Claude, GPT-4, Gemini ou um modelo open-source, incluir exemplos nas descrições das suas ferramentas melhora a precisão de parâmetros. A melhoria específica varia por modelo, mas a direção é consistente.

Comecei a aplicar esses padrões a um projeto paralelo que usa uma mistura de Claude e GPT-4o dependendo da complexidade da tarefa. A camada de busca de ferramentas funciona identicamente para ambos os modelos. O sandbox de chamadas programáticas não se importa com qual modelo gerou o código. A única peça específica do modelo é ajustar as definições de ferramentas para as forças e fraquezas particulares de cada modelo na geração de código.

Se você está preso a um framework ou modelo específico, não descarte essas técnicas como "recursos só da Anthropic". Extraia os padrões, adapte a implementação e aplique-os onde quer que esteja construindo agentes.

Os Números Após 30 Dias em Produção

Tenho rodado a arquitetura de agente otimizada por cerca de um mês, e quero compartilhar números reais de produção porque estou cansado de posts de blog que mostram benchmarks selecionados a dedo.

O uso médio de tokens por conversa caiu 42% comparado à arquitetura anterior. Para o agente de operações especificamente, isso é aproximadamente $0,03 por conversa em vez de $0,05. Com cerca de 200 conversas por dia entre todos os usuários, isso economiza cerca de $4/dia ou aproximadamente $120/mês. Não é dinheiro que muda a vida, mas é uma redução de 42% que não exigiu mudanças nas capacidades do agente.

Erros de chamadas de ferramentas -- casos onde o agente chamou a ferramenta errada ou passou parâmetros inválidos -- caíram de cerca de 8% das chamadas para menos de 2%. A maioria dos erros restantes são casos extremos com nomes ambíguos de ferramentas que ainda estou refinando.

A precisão de conclusão de tarefas de ponta a ponta para o fluxo de trabalho de conformidade orçamentária melhorou de aproximadamente 85% (a abordagem tradicional às vezes perdia casos extremos) para 97% com chamadas programáticas. A taxa de falha de 3% é quase inteiramente do sandbox atingindo limites de timeout em conjuntos de dados incomumente grandes, o que estou resolvendo aumentando o timeout do contêiner.

A latência percebida pelo usuário na verdade aumentou levemente para consultas simples -- cerca de 200ms de sobrecarga da busca de ferramentas no primeiro uso. Para consultas complexas que antes requeriam mais de 30 chamadas sequenciais de ferramentas, a latência diminuiu significativamente porque o sandbox executa chamadas de ferramentas mais rápido que o loop de raciocínio serial do LLM.

Esses números não são hipotéticos. São de traces do Langfuse em um sistema de produção lidando com consultas reais de usuários. Seus números específicos dependerão da sua contagem de ferramentas, complexidade de tarefas e padrões de conversa. Mas a melhoria direcional deve ser similar para qualquer pessoa lidando com inchaço de ferramentas ou sobrecarga de chamadas sequenciais.

A Pergunta Que Deveria Mantê-lo Construindo

Seis meses atrás, eu pensava que o caminho para melhores agentes de IA era melhor prompting. Escreva instruções mais claras, forneça mais contexto, use system prompts mais sofisticados. E prompting importa -- não estou descartando. Mas prompting sozinho não resolve problemas arquitetônicos. Você não consegue fazer prompt para sair de uma sobrecarga de 13.000 tokens em definições de ferramentas. Você não consegue fazer prompt para processamento preciso de dados quando resultados intermediários estão inundando sua janela de contexto.

Os ganhos reais vivem na arquitetura de execução: como ferramentas carregam, como dados fluem, como código executa e como o agente decide entre estratégias. Busca de ferramentas, chamadas programáticas e design cuidadoso de ferramentas são a primeira geração dessas ferramentas arquitetônicas. Não serão as últimas.

A pergunta que continuo me fazendo -- e a que desafio você a considerar -- é esta: Como seria sua arquitetura de agente se você a projetasse para 500 ferramentas em vez de 50? Porque é para lá que estamos indo. O ecossistema de servidores MCP, integrações de API e ferramentas customizadas está crescendo rápido. Os agentes que prosperarem não serão os com os prompts mais inteligentes. Serão os com arquiteturas que escalam elegantemente quando a contagem de ferramentas dobra, e depois dobra de novo.

Comece com as três camadas. Meça seu uso de tokens. Observe suas métricas de precisão. E construa a base agora, porque a complexidade só vai aumentar daqui.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds customizados e integrações): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io