Observabilidad y control de costos para agentes de IA: cómo evitar que tu factura de tokens se convierta en un incidente
# Observabilidad y control de costos para agentes de IA: cómo evitar que tu factura de tokens se convierta en un incidente
El patrón ya es familiar en toda la industria. Un equipo despliega un agente de IA en producción —un bot de triaje de soporte al cliente, un asistente de revisión de código, un agente de investigación que consulta documentación interna— y en cuestión de semanas llega la factura mensual mostrando un número de cinco dígitos que nadie presupuestó. El agente funcionó, técnicamente. Devolvió 200s, terminó en segundos y produjo respuestas plausibles. Pero por debajo del funcionamiento aparentemente correcto, bucles de llamadas a herramientas descontrolados, recuperaciones redundantes y cadenas de razonamiento sin restricciones quemaron silenciosamente el presupuesto de tokens a múltiplos de la tarifa esperada.
Este artículo explica por qué las herramientas tradicionales de observabilidad pasan por alto estos fallos, qué cambia cuando instrumentas agentes de forma específica, y cómo los equipos que ejecutan agentes en producción en 2026 están conteniendo tanto los costos como la degradación silenciosa de calidad que los acompaña. El enfoque es pragmático: estamos hablando de práctica operativa, no de investigación, y las soluciones que funcionan son las que realmente puedes desplegar.
Por qué los agentes fallan de forma diferente a las aplicaciones tradicionales
La observabilidad convencional fue construida alrededor de servicios que funcionan o fallan. Un servidor web devuelve 200 o 500. Una consulta a base de datos completa en milisegundos o lanza una excepción. La pila de telemetría —Prometheus, OpenTelemetry, la familia ELK— fue diseñada para capturar estos resultados binarios y las latencias que los rodean.
Los agentes de IA rompen este modelo de una forma específica. Un agente puede devolver HTTP 200, terminar en dos segundos, y aun así estar equivocado. El modo de falla es semántico: el agente alcanzó una respuesta confiada pero incorrecta a través de una cadena de razonamiento que parecía plausible en cada paso. Como señala el análisis de Vellum de 2026: "un agente puede devolver HTTP 200, terminar en dos segundos, y estar equivocado". El monitoreo tradicional ve un servicio saludable. El usuario ve una respuesta confiadamente incorrecta.
Este modo de falla semántico es lo que convierte a la observabilidad de agentes en una disciplina propia. No basta con saber que el agente fue llamado; necesitas saber qué hizo durante la llamada —qué herramientas invocó, qué recuperó, cómo razonó, dónde se comprometió con una decisión que resultó ser errónea. Esa telemetría se estructura de forma diferente, se captura en puntos diferentes y se analiza con preguntas diferentes.
La diferencia entre observabilidad de LLM y observabilidad de agentes
La observabilidad de LLM, la disciplina más antigua, rastrea llamadas individuales a modelos. Registra el prompt, la completion, la latencia, el conteo de tokens y el costo. Un equipo que ejecuta un endpoint de clasificación o un resumidor de un solo turno puede obtener la mayor parte de lo que necesita de la observabilidad de LLM: se hizo la llamada, tuvo éxito, cuánto costó.
La observabilidad de agentes añade una capa por encima de la observabilidad de LLM: rastrea la ejecución dentro de la cual esas llamadas se sientan. Una ejecución de agente es un árbol de operaciones: llamadas de planificación, decisiones de enrutamiento, invocaciones de herramientas, recuperaciones, llamadas de LLM de seguimiento basadas en resultados intermedios, y síntesis final. Los fallos interesantes ocurren en el medio de este árbol, no en las hojas. Una herramienta que devolvió un resultado vacío no es un error, y a menudo es la razón por la que la respuesta final fue incorrecta. Una recuperación que recuperó los documentos equivocados no es una excepción, y a menudo es la razón por la que el agente alucinó una cita.
La comunidad de desarrolladores de OpenAI ha estado recopilando estos patrones en tiempo real. En un hilo de septiembre de 2026 titulado "¿Alguien ha resuelto realmente los costos descontrolados de los agentes?", los participantes describen el problema del "Bucle Zombie" —agentes que iteran sobre la misma llamada a herramienta indefinidamente hasta alcanzar un máximo configurado, momento en el cual han consumido miles de tokens llegando a una respuesta que una llamada directa habría producido. Otros participantes describen agentes que llaman APIs externas de pago en bucles cerrados, cada llamada barata individualmente pero acumulativamente devastadora. Las historias de terror comparten un patrón: el agente parecía estar funcionando, la telemetría mostraba un servicio saludable, y el costo solo se volvió visible cuando llegó la factura.
Cómo se ve un trace adecuado de un agente
Un trace para una ejecución de agente es un árbol de spans, cada uno representando una operación. El span raíz es la ejecución del agente en sí; sus hijos son las llamadas de planificación, las invocaciones de herramientas, las recuperaciones y las llamadas a LLM. Cada span lleva su propio input, output, latencia y costo. El árbol es lo que cuenta la historia, porque un span individual rara vez se explica por sí mismo.
Para un agente de investigación que toma una consulta, planifica una recuperación, recupera documentos, planifica una síntesis, llama a un LLM para redactar una respuesta, y verifica la respuesta contra las fuentes recuperadas, un trace típico podría tener entre 10 y 50 spans. Cada recuperación tiene su propia consulta, sus top-k resultados y sus puntajes de similitud. Cada llamada a LLM tiene su prompt, completion, conteo de tokens y finish reason. La llamada de síntesis referencia los outputs de las llamadas anteriores.
Cuando algo sale mal, el trace te permite reproducir la ejecución paso a paso. Puedes ver que la recuperación devolvió documentos sobre la línea de productos equivocada, que el agente luego sintetizó una respuesta usando esos documentos equivocados, y que ningún paso de verificación detectó el problema porque el paso de verificación usó la misma recuperación defectuosa. Sin el trace, solo verías "el agente devolvió una respuesta incorrecta" sin camino hacia la remediación.
Las convenciones semánticas GenAI de OpenTelemetry
OpenTelemetry ha estado desarrollando convenciones semánticas para cargas de trabajo de IA generativa bajo el namespace `gen_ai.*`. Estas convenciones definen nombres de atributos estandarizados para las cosas que importan en la instrumentación de agentes: el nombre del modelo, los conteos de tokens para prompt y completion, el finish reason, el nombre de la herramienta, los argumentos de la herramienta, la consulta y los resultados de la recuperación.
Las convenciones aún no están finalizadas, pero son lo suficientemente estables como para que el tooling de producción las esté adoptando. El beneficio de la estandarización es que la instrumentación escrita una vez puede exportar a más de un backend. Si instrumentas tus agentes usando las convenciones GenAI de OpenTelemetry, puedes rutear los mismos spans a Datadog, a Honeycomb, a un colector autoalojado de OpenTelemetry, o a un vendor especializado en observabilidad de agentes sin reescribir tu instrumentación.
Los paquetes de auto-instrumentación que existen hoy cubren los frameworks principales. Los SDKs de Python y Node de OpenAI tienen instrumentaciones mantenidas por la comunidad. El SDK de Anthropic tiene instrumentación oficial. LangChain y LlamaIndex, los dos frameworks de agentes más populares, ambos se distribuyen con instrumentación compatible con OpenTelemetry que captura los principales tipos de spans automáticamente. Para equipos que construyen frameworks de agentes personalizados, las convenciones GenAI de OpenTelemetry proporcionan una plantilla que puede adaptarse.
Las cuatro clases de alertas que realmente importan
Las reglas de alerting estándar no funcionan para agentes. El enfoque tradicional —alertar cuando la latencia excede un umbral, alertar cuando la tasa de errores excede un umbral— pasa por alto los modos de falla más comunes de los agentes. Un umbral de latencia no detecta un agente que está tardando más porque está iterando. Un umbral de tasa de errores no detecta un agente que está teniendo éxito pero devolviendo respuestas incorrectas.
Las reglas de alerting que importan en la práctica son diferentes. El análisis de OneUptime de 2026 identifica cuatro clases:
Alertas de tasa de costo: "Este agente está quemando $50/hora, normalmente son $3/hora". El umbral se calibra contra la línea base histórica, no contra un número absoluto, porque los costos de los agentes varían enormemente según el tipo de consulta. La alerta se dispara cuando el costo-por-tiempo excede la línea base por algún múltiplo —dos veces, cinco veces, diez veces dependiendo de la tolerancia.
Alertas de detección de bucles: "Este agente ha hecho más de 20 llamadas a LLM para una sola consulta". La mayoría de los agentes que funcionan bien hacen menos de 10 llamadas a LLM por consulta; las alertas sobre el conteo de llamadas detectan los bucles zombie que queman tokens sin hacer progreso.
Alertas de distribución de latencia: No solo latencia p99, sino alertas cuando la varianza de la latencia en sí misma aumenta. Un agente que está tomando tiempos altamente variables por consulta a menudo está haciendo cantidades inconsistentes de llamadas internas, lo cual a menudo correlaciona con calidad inconsistente.
Alertas de degradación de calidad: "Los puntajes de relevancia de recuperación cayeron 40% en la última hora". Estas alertas requieren instrumentar el paso de recuperación específicamente y rastrear la calidad de lo que se recuperó. Detectan las fallas de calidad silenciosas que las alertas de tasa de costo pasan por alto.
El agente descontrolado como incidente presupuestario
El encuadre de OneUptime vale la pena enfatizar: "Un agente descontrolado es un incidente presupuestario, y sin telemetría de costo por ejecución te enteras en la factura". Esto reencuadra el problema de ingeniería a finanzas. Los incidentes de rendimiento tradicionales disparan respuesta de ingeniería; los incidentes presupuestarios requieren involucramiento de finanzas y procurement. Los dos no son intercambiables.
Para un agente que cuesta $0.05 por consulta en promedio pero alcanza un camino de código que cuesta $5 por consulta debido a un bucle, la diferencia entre la factura esperada y la observada puede ser 100x. Si ese camino de código se activa por una fracción no trivial de consultas en producción, la factura mensual puede exceder todo el presupuesto de ingeniería del proyecto. Varias de las historias de terror en la comunidad de desarrolladores de OpenAI involucran exactamente este patrón: un único camino de código no obvio que se convierte en un amplificador de costo recurrente.
La mitigación requiere telemetría de costo por ejecución. Cada ejecución de agente necesita llevar su costo total como un atributo del span, y el costo necesita ser calculado a partir de los conteos de tokens reales y las invocaciones de herramientas, no estimado a partir del conteo de llamadas. Esto requiere instrumentar el cálculo de costos en cada capa del stack del agente, no solo a nivel de llamada LLM. Las llamadas a herramientas también tienen costos —costos de API por servicios externos, costos de consulta a base de datos, costos de recuperación desde bases de datos vectoriales. Un agente que hace 50 recuperaciones por consulta puede costar más en tarifas de recuperación que en tokens de LLM.
Eligiendo la herramienta correcta para el trabajo
El panorama de herramientas de observabilidad de agentes en 2026 se divide en varios grupos. Para tracing y evaluación, LangSmith, Langfuse, Arize Phoenix, Braintrust y Confident AI capturan ejecuciones de agentes y las puntúan, con Langfuse y Phoenix favorecidos por equipos que quieren opciones open-source o nativas de OpenTelemetry. Para correlacionar comportamiento de agentes con infraestructura, Datadog LLM Observability conecta señales del modelo con el resto del stack. Para tracking basado en proxy de costo y latencia, Helicone es rápido de desplegar. Para evaluación y seguridad, Galileo y Fiddler añaden guardrails y monitoreo de cumplimiento para equipos regulados.
La elección depende de lo que ya tienes. Equipos que ya ejecutan Datadog para observabilidad de infraestructura encontrarán en Datadog LLM Observability el camino de menor resistencia. Equipos con stacks nativos de OpenTelemetry encontrarán en Langfuse o Arize Phoenix la extensión natural. Equipos construyendo flujos de trabajo pesados en evaluación encontrarán en Confident AI o Braintrust el mejor encaje.
Un error común es tratar la elección como permanente. El tooling de observabilidad de agentes está evolucionando rápidamente, y los costos de cambio son reales pero no insuperables si instrumentas con las convenciones GenAI de OpenTelemetry. Las convenciones son lo suficientemente estables como para que cambiar de backend no requiera re-instrumentar el código del agente.
El costo de no tener observabilidad de agentes
El costo de ejecutar un agente sin observabilidad adecuada no son solo las facturas de tokens descontroladas. Son las fallas silenciosas de calidad que erosionan la confianza del usuario durante semanas y meses antes de que alguien note. Es la inhabilidad de debuggear modos de falla específicos porque no existe un trace. Es la imposibilidad de hacer A/B testing de nuevos prompts o nuevas arquitecturas de agentes porque las métricas que los distinguirían no se capturan.
Los equipos que despliegan agentes sin observabilidad están volando a ciegas. Podrían tener suerte y que el agente funcione bien durante meses. También podrían tener una regresión de calidad que aleje a los usuarios, y no sabrán por qué. Como concluye el análisis de OneUptime: "La ola de agentes de IA es real. Las empresas que instrumentan correctamente desde el día uno iterarán más rápido, gastarán menos, y enviarán productos más confiables. Las que no lo hagan estarán debuggeando incidentes de producción leyendo logs de output de LLM y rezando".
La buena noticia es que el tooling ha madurado lo suficiente como para que instrumentar desde el día uno ya no sea un proyecto de investigación. Las convenciones GenAI de OpenTelemetry son estables, los paquetes de auto-instrumentación cubren los frameworks principales, y los patrones de alerting son bien entendidos. El costo de instrumentación adecuada se mide en días de trabajo, no en meses. El costo de saltarla se paga en facturas descontroladas, fallas silenciosas y confianza del usuario erosionada con el tiempo.
Conclusión operativa
Instrumenta tus agentes con las convenciones semánticas GenAI de OpenTelemetry desde el inicio. Captura costo como un atributo del span en cada capa, no solo en llamadas a LLM. Configura cuatro clases de alertas: tasa de costo, detección de bucles, varianza de latencia y calidad de recuperación. Elige un backend de observabilidad que se ajuste a tu stack pero que permanezca portable a través de las convenciones. Y trata los costos descontrolados de agentes como incidentes presupuestarios, no solo como incidentes de ingeniería.
La ola de agentes no se está desacelerando. Los equipos que envían agentes confiables a costo predecible son los que han construido la disciplina de observabilidad para ver qué están haciendo realmente sus agentes. Cualquier otro equipo está debuggeando a ciegas.
---
*Fuentes verificadas: análisis de InfoQ "Observability and Cost Controls for AI Agents" por Mark Silvester, septiembre de 2026; Expanso "AI Agent Observability Best Practices 2026"; análisis de OneUptime "Observability for AI Agents: Why Your LLM Apps Are Flying Blind", febrero de 2026; guía de Uptrace "OpenTelemetry for AI Systems: LLM and Agent Observability", abril de 2026; Vellum "Best AI Agent Observability Tools 2026"; Elastic "Observability Trends for 2026 Part 2"; Confident AI "Top 8 AI Agent Observability Platforms for 2026"; hilo de la comunidad de desarrolladores de OpenAI "Has anyone actually solved runaway agent costs?", septiembre de 2026; Honeycomb "15 Best AI Observability Tools for Production Teams in 2026".*