Como eliminamos US$ 1 milhão por ano em gastos desperdiçados com agentes de AI em uma hora

Os engenheiros da Databricks dependem muito de agentes de AI para simplificar e acelerar seu trabalho. Por sua vez, esses agentes exigem acesso não apenas a diferentes Foundation Models, mas também a servidores MCP com ferramentas que permitem o acesso a artefatos relevantes (por exemplo, logs do sistema, tabelas de uso, chamados de suporte, wikis). Em um blog anterior, compartilhamos que gerenciar custos de AI em escala exige otimizar não apenas a seleção do modelo, mas também como os agentes usam as ferramentas. Neste post, descrevemos como buscamos economias de custo no uso de ferramentas por nossos agentes, os desafios que encontramos pelo caminho e como o rastreamento de OTel no Unity Gateway reduziu o caminho da análise para uma economia de US$ 1,2 milhão/ano a apenas uma hora.

Permitir que nossos desenvolvedores criassem seus próprios agentes foi um grande avanço para a produtividade, mas, à medida que o uso aumentou, também enfrentamos custos crescentes. Começamos a investigar várias otimizações, e uma suspeita que tínhamos era o custo oculto de chamadas de ferramentas que falham. Especificamente, quando as ferramentas apresentam mau funcionamento, o agente que faz a chamada raramente falha de forma evidente. Em vez disso, ele tenta novamente, adivinha e, eventualmente, contorna o problema, consumindo silenciosamente tokens e tempo do desenvolvedor durante todo o processo. Esse tipo de desperdício é perigoso: externamente, a tarefa ainda é concluída, e um painel de custos agregados pode mostrar um aumento de 10% no gasto de tokens que pode ser facilmente interpretado erroneamente como crescimento de uso. 

Investigamos essa suspeita em nossa frota de agentes usando o rastreamento (tracing) do Unity Gateway e o Genie One. Encontramos sete pequenos bugs em nossos servidores de ferramentas que estavam custando cerca de US$ 499 mil/ano em tokens desperdiçados e cerca de 12.000 horas de engenharia por ano em tempo de espera dos agentes. No total, isso representa uma perda estimada de US$ 1,2 milhão/ano em produtividade. 

Encontrar todos os sete bugs, quantificá-los e corrigi-los levou cerca de uma hora. Este post descreve o processo que seguimos e o que ele nos ensinou sobre a criação de ferramentas para agentes.

Como monitorar a atividade de agentes de AI e MCP

Quando implantamos os agentes de AI pela primeira vez em larga escala na Databricks para codificação e fluxos de trabalho internos, era impossível gerenciar ou até mesmo entender totalmente os custos porque não tínhamos visibilidade das chamadas de ferramentas dos agentes e da atividade geral. Para resolver isso, aproveitamos o Unity Gateway, que emite automaticamente um rastreamento do OpenTelemetry para todas as invocações de ferramentas MCP, incluindo o nome da ferramenta, argumentos, erro (se houver), contagem de tokens, latência e um ID de sessão que vincula as chamadas. Esses rastreamentos vão para uma única tabela que registra exatamente o que nossos agentes fizeram em qualquer janela de tempo. Nenhuma nova instrumentação foi necessária, e o gateway já fica no caminho de cada chamada, de modo que os dados estavam prontamente disponíveis.

Isso torna o gerenciamento de custos de agentes de AI mais prático, onde, em vez de ver apenas o gasto agregado de tokens, podemos atribuir o gasto desperdiçado a ferramentas, erros e sessões de agentes específicos.

Agora que os dados estão disponíveis, o próximo passo é a exploração:

• Quais erros de ferramenta ocorrem com mais frequência?
• Quando um agente encontra um erro, quantas interações são necessárias para se recuperar?
• Quanto custa cada erro em termos de tokens e tempo de espera real?

Normalmente, a parte cara desse tipo de análise é o SQL e a exploração de esquemas. Mas com o Genie One, apenas o apontamos para a tabela de rastreamento, fizemos exatamente essas perguntas em inglês simples e obtivemos respostas em minutos. A maior parte da nossa hora foi gasta lendo essas respostas em vez de escrever consultas.

O que os rastreamentos revelaram: como as falhas de ferramentas MCP aumentam os custos dos agentes de AI

O Genie One transformou uma suspeita vaga ("os agentes parecem se debater em chamadas do Jira") em uma lista de bugs classificada e quantificada em minutos. Aqui está um exemplo de uma única janela de 24 horas, mostrando bugs em nossos servidores de ferramentas do Jira e do Google Drive/Docs:

Pegue o bug de maior volume, 535 falhas por dia, como exemplo. A ferramenta issues.search do Jira aceita um parâmetro fields, e o servidor fez o seguinte:

Ele esperava uma string separada por vírgulas como "key,summary,status". Mas um array é o tipo JSON semanticamente natural para "uma lista de campos", e foi isso que o modelo inferiu a partir de seu conhecimento prévio das convenções JSON e de chamadas de ferramentas adjacentes na mesma sessão. Portanto, ele passou o valor estruturado que um chamador razoável passaria:

Uma lista não tem .split(), então o servidor gerou 'list' object has no attribute 'split', um traceback bruto do Python que não diz nada ao agente sobre o que ele fez de errado. Então o agente tentou adivinhar novamente. Às vezes, ele tentava novamente a mesma lista e falhava da mesma forma; vezes relia o esquema ou recorria à tentativa e erro. Em média, levou 12 interações para se recuperar, e 30% das sessões apresentaram o erro mais de uma vez. Uma única chamada .split() estava custando cerca de US$ 87 mil/ano em tokens e 4.850 horas de tempo de espera do agente.

O erro Invalid field selection do Google Drive foi ainda mais impressionante em volume: 49,6% de todas as chamadas drive_file_get falharam, porque o modelo continuou passando nomes de campos da API do Drive que pareciam válidos (id, name, mimeType), mas que o endpoint da ferramenta não aceitava.

A verdadeira lição: como projetar ferramentas MCP para agentes de AI e LLMs

A conclusão óbvia é "escreva mensagens de erro melhores", e os dados comprovam isso. O custo de recuperação acompanha a qualidade da mensagem de erro quase perfeitamente:

Mas dizer que "boas mensagens de erro ajudam" não é novidade. A questão mais interessante é por que o modelo chamou essas ferramentas de forma "errada" em primeiro lugar. Na maioria desses casos, não foi o que aconteceu.

As assinaturas de ferramentas MCP geralmente são subespecificadas de propósito. Nós as mantemos flexíveis de propósito: em parte por generalidade e em parte para economizar tokens de contexto, já que cada descrição de parâmetro custa tokens que o modelo consome a cada chamada. A consequência é que, quando uma assinatura é vaga sobre os campos, o modelo preenche a lacuna com um palpite razoável, e um array JSON é um palpite razoável para uma lista de campos. O bug não foi que o modelo chamou a ferramenta incorretamente. Foi que o servidor aceitou apenas uma de várias interpretações razoáveis e falhou nas demais.

Portanto, o princípio de design é o inverso do reflexivo: as ferramentas para agentes devem se adaptar à maneira como os LLMs as chamam naturalmente, por exemplo, converter a lista em uma string, definir um valor padrão para o parâmetro omitido, absorver o argumento inesperado e assim por diante. Uma assinatura subespecificada é uma promessa de flexibilidade, e a ferramenta deve honrar essa promessa na recepção, em vez de falhar na primeira entrada que não corresponda ao formato exato que seu autor tinha em mente.

A parte fácil: como reduzimos o desperdício de gastos com agentes de AI em uma hora

As correções em si foram simples e não são a parte interessante desta história. Depois que o Genie One nos entregou uma lista classificada de quais erros corrigir e o que o modelo estava realmente enviando, aplicar as correções nos servidores de ferramentas foi uma etapa rápida com um agente de codificação. Todo o ciclo (encontrar, quantificar, corrigir) levou cerca de uma hora.

A etapa escassa e cara nunca foi escrever a correção. Foi saber o que corrigir. O tracing mais o Genie One transformou essa etapa de um projeto de pesquisa em uma pergunta que você pode fazer em voz alta.

Fechando o ciclo: como monitorar continuamente e reduzir os custos dos agentes de AI

À medida que mais trabalho real é transferido para os agentes, as falhas silenciosas de ferramentas tornam-se um centro de custo de primeira classe, do tipo que se esconde dentro do "crescimento de uso" e nunca alerta ninguém. O ciclo para detectá-las é barato e repetível: o Unity Gateway torna o comportamento do agente observável, e o Genie One torna esse comportamento consultável sem SQL.

Juntos, eles oferecem às equipes uma maneira repetível de monitorar agentes de AI, diagnosticar falhas de ferramentas MCP e reduzir o desperdício de gastos com AI. Se você executa agentes em suas próprias ferramentas, faça o mesmo. Rastreie as chamadas e pergunte ao Genie One o que continua dando errado.

Comece a usar a análise de trace do Unity Gateway com o Genie One

O Unity Gateway está em Disponibilidade Geral, e agora você pode monitorar toda a atividade de AI usando a tabela de trace unificada, que agora está em Beta. Consulte a nossa documentação para saber como começar. 

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original