Cómo eliminamos en una hora un millón de dólares al año en gasto desperdiciado de agentes de IA

Los ingenieros de Databricks confían en gran medida en los agentes de AI para agilizar y acelerar su trabajo. A su vez, estos agentes requieren acceso no solo a diferentes modelos fundacionales, sino también a servidores MCP con herramientas que permiten el acceso a artefactos relevantes (por ejemplo, registros del sistema, tablas de uso, tickets de soporte, wikis). En un blog anterior, compartimos que administrar los costos de AI a escala requiere optimizar no solo la selección de modelos, sino también cómo los agentes usan las herramientas. En esta publicación, describimos cómo buscamos ahorros de costos en el uso de herramientas por parte de nuestros agentes, los desafíos que encontramos en el camino y cómo el rastreo de OTel en Unity Gateway redujo a una sola hora el camino desde el análisis hasta un ahorro de $1.2 millones al año.

Permitir que nuestros desarrolladores crearan sus propios agentes fue un gran impulso para la productividad, pero a medida que el uso aumentó, también nos enfrentamos a costos crecientes. Comenzamos a investigar varias optimizaciones, y una sospecha que teníamos era el costo oculto de las llamadas a herramientas fallidas. Específicamente, cuando las herramientas no funcionan correctamente, el agente que realiza la llamada rara vez falla de manera evidente. En su lugar, vuelve a intentarlo, adivina y, finalmente, busca una solución alternativa al problema, consumiendo silenciosamente tokens y tiempo de desarrollo durante todo el proceso. Este tipo de desperdicio es peligroso: desde fuera, la tarea aún se completa, y un panel de control de costos agregados puede mostrar un aumento del 10% en el gasto de tokens que puede malinterpretarse fácilmente como un crecimiento en el uso. 

Investigamos esta sospecha en nuestra flota de agentes utilizando el rastreo de Unity Gateway y Genie One. Encontramos siete pequeños errores en nuestros servidores de herramientas que costaban un estimado de $499,000 al año en tokens desperdiciados y alrededor de 12,000 horas de ingeniería al año en tiempo de espera de los agentes. En general, esto representa un estimado de $1.2 millones al año en pérdida de productividad. 

Encontrar los siete errores, cuantificarlos y corregirlos tomó alrededor de una hora. Esta publicación describe el proceso que seguimos y lo que nos enseñó sobre la creación de herramientas para agentes.

Cómo monitorear la actividad de los agentes de AI y MCP

Cuando implementamos por primera vez agentes de AI a gran escala en Databricks para la codificación y los flujos de trabajo internos, era imposible administrar o incluso comprender por completo los costos porque carecíamos de visibilidad sobre las llamadas a herramientas de los agentes y su actividad general. Para solucionar esto, aprovechamos Unity Gateway, que emite automáticamente un rastro de OpenTelemetry para todas las invocaciones de herramientas MCP, incluido el nombre de la herramienta, los argumentos, el error (si lo hay), el conteo de tokens, la latencia y un ID de sesión que vincula las llamadas. Esos rastros terminan en una sola tabla que registra exactamente lo que hicieron nuestros agentes durante cualquier período de tiempo. No se requirió nueva instrumentación, y la puerta de enlace ya se encuentra en la ruta de cada llamada, por lo que los datos estaban disponibles de inmediato.

Esto hace que la administración de costos de los agentes de AI sea más accionable, donde en lugar de ver solo el gasto agregado de tokens, podemos atribuir el gasto desperdiciado a herramientas, errores y sesiones de agentes específicos.

Ahora que los datos están disponibles, el siguiente paso es la exploración:

• ¿Qué errores de herramientas se repiten más?
• Cuando un agente se topa con uno, ¿cuántos turnos le toma recuperarse?
• ¿Cuánto cuesta cada error en tokens y tiempo de espera real?

Normalmente, la parte costosa de este tipo de análisis es el SQL y la exploración de esquemas. Pero con Genie One, simplemente lo apuntamos a la tabla de rastreo, hicimos estas mismas preguntas en inglés sencillo y obtuvimos respuestas en minutos. La mayor parte de nuestra hora se dedicó a leer esas respuestas en lugar de escribir consultas.

Lo que revelaron los rastreos: Cómo las fallas de las herramientas MCP aumentan los costos de los agentes de AI

Genie One convirtió una sospecha vaga ("los agentes parecen dar vueltas en las llamadas de Jira") en una lista de errores clasificada y cuantificada en minutos. Aquí hay un ejemplo de una sola ventana de 24 horas, que muestra errores en nuestros servidores de herramientas de Jira y Google Drive/Docs:

Tomemos como ejemplo el error de mayor volumen, 535 fallas al día. La herramienta issues.search de Jira toma un parámetro fields, y el servidor hizo esto:

Esperaba una cadena separada por comas como "key,summary,status". Pero un array es el tipo de JSON semánticamente natural para "una lista de campos", y eso es lo que el modelo infirió a partir de su conocimiento previo de las convenciones de JSON y de las llamadas a herramientas adyacentes en la misma sesión. Así que pasó el valor estructurado que pasaría un emisor razonable:

Una lista no tiene .split(), por lo que el servidor generó 'list' object has no attribute 'split', un rastreo de error (traceback) de Python sin procesar que no le dice nada al agente sobre lo que hizo mal. Así que el agente volvió a adivinar. A veces volvía a intentar con la misma lista y fallaba de la misma manera; a veces volvía a leer el esquema o recurría al método de prueba y error. En promedio, tomó 12 turnos para recuperarse, y el 30% de las sesiones experimentaron el error más de una vez. Una sola llamada a .split() estaba costando un estimado de $87,000 al año en tokens y 4.850 horas de tiempo de espera del agente.

El error de Google Drive Invalid field selection fue aún más sorprendente en volumen: el 49.6% de todas las llamadas a drive_file_get fallaron, porque el modelo seguía pasando nombres de campos de la API de Drive que parecían válidos (id, name, mimeType) pero que el endpoint de la herramienta no aceptaba.

La verdadera lección: Cómo diseñar herramientas MCP para agentes de AI y LLM

La conclusión obvia es "escribir mejores mensajes de error", y los datos lo respaldan. El costo de recuperación se alinea casi a la perfección con la calidad del mensaje de error:

Pero que "los buenos mensajes de error ayudan" no es ninguna novedad. La pregunta más interesante es por qué el modelo llamó a estas herramientas de forma "incorrecta" en primer lugar. En la mayoría de estos casos, no lo hizo.

Las firmas de las herramientas MCP a menudo están deliberadamente subespecificadas. Las mantenemos flexibles a propósito: en parte por generalidad y en parte para ahorrar tokens de contexto, ya que cada descripción de parámetro cuesta tokens que el modelo paga en cada llamada. La consecuencia es que cuando una firma es vaga sobre los campos, el modelo llena el vacío con una suposición razonable, y un array JSON es una suposición razonable para una lista de campos. El error no fue que el modelo llamara a la herramienta de forma incorrecta. Fue que el servidor aceptó solo una de varias interpretaciones razonables y falló con el resto.

Por lo tanto, el principio de diseño es el inverso al reflexivo: las herramientas para agentes deben adaptarse a la forma en que los LLM las llaman de manera natural, por ejemplo, convertir la lista en una cadena, asignar un valor predeterminado al parámetro omitido, absorber el argumento inesperado, etc. Una firma subespecificada es una promesa de flexibilidad, y la herramienta debe cumplir esa promesa en el extremo receptor en lugar de fallar con la primera entrada que no coincida con la única forma que su autor tenía en mente.

La parte fácil: cómo redujimos el gasto innecesario en agentes de AI en una hora

Las correcciones en sí fueron sencillas y no son la parte interesante de esta historia. Una vez que Genie One nos entregó una lista clasificada de qué errores corregir y qué estaba enviando realmente el modelo, aplicar las correcciones en los servidores de herramientas fue un paso rápido con un agente de codificación. Todo el ciclo (buscar, cuantificar, corregir) tomó aproximadamente una hora.

El paso escaso y costoso nunca fue escribir la corrección. Era saber qué corregir. El rastreo junto con Genie One convirtió ese paso de un proyecto de investigación a una pregunta que se puede hacer en voz alta.

Cerrar el ciclo: cómo monitorear continuamente y reducir los costos de los agentes de AI

A medida que se traslada más trabajo real a los agentes, las fallas silenciosas de las herramientas se convierten en un centro de costos de primer nivel, del tipo que se oculta dentro del "crecimiento del uso" y nunca alerta a nadie. El ciclo para detectarlas es económico y repetible: Unity Gateway hace que el comportamiento del agente sea observable, y Genie One hace que ese comportamiento sea consultable sin SQL.

Juntos, esto ofrece a los equipos una forma repetible de monitorear agentes de AI, diagnosticar fallas en las herramientas MCP y reducir el gasto innecesario en AI. Si ejecuta agentes con sus propias herramientas, haga lo mismo. Rastree las llamadas y pregúntele a Genie One qué sigue saliendo mal.

Comience con el análisis de rastreo de Unity Gateway con Genie One

Unity Gateway está disponible de forma general (GA), y ahora puede monitorear toda la actividad de AI utilizando la tabla de rastreo unificada, que ahora está en versión Beta. Consulte nuestra documentación para saber cómo comenzar. 

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original