Observabilidad de agentes de IA: ver qué hace un agente en tiempo real

Cuanto más autonomía gana un agente de IA, más central se vuelve la pregunta «¿qué hizo exactamente?». Un agente que funciona de forma continua, solicitado por varios canales, que llama a herramientas y a veces delega en subagentes, produce una actividad difícil de seguir a simple vista. La observabilidad es la respuesta técnica a este problema: hacer visible, trazable y comprensible lo que realmente ocurre dentro del sistema.

Definición detallada

La observabilidad, en el sentido amplio del término en ingeniería de software, es la capacidad de entender el estado interno de un sistema examinando lo que produce hacia el exterior, típicamente trazas, métricas y registros (logs). Es la definición que adopta OpenTelemetry, el estándar abierto de referencia para la instrumentación de software, respaldado por numerosos proveedores de herramientas de observabilidad. Estos tres tipos de datos cumplen funciones complementarias: las trazas siguen una solicitud a lo largo de su recorrido en un sistema distribuido, los registros anotan eventos con marca de tiempo asociados o no a una solicitud precisa, y las métricas agregan mediciones numéricas a lo largo del tiempo.

La observabilidad de agentes aplica este mismo principio al caso específico de un agente de IA autónomo. Todavía no existe una norma única y ampliamente asentada que defina con precisión lo que debe cubrir la observabilidad agéntica, a diferencia de la observabilidad de software clásica que cuenta con un estándar maduro como OpenTelemetry. En la práctica, sin embargo, las plataformas que hacen funcionar agentes convergen hacia necesidades comunes: saber qué acción ejecutó un agente, sobre qué herramienta, en qué momento, con qué resultado, y a iniciativa de qué disparador (una conversación, un correo, una tarea planificada).

No es un lujo técnico reservado a los grandes equipos. En cuanto un agente puede actuar sin validación sistemática en cada paso, la observabilidad se convierte en la forma concreta de responder a la pregunta «¿por qué hizo eso?» a posteriori, o de detectar un comportamiento anómalo antes de que cause un problema real.

Cómo funciona

En concreto, la observabilidad de un agente se apoya en tres capas superpuestas. La primera es la captura de eventos: cada decisión, cada llamada a herramienta, cada paso de razonamiento significativo se registra en el momento en que ocurre, con una marca de tiempo, un estado (en curso, correcto, con error) y el origen del disparador. La segunda es la estructuración: estos eventos en bruto se categorizan (una acción sobre un archivo no se registra igual que una llamada a una herramienta externa o que un paso de razonamiento del modelo), para poder filtrar y buscar de forma eficaz. La tercera es la presentación: una interfaz o una exportación que permite a una persona recorrer esta actividad, ya sea para un agente concreto o para el conjunto de una organización.

Un buen sistema de observabilidad agéntica también distingue el trabajo delegado: cuando un agente confía una subtarea a un subagente efímero, esa delegación debe seguir siendo visible en la cronología del padre, de lo contrario una parte del trabajo real se vuelve invisible.

Ejemplo concreto con Atako

En Atako, la observabilidad por agente se apoya en una línea de tiempo de actividad en tiempo real: cada evento se categoriza ahí (web, archivos, memoria, código, integración, planificación, delegación, razonamiento del modelo, otro), con un estado (en curso, correcto, con error), una duración, y un origen preciso (chat, correo, webhook, tarea planificada, mensaje entre agentes, subagente, o sistema). Un panel dedicado, «Tool logs», lista por separado cada llamada de integración realizada por el agente, con su resultado (éxito, rechazo, error).

Esta observabilidad por agente se completa con una vista a nivel de toda la empresa, reservada a los administradores: una página de «Integration logs» filtrable por equipo, agente, proveedor y fecha, con una exportación CSV de hasta 50 000 líneas, además de una vista agregada de uso por proveedor de integración. Cada llamada registrada conserva el agente implicado, la conexión utilizada, el proveedor, la acción precisa, sus argumentos (con los campos sensibles como el cuerpo de un correo o una consulta de búsqueda enmascarados sistemáticamente), el estado, el código HTTP devuelto por el proveedor, la latencia y la marca de tiempo. Las barreras de seguridad de permisos (los grants) y la observabilidad funcionan de la mano: una decide si una acción está autorizada, la otra conserva el rastro de lo que realmente ocurrió.

Errores frecuentes

Un error frecuente consiste en confundir observabilidad con un simple registro de errores. Un sistema observable no se limita a señalar cuando algo se rompe, también da visibilidad sobre el funcionamiento normal, lo que permite entender un comportamiento inesperado incluso cuando nada ha fallado técnicamente.

Segundo error: pensar que la observabilidad impide que un agente actúe mal. No es un mecanismo de bloqueo, es un mecanismo de visibilidad. Se combina con los permisos y, para las acciones sensibles, con un punto de validación humana, pero no sustituye a ninguno de los dos.

Tercer error: reservar la observabilidad a los administradores sin ponerla a disposición de los equipos que realmente usan el agente día a día. Una observabilidad útil debe permitir que la persona que creó o que usa un agente entienda su comportamiento, no solo un rol técnico aislado.

Por último, subestimar la importancia de las delegaciones a subagentes en la cronología de actividad es un error clásico. Un agente que delega una subtarea sigue siendo responsable del resultado ante el usuario: si esa delegación no aparece con claridad en la línea de tiempo, una parte del trabajo real se vuelve invisible e incomprensible a posteriori.