AgentOps: observar el razonamiento, no solo el resultado
Respuesta rápida:
Con un modelo que responde, basta con guardar la respuesta. Con un agente que actúa, la respuesta es lo último que pasa y casi nunca es donde está el fallo.
Cuando un agente da un resultado incorrecto, la pregunta útil no es «qué contestó», sino «por qué decidió eso». Y esa pregunta solo tiene respuesta si se ha instrumentado el camino, no el destino.
Lo que se pierde guardando solo la respuesta
Un agente resuelve una petición en varios pasos: descompone la tarea, elige fuentes, descarta algunas, llama a una herramienta, evalúa lo que recibe y decide si sigue. Si el registro solo contiene la entrada y la salida, todo eso desaparece.
Cuando llegue el incidente —y llegará— el equipo tendrá que reproducirlo a mano, con un modelo no determinista que quizá ya no decida lo mismo. Es el equivalente a depurar un sistema distribuido con un único print al final.
Qué hay que instrumentar
Cada paso de razonamiento, como una traza
El patrón que funciona es el de la traza distribuida: la petición es una traza y cada paso un tramo. Por cada tramo conviene registrar qué se decidió, con qué entrada y cuánto tardó. No hace falta inventar nada: OpenTelemetry sirve, y el equipo de plataforma ya sabe leerlo.
Cada llamada a herramienta
Qué herramienta, con qué parámetros, qué devolvió y si falló. Aquí es donde aparecen la mayoría de los problemas reales: la API que cambió su contrato, el tiempo de espera que se agota, el parámetro que el agente rellena mal de forma sistemática.
El coste, en la misma traza
Tokens de entrada y salida, modelo utilizado y coste estimado por paso. Puesto junto al resto, permite ver que el 80 % del gasto viene de un único reintento que nadie había mirado. Separado en otro panel, no lo ve nadie.
La evidencia que sostuvo la decisión
Qué fuentes consultó y cuáles usó para responder. Sin esto es imposible distinguir entre un modelo que alucina y un modelo que respondió correctamente a partir de un dato que estaba mal. Son dos problemas distintos, con dos arreglos distintos, y se confunden constantemente. Es la misma trazabilidad que exigimos a cualquier dato en un entorno multi-cloud, aplicada al razonamiento.
Las señales que de verdad avisan
Hay cuatro indicadores que anticipan casi todos los incidentes:
- Tasa de intervención humana. Si sube, el agente ha empezado a fallar en casos que antes resolvía.
- Pasos por tarea. Un agente que necesita el doble de pasos para lo mismo está dando vueltas.
- Coste por transacción. Sube antes que cualquier otra señal cuando algo entra en bucle.
- Deriva de la evidencia. El agente empieza a apoyarse en fuentes distintas para las mismas preguntas: algo cambió aguas arriba.
Ninguna de las cuatro requiere tecnología nueva. Requieren decidir que se miran.
Cortes automáticos: cuándo parar al agente
Observar sin poder actuar sirve de poco. Tres cortes que conviene tener desde el primer día:
- Tope de pasos y de gasto por tarea. Si se supera, la tarea termina y escala a una persona.
- Retirada de credenciales ante comportamiento anómalo, como un número de llamadas muy por encima de lo normal. Solo es posible si cada agente tiene identidad y permisos propios.
- Parada por regla de negocio: acciones que nunca deben ejecutarse sin confirmación humana, por mucha confianza que declare el agente.
El corte no es un fallo del sistema: es el sistema funcionando. Un agente que nunca se detiene no es un agente fiable, es uno al que nadie vigila.
Quién mira todo esto
El error organizativo habitual es dejar la observabilidad en manos del equipo que construyó el agente. Funciona mientras hay uno. Con quince, hace falta un sitio único donde se vean todos, con los mismos indicadores, y alguien que lo mire con la misma disciplina con la que se miran los sistemas de producción.
Aquí aplica lo mismo que en cualquier producto de datos: si no tiene dueño y tablero, no está en producción, está en pruebas prolongadas.
Cómo puede ayudar Galde
Instrumentamos los agentes que construimos con Palantir AIP con trazas por paso, coste por transacción y cortes automáticos, y dejamos los tableros en manos del equipo interno. Lo hacemos con el mismo criterio con el que llevamos la IA con Palantir AIP a producción: nada se considera terminado hasta que alguien puede explicar por qué el sistema decidió lo que decidió.
Conclusión
Un agente sin observabilidad no es un agente autónomo: es un agente sin supervisión, que no es lo mismo. La diferencia entre las dos cosas es exactamente la capacidad de reconstruir una decisión después de que ocurra.
Instrumentar el razonamiento cuesta unos días al principio del proyecto. Reconstruirlo a posteriori, sin datos, cuesta semanas y a veces no se consigue.
Preguntas frecuentes
¿Qué es AgentOps?
Es la práctica de operar agentes de IA en producción: instrumentar sus pasos de razonamiento y llamadas a herramientas, vigilar coste y deriva, y disponer de mecanismos para detenerlos cuando se comportan de forma anómala.
¿En qué se diferencia de la observabilidad tradicional?
En que el objeto observado no es solo la infraestructura, sino la decisión. Además de latencia y errores, hay que registrar qué pasos siguió el agente, qué fuentes usó y qué herramientas llamó, porque el fallo suele estar ahí y no en el servidor.
¿Hace falta una herramienta específica?
No necesariamente. Con trazas distribuidas estándar y un panel de métricas se cubre la mayor parte. Lo que hace falta es decidir qué se registra en cada paso, que es una decisión de diseño, no de compra.
¿Qué señal avisa antes de un incidente?
El coste por transacción. Sube antes que la tasa de error cuando un agente entra en bucle o empieza a reintentar, y por eso conviene tenerlo en el mismo panel que el resto de indicadores.
