Cuando el panel de control muestra estado verde y el agente está equivocado: seguimiento del estado

Un panel verde y una respuesta incorrecta

Depurar agentes de IA tiene una peculiaridad molesta: la pantalla de monitoreo puede indicar que todo está bien. La llamada al modelo se completó, las herramientas terminaron su trabajo, las APIs respondieron con códigos 200, la latencia parece normal y el uso de tokens está en los niveles esperados. Desde la perspectiva de la infraestructura no está ocurriendo nada, y aun así el resultado final puede estar completamente equivocado.

Ese no es el tipo obvio de error, en el que un modelo inventa algo absurdo. Esos fallos son más fáciles de manejar porque al menos sabes por dónde empezar. El tipo más difícil es aquel en el que cada paso parece razonable, no hay fallos técnicos y la respuesta es lo suficientemente creíble como para que alguien pueda actuar en base a ella.

El problema se agrava a medida que los sistemas evolucionan de simples llamadas a LLM a agentes y flujos de trabajo de múltiples pasos. Antes de que aparezca una respuesta, la información subyacente puede haber pasado por varios modelos, herramientas, APIs, transformaciones y enrutadores, por lo que el modelo final podría estar realizando un trabajo perfecto con datos que ya estaban dañados cinco pasos atrás. Este aspecto de la observabilidad de los agentes necesita mucha más atención de la que recibe.

Un cambio de esquema que nadie nota

Considere una tarea habitual de gestión del éxito del cliente. Se le pide al agente que encuentre clientes cuyas renovaciones tengan lugar dentro de 30 días, marque las cuentas que parezcan estar a punto de abandonar el servicio y redacte un informe para el equipo de éxito. En el proceso, puede consultar un CRM, calcular una puntuación de riesgo, obtener hilos de soporte recientes, verificar el uso del producto y, finalmente, pedir a un LLM que escriba el informe.

Ahora supongamos que el CRM modifica uno de sus esquemas de respuesta. Ayer, la carga de datos se veía así.

{
  "health_score": 42
}

Hoy se ve así.

{
  "health": {
    "score": 42
  }
}

La API sigue funcionando, la solicitud sigue teniendo éxito y el JSON sigue siendo procesado. Dependiendo del código de integración, no es necesario lanzar ninguna excepción en ningún lugar. El problema aparece más tarde, cuando la capa de normalización sigue buscando health_score y el paso siguiente recibe el valor null.

Tal vez la función de evaluación de riesgos interprete un valor faltante como neutral, o quizás las instrucciones indiquen utilizar lo que haya disponible. En ambos casos, el flujo de trabajo continúa y termina con un informe creíble que omite una cuenta de la que el equipo necesitaba tener conocimiento.

Al centrarse en la generación final, el modelo se convierte fácilmente en el culpable, y la gente termina reescribiendo las instrucciones, cambiando de modelo o ajustando la temperatura sin abordar la verdadera causa. Una pregunta mejor sería cuándo se produjo por primera vez el error en el estado, y con esa pregunta depurar a un agente resulta muy diferente.

Los eventos de éxito no demuestran comprensión

Un ensayo reciente sobre cómo la web se está convirtiendo en una API para agentes describe cómo el software pasa de informar datos a actuar en nombre del usuario. Afirma que exponer herramientas a un modelo es solo una parte del proceso, ya que la intención, los permisos, los controles en tiempo de ejecución y la posibilidad de auditoría son importantes una vez que los agentes realizan acciones reales.

Lo mismo ocurre con la depuración de esas acciones. Aunque es útil saber qué herramienta se ejecutó, eso no revela si el resto del flujo de trabajo comprendió lo que generó dicha herramienta. Imagine un registro que contenga esta información.

crm.search_accounts
status: success
duration: 184ms
records: 47

Lo que se puede concluir es que el CRM respondió con 47 registros. Lo que sigue sin saberse es si los 47 llegaron intactos a la siguiente etapa. Quizás existían seis páginas más y la paginación terminaba después de la primera. Tal vez una cantidad se convirtió de dólares a centavos, o una marca de tiempo UTC se interpretó posteriormente como hora local. Quizás un valor enumerado cambió su escritura de “cancelled” a “canceled”, o una API comenzó a reportar errores a nivel de aplicación dentro de una respuesta cuyo estado HTTP parecía correcto.

Son simples errores de software, nada más. Con los agentes, lo complicado es que el modelo siguiente suele seguir adelante sin importar nada, aceptando datos que parecen creíbles y razonando sobre ellos. Por lo tanto, un modelo más avanzado no necesariamente arreglará nada. Si la información de entrada está incorrecta desde el principio, el modelo simplemente resuelve el problema equivocado con mayor habilidad.

En los puntos críticos, debería ser posible observar la entrada, la salida, la transformación aplicada a la respuesta y qué se obtuvo en el paso siguiente. No es necesario conservar para siempre todo el contenido bruto; sí lo es guardar lo suficiente como para reanudar el proceso tras un fallo.

Rastreo de un competidor ausente

Las herramientas están mejorando. Las convenciones semánticas GenAI de OpenTelemetry comienzan a estandarizar la forma en que se describen las llamadas a modelos y la ejecución de herramientas, y frameworks como el OpenAI Agents SDK rastrean las generaciones, las llamadas a herramientas, las transferencias de datos y las restricciones. Eso constituye material bruto útil, pero sigue siendo difícil hacer que el rastreo sea útil cuando el flujo de trabajo se ha completado y el fallo real está oculto en el estado transmitido entre dos pasos funcionales.

Considere un proceso simplificado como el que se muestra.

Supongamos que el informe final carece de un competidor que obviamente debería estar incluido. El instinto anterior era abrir la instrucción final y examinar la respuesta del modelo. Quizás las instrucciones no eran lo suficientemente claras, o el modelo ignoró parte del contexto, o otro modelo habría rendido mejor. Empezar por ahí ya no es la opción adecuada.

En su lugar, trabaje hacia atrás. ¿El modelo final incluyó al competidor faltante? Si no, ¿ocurrió algo en el paso de clasificación? Si desapareció antes de la clasificación, ¿estaba presente después de la extracción? Estar presente después de la extracción pero ausente después de la normalización significa que el fallo se produce exactamente en un punto de transición.

{
  "company": "Example Corp",
  "website": {
    "url": "https://example.com"
  }
}

mientras que el paso de normalización esperaba esto.

{
  "company": "Example Corp",
  "website": "https://example.com"
}

Nada de eso fue dramático. A mitad del proceso, un objeto cambió de forma y un paso lo manejó mal, pero la mayoría de las operaciones cercanas seguían funcionando bien. Errores como este merecen ser rastreados, ya que de lo contrario la culpa recae en el componente más visible, sin importar lo que ocurrió anteriormente.

La lección práctica no es que se necesite un producto específico de observabilidad. Es que un rastreo debe permitirte seguir el estado a lo largo del flujo de trabajo, y no limitarse a listar qué componentes se ejecutaron. Hay una gran diferencia entre saber que se ejecutó el Paso 4 y saber qué recibió el Paso 5 de él.

El desvío del plan parece razonable

Una vez que se localiza un fallo relacionado con los límites de la herramienta, este es bastante evidente. El desvío en la planificación es más complicado, ya que un agente puede abandonar la tarea original siguiendo pasos que, individualmente, parecen razonables. Imagine que a un agente se le pide que investigue a cinco proveedores, evalúe sus precios y fiabilidad y redacte una recomendación, con la instrucción de no ponerse en contacto con ellos.

El agente encuentra a los proveedores y comienza a recopilar datos. Dos de ellos no indican precios, por lo que busca otra forma de solucionarlo. Finalmente descubre una herramienta de correo electrónico disponible. Su lógica no es absurda: se necesitan precios, estos no son públicos y un mensaje al proveedor resolvería el problema. Sin embargo, también infringe una de las reglas más importantes de la tarea.

Cuando la regla es solo una oración cerca de la parte superior de una ventana de contexto en expansión, todo depende de que el modelo siga considerándola importante después de que se hayan acumulado miles de tokens de resultados de búsqueda, salida de herramientas y estados intermedios. Las restricciones con consecuencias reales merecen una forma explícita.

{
  "objective": "Compare suppliers and prepare a recommendation",
  "constraints": [
    "Do not contact suppliers"
  ],
  "completed_steps": [
    "discover_suppliers",
    "collect_public_pricing"
  ],
  "next_action": "request_missing_prices",
  "requested_tool": "send_email"
}

Ahora la aplicación tiene algo que verificar antes de que se ejecute una acción. Puede rechazar la solicitud del herramienta, solicitar aprobación humana o enviar al agente a buscar otra ruta. La respuesta adecuada depende del flujo de trabajo, pero lo importante es que la restricción ya no reside únicamente en la redacción de la instrucción.

Reglas como un límite de gasto, “redactar pero no enviar” o “nunca tocar la versión en producción” funcionan de la misma manera. El lenguaje sencillo es útil para transmitir lo que pretende el usuario, pero los permisos y límites relevantes también deben convertirse en controles en tiempo de ejecución.

El software maneja esto en todos los demás casos. Nadie escribiría “por favor, no permita que los usuarios no autorizados eliminen la base de datos” en un comentario y lo llamaría control de acceso, y los agentes no merecen una exención solo porque sus instrucciones están en inglés.

El enrutamiento de modelos establece un límite

El enrutamiento genera un problema similar. Elegir un modelo deja de ser simplemente un valor de configuración una vez que es necesario equilibrar la calidad, el costo, la latencia, el uso de herramientas y las diferentes capacidades del modelo en todo el sistema de producción, y la decisión de enrutamiento pasa a formar parte del rastro necesario para la depuración.

Supongamos que el Paso 6 suele ejecutarse en el Modelo A. Durante una ejecución en tiempo real, el proveedor tiene un límite de velocidad, por lo que el enrutador cambia al Modelo B. Eso es el mecanismo de respaldo que funciona según lo diseñado, ya que el flujo de trabajo sigue activo en lugar de fallar. Sin embargo, el Modelo B formatea ligeramente de manera diferente los argumentos estructurados para la siguiente herramienta. Estos siguen siendo válidos y la herramienta funciona correctamente, pero un campo se lee de tal forma que altera el resultado posterior.

Si los informes de observabilidad solo muestran el modelo configurado para el flujo de trabajo, alguien podría pasar horas intentando reproducir el fallo en el Modelo A, cuando en realidad fue el Modelo B el que atendió la solicitud que causó el problema. Por lo tanto, un rastro debe registrar el modelo solicitado, el que respondió, cualquier solución alternativa, la política de enrutamiento activa y si la llamada fue un intento de reintentar. No se trata de información emocionante, pero la mayoría de las herramientas útiles para depurar en producción tampoco lo son. Más allá de las demostraciones, gran parte del trabajo consiste en descubrir qué detalle poco llamativo cambió sin que se notara.

Estado del rastro, y no solo eventos

Las herramientas de agente ahora realizan un buen trabajo al mostrar la estructura de una ejecución, con llamadas a modelos, herramientas, transferencias, intentos de repetición y otros eventos en vistas de seguimiento cada vez más útiles. El error sería asumir que registrar más eventos genera automáticamente una buena capacidad de observabilidad. Una ejecución con diez segmentos perfectamente instrumentados sigue resultando problemática si no se puede determinar qué estado cambió entre ellos.

Una breve lista de preguntas ayuda a analizar una ejecución fallida. ¿Qué quería originalmente el usuario? ¿Qué restricciones se aplicaron? ¿Qué plan siguió el sistema? ¿Qué devolvió cada herramienta y qué recibió el siguiente paso? ¿Qué modelo tomó cada decisión? ¿Cambió algo en el mundo exterior? ¿Dónde dejó de coincidir la salida con las expectativas?

Responder a estas preguntas requiere menos datos que registrar todo, y capturarlo todo conlleva sus propios problemas. Los comandos, los argumentos de las herramientas y sus respuestas pueden contener datos privados de los clientes, credenciales u otro contenido sensible que no debería llegar a una plataforma de observabilidad sin una evaluación previa. La guía de GenAI de OpenTelemetry señala esto, y su detallada especificación de spans hace que la captura de las entradas y salidas del modelo sea opcional y no algo predeterminado.

Por lo tanto, el objetivo es poder reconstruir las partes relevantes de una ejecución, no registrarla en su totalidad. A veces basta con una respuesta censurada, otras veces con la versión del esquema más un ID de objeto, y en ocasiones se necesita un snapshot de un resultado intermedio porque nada más puede reproducir la ejecución. Toma una decisión deliberada para que, en caso de incidente, no quede como única evidencia un status: success.

Qué significa esto para la evaluación

Una huella explica lo que sucedió, pero no si el resultado fue bueno, por lo que la evaluación sigue siendo necesaria. Anthropic sostiene lo mismo en su artículo sobre evaluaciones de agentes. Es más difícil calificar a los agentes que a las respuestas individuales, ya que operan a lo largo de varias interacciones, utilizan herramientas, modifican el estado y se adaptan a lo que ocurrió anteriormente.

Algunos resultados pueden verificarse sin necesidad de un modelo adicional. Un agente al que se le indicó no enviar un correo electrónico y que lo envía ha fallado, y una tarea de extracción diseñada para devolver 27 registros y que solo devuelve 11 está claramente desviada. Otros casos son más ambiguos: ¿Fue un informe de investigación lo suficientemente exhaustivo? ¿Eran fiables las fuentes? ¿Resolvió la respuesta del servicio de soporte el problema del cliente? Para estos casos, puede ser necesario un examen humano, comentarios de los usuarios, conjuntos de datos o herramientas de evaluación basadas en modelos.

El verdadero valor proviene de combinar la evaluación con el seguimiento del proceso. Un voto negativo junto a una respuesta final almacenada solo indica que al usuario no le gustó. Al estar vinculado a todo el proceso, la misma señal permite examinar el material recuperado, las herramientas utilizadas, los modelos involucrados y el punto en el que cambió el estado.

Una vez que se identifica la verdadera causa del fallo, esa ejecución mantiene su valor después del incidente, ya que puede convertirse en un caso de evaluación que sirve para evitar que se repita tras futuros cambios en los prompts, modelos o flujos de trabajo. Es mucho mejor que corregir respuestas defectuosas una por una con la esperanza de que nada más falle.

Deje de empezar por el prompt final

Probablemente el cambio más importante en la depuración de sistemas de IA es este. En una aplicación sencilla de LLM que da una respuesta incorrecta, leer el prompt y la respuesta es razonable, ya que hay pocos otros lugares donde pueda residir el problema. A medida que los sistemas crecen, ese hábito deja de ser tan útil. Imagine una cadena de procesos que cuenta con varios modelos, herramientas de recuperación e búsqueda, APIs externas, enrutadores y un bucle de verificación: su último prompt podría ser simplemente el lugar donde finalmente surgió un error anterior.

RAG ya ha dado la lección. Cuando la recuperación introduce el documento incorrecto en la ventana de contexto, un modelo de generación más avanzado no lo corregirá, por lo que hay que volver atrás para arreglar la recuperación. Los agentes siguen la misma lógica pero con límites adicionales. ¿La recuperación está bien? Mira qué resultado se obtuvo. ¿Ese también está bien? Observa la siguiente decisión. ¿Se eligió la herramienta adecuada? Revisa los argumentos y la salida. ¿El estado sigue siendo correcto? Sigue avanzando hasta encontrar el primer punto en el que difiere de lo esperado.

Suena sencillo en teoría, pero la gente lo olvida porque la respuesta final es lo que tienen delante y, por lo general, es lo más fácil de culpar.

Observabilidad para todo el proceso

Los agentes se volverán cada vez más complejos. MCP les brinda más herramientas, los diseños multiagente incluyen delegación y transferencias de tareas, los enrutadores eligen modelos en tiempo real, y los flujos de trabajo de larga duración permiten un estado persistente, así como intentos repetidos y reanudaciones. La aprobación humana puede interrumpir un proceso, y los agentes que se usan en navegadores o computadoras pueden modificar sistemas mucho más allá del ámbito de un chat. Todo esto hace que los agentes sean más capaces, pero también aumenta las posibilidades de que surjan errores, mientras cada componente informa sobre éxitos.

Por eso la observabilidad debe ir más allá de las métricas de los LLM. La latencia, el conteo de tokens, los errores y el costo son importantes, y un panel de control debería alertar cuando un agente entra en bucle y consume créditos de la API a las 2 a.m. Sin embargo, estas cifras solo indican si el sistema está funcionando. Un agente de múltiples pasos también necesita una forma de confirmar que lo que procesa sigue siendo adecuado para la tarea del usuario.

En la práctica, eso significa rastrear la intención inicial, las restricciones clave, las herramientas y modelos que realmente se utilizaron, el estado transferido entre pasos y el resultado final. Ante un resultado incorrecto, se debe poder retroceder hasta el primer punto en el que el estado se desvió de la realidad. Con esta capacidad, un proceso fallido se convierte en un problema de ingeniería ordinario que se puede investigar, reproducir y probar. Sin ella, uno solo puede mirar la respuesta final e intentar adivinar qué parte del sistema falló antes.