Observabilidad de agentes de IA: cómo ver qué hacen tus agentes (2026)

Los agentes de IA fallan de formas que el software normal no falla: no lanzan una excepción, simplemente se desvían, se atascan o queman dinero en silencio. La observabilidad de agentes es la capacidad de responder, en cualquier momento, a cuatro preguntas: ¿qué agentes corren?, ¿qué están haciendo?, ¿cuánto llevan gastado? y ¿cuál me necesita?

Por qué los logs no bastan

Un log te dice qué pasó después de que pasara. Con agentes que corren minutos u horas y toman decisiones por el camino, lo que necesitas es estado en vivo: el paso actual, el plan restante, la última salida. Revisar logs de un agente desviado es hacer la autopsia; la observabilidad de verdad te deja intervenir mientras el paciente sigue vivo.

Las señales que importan

• Estado. Corriendo, esperando aprobación, atascado, terminado, fallido — de un vistazo, para todos los agentes.
• Paso actual. Qué está haciendo ahora mismo y qué viene después.
• Coste acumulado. Tokens y dinero por tarea — los desvíos de coste avisan antes que los de comportamiento.
• Tiempo en el paso. Un agente 20 minutos en el mismo paso está atascado, aunque su estado diga "corriendo".
• Peticiones al humano. Cuántas decisiones esperan tu respuesta y desde cuándo.

El anti-patrón: un dashboard que nadie mira

La observabilidad que requiere estar sentado delante no funciona, porque los agentes corren precisamente cuando tú no estás. Las señales tienen que llegar a donde estés — el móvil — con la opción de actuar desde ahí: aprobar, parar, redirigir. Ver sin poder actuar es televisión, no observabilidad.

En qué se diferencia de la observabilidad de siempre

Un APM clásico está construido sobre una premisa: cuando algo va mal, algo falla. Hay una excepción, un 500, una latencia que se dispara. Con agentes esa premisa se rompe. Un agente que se ha entendido mal la tarea devuelve un 200 en todas sus llamadas, no lanza ni un error, y produce trabajo inútil durante cuarenta minutos con una salud perfecta en el panel.

Por eso las señales útiles son distintas. En un servicio web vigilas latencia, errores y saturación. En un agente vigilas progreso (¿avanza o da vueltas?), coherencia (¿el paso actual tiene que ver con el objetivo?) y gasto (¿cuánto lleva quemado?). Las tres pueden ir mal sin que se caiga nada.

Las herramientas y qué cubre cada una

• Trazas y evaluación — LangSmith, Langfuse, Arize Phoenix, W&B Weave. Registran cada llamada al modelo, cada herramienta invocada y cada resultado, para que puedas reconstruir después qué pasó y puntuarlo. Langfuse y Phoenix son open source y se pueden autoalojar, que importa si tus prompts contienen datos de clientes.
• Proxies de coste — Helicone y similares se colocan entre tu código y el proveedor, y te dan gasto por petición sin tocar la aplicación. Baratos de adoptar; a cambio, todo tu tráfico pasa por ellos.
• OpenTelemetry ya tiene convenciones semánticas para GenAI, así que puedes instrumentar agentes con el mismo estándar que el resto de tu infraestructura. Es la opción correcta a largo plazo y la más lenta de montar.
• Capas de control — la parte que ninguna de las anteriores cubre: actuar sobre un agente que sigue corriendo. Una traza te explica el desastre de anoche; no lo detiene.

La prueba práctica para elegir: cuando un agente lleve veinte minutos yendo en la dirección equivocada, ¿tu stack te deja intervenir, o solo contártelo mañana?

Qué alertar y qué solo registrar

El fallo más común no es no tener datos, es alertar de todo y acabar ignorándolo. Una regla que funciona: alerta de lo que requiere una decisión tuya; registra el resto.

• Alerta: agente esperando aprobación, agente parado más de N minutos en el mismo paso, coste de una tarea por encima de su presupuesto, fallo tras agotar reintentos.
• Registra: cada llamada al modelo, cada herramienta usada, cada salida intermedia. Lo vas a necesitar cuando preguntes "¿por qué hizo eso?", y no antes.

Si una alerta no cambia lo que vas a hacer en los próximos cinco minutos, no es una alerta: es una línea de log con ínfulas.

El coste, medido de verdad

El gasto por agente no dice gran cosa. Lo que necesitas es coste por tarea completada, porque es lo único comparable: si una tarea que costaba 0,40 € pasa a costar 1,80 €, algo cambió — el agente está reintentando, ha entrado en un bucle, o el contexto ha crecido sin control.

Dos cifras más que valen su peso: el porcentaje de tareas abandonadas (empezadas y nunca terminadas, que suelen ser gasto puro) y el coste de los reintentos frente al del primer intento. Cuando el segundo se acerca al primero, tienes un problema de diseño, no de precio del modelo.

Empieza simple

No necesitas OpenTelemetry para empezar. Una vista con el estado de cada agente, su paso actual y un botón de parar cubre el 80 % del valor. Añade coste por tarea y alertas de atasco, y tendrás más observabilidad de la que tiene la mayoría de equipos que ejecutan agentes hoy.

Preguntas frecuentes

¿Qué es la observabilidad de agentes de IA? Es poder responder en cualquier momento a qué agentes están corriendo, qué están haciendo, cuánto llevan gastado y cuál necesita una decisión tuya. Se distingue de los logs en que describe el presente, no el pasado.

¿No me vale mi APM de siempre? Para la infraestructura sí, para los agentes no. Un APM detecta que algo falla; un agente que se ha equivocado de tarea no falla, responde 200 en todo y gasta dinero produciendo trabajo inservible.

¿Observabilidad y orquestación son lo mismo? No. La observabilidad registra y muestra; la orquestación además actúa — aprobar, redirigir, parar. Comprar solo la primera es el error más habitual, porque deja el problema perfectamente documentado y sin resolver.

¿Cuántos agentes hacen falta para que compense? Con uno, mirarlo de vez en cuando basta. La necesidad aparece cuando ya no sabes de un vistazo cuál está atascado, que suele ser hacia el tercero o el cuarto.