No puedes operar un agente que no puedes observar

Aquí hay un hallazgo silenciosamente alarmante: una encuesta de Cisco de este año reportó que el 71% de las organizaciones están corriendo agentes de IA que no pueden monitorear bien. Léelo por lo que es: la mayoría de los equipos que despliegan agentes no tienen una forma confiable de ver qué están haciendo esos agentes. Lanzaron algo autónomo dentro de su negocio y luego cerraron los ojos.

Suena descuidado, pero es una trampa fácil de caer, porque los agentes rompen los supuestos sobre los que está construido el monitoreo normal. Y la respuesta de la industria —toda una categoría nueva llamada observabilidad de agentes que apenas existía hace un año— te dice qué tan real es el problema. Vale la pena entenderlo aunque nunca compres una herramienta para ello, porque el principio de fondo es simple: no puedes operar lo que no puedes ver.

Los agentes fallan de una forma que parece éxito

El software normal falla a gritos. Lanza un error, devuelve un 500, se cae. Tu monitoreo está construido para atrapar exactamente eso. Los agentes no te hacen ese favor.

Un agente falla de maneras que parecen éxito: una respuesta bien formada que está equivocada, una llamada a una herramienta que no necesitaba, una acción sintácticamente válida y semánticamente absurda. Devuelve un limpio HTTP 200 y un resultado seguro de sí mismo mientras hizo lo incorrecto. Esta es la misma falla sobre la que escribí en los agentes declaran victoria contra el objetivo equivocado y, desde afuera, esa falla es invisible. Nada arrojó error. El tablero está en verde. El agente manejó mal el caso en silencio y siguió adelante.

Por eso el monitoreo tradicional no te salva aquí. Rastrear códigos de respuesta y latencia te dice que el agente corrió. No te dice nada sobre si hizo lo correcto, y «corrió con éxito mientras estaba equivocado» es el modo de falla característico del agente.

La falla vive en la traza, no en la salida

Hay una segunda razón por la que los agentes son difíciles de observar. Sus errores normalmente no están en ningún paso individual: están en la secuencia. Un agente lee, decide, llama a una herramienta, lee el resultado, decide otra vez, llama a otra. Cada llamada individual puede verse perfectamente bien mientras el camino general se descarrila en silencio. Como lo pone una guía, las fallas de varios turnos son invisibles a nivel de la llamada individual y solo aparecen en la traza causal completa.

Así que observar un agente no significa registrar su respuesta final. Significa capturar toda la cadena —cada llamada al modelo, cada ejecución de herramienta, cada paso de razonamiento— como una traza que puedas reproducir y seguir. La diferencia es brutal en un incidente: los equipos con esa traza pueden responder «por qué hizo eso» en minutos; la mayoría no instrumentada solo puede encoger los hombros y volver a correrlo, esperando que se comporte distinto esta vez. A medida que los agentes pasan a trabajos que tocan dinero y clientes, esa brecha deja de ser un lujo opcional.

Esta es la mitad poco glamorosa de «observa, no apruebes»

He defendido que el trabajo se desplaza de aprobar cada paso a observar el sistema: fijar la política e intervenir cuando algo se ve mal. El incómodo corolario es: solo puedes observar lo que has instrumentado. «Yo lo monitoreo» es una promesa vacía si no tienes una traza que monitorear. Todo el modelo de observa-no-apruebes asume en silencio una capa de observabilidad que la mayoría de los equipos se saltaron construir.

Esa es exactamente la brecha que los proveedores empresariales corren a llenar. La nueva Control Tower de Hyland se vende como un centro de comando que rastrea a los agentes contra KPIs y puede pausar o ajustar a uno en tiempo real cuando cruza una barrera; y su Agent Lifecycle Management plantea a un agente como algo que gestionas desde el diseño hasta el retiro, no algo que lanzas y olvidas. Quítale el empaque empresarial y es la misma lección: escalar agentes sin supervisión no es escalar, es apostar.

Qué hacer en concreto

No necesitas una plataforma para tomarte el principio en serio. Incluso en un proyecto en solitario:

• Traza la sesión completa, no solo el resultado. Registra cada llamada a herramienta y cada decisión en orden, para que cuando algo salga mal puedas reproducir el camino en vez de adivinar. La salida final es lo menos informativo que vale la pena guardar.
• Vigila el «tuvo éxito pero está mal», no solo los errores. Tus alertas deben atrapar la falla semántica —el agente que devolvió 200 e hizo lo incorrecto—, lo que significa evaluar las salidas contra criterios, no solo verificar que corrió.
• Trata al agente como algo con un ciclo de vida. Va a derivar a medida que los modelos se actualizan y el mundo cambia; la mayor parte de esa deriva ocurre en silencio después del demo. Revísalo de forma periódica como revisarías cualquier sistema que pueda pudrirse sin avisar.
• Si no puedes verlo, no lo dejes actuar sin supervisión. La regla honesta: un agente que no puedes observar es un agente que no deberías tener haciendo nada importante por su cuenta.

En resumen

La historia emocionante sobre los agentes es la autonomía: van y hacen cosas sin ti. La verdad poco glamorosa es que la autonomía sin observabilidad no es independencia, es solo ceguera. A un agente que falla como software normal lo atraparías. A un agente que falla entregándote una respuesta equivocada, segura de sí misma y con palomita verde, solo lo atraparás si construiste la capacidad de mirar.

Así que antes de dejar que un agente opere algo que importa, hazte la pregunta llana: si hiciera lo incorrecto ahora mismo, ¿siquiera me enteraría? Si la respuesta es no, no tienes un agente en producción. Tienes uno sin monitorear, y eso es solo un incidente que todavía no se ha notado.