Un agente devuelve una respuesta incompleta. ¿Falló un documento o una herramienta? Los registros protegidos disponibles pueden ayudar a investigar la causa. Evalúa la calidad de la respuesta por separado.
Sigue una solicitud durante la ejecución
Imagina que el equipo de mantenimiento pide a un agente: «Revisa esta solicitud de reemplazo de equipo según la política vigente y el registro de inventario. Señala los datos que falten y prepara una recomendación para revisión. No hagas ningún pedido». El agente puede leer la solicitud, la política aprobada para reemplazos y el registro de inventario. Puede preparar un borrador, pero una persona decide qué hacer después.
La consulta al inventario agota el tiempo de espera. La traza registra el fallo y el borrador queda incompleto.
Campos y duraciones ilustrativos, no un esquema del SDK ni resultados medidos. Todas las filas: ejecución demo-042, configuración v3. Las categorías omiten contenido de la solicitud y datos personales.
Desplázate horizontalmente para ver todas las columnas.
| Paso | Fuente u operación | Resultado | Duración | Reintentos |
|---|---|---|---|---|
| 1 | Leer solicitud presentada | Correcto | 120 ms | 0 |
| 2 | Leer política aprobada de reemplazos | Correcto | 80 ms | 0 |
| 3 | Consultar inventario | Tiempo de espera agotado | 2.000 ms | 0 |
| 4 | Preparar borrador para revisión | Incompleto: inventario sin verificar | 350 ms | 0 |
Estado final: La ejecución automática se detuvo con un borrador incompleto; la decisión de negocio sigue pendiente de revisión. No se invocó ninguna operación de pedido. La traza muestra que se agotó el tiempo de espera al consultar el inventario. No explica por qué ni permite saber si el borrador es correcto.
Proporción de ejecuciones con tiempo de espera agotado al consultar inventario
Ejecuciones con al menos una consulta de inventario que agotó el tiempo de espera ÷ ejecuciones que intentaron consultar el inventario durante el mismo período.
- Cuenta cada ejecución una sola vez, aunque haya reintentos.
- Excluye las ejecuciones que nunca intentaron consultar el inventario.
- Informa cuántas ejecuciones carecen de telemetría.
Día ilustrativo: 4 / 50 = 8 %. Esta medida describe un problema operativo, no la calidad de las respuestas.
Una ejecución produce eventos que se pueden investigar.
Elige señales que respondan preguntas operativas
Desplázate horizontalmente para ver todas las columnas.
| Señal | Qué puede ayudar a responder | Qué conviene verificar |
|---|---|---|
| Identificador de ejecución y versión de configuración | ¿Qué tarea y configuración generaron este resultado? | ¿Se puede vincular una ejecución con el trabajo, la fecha y la configuración activa sin exponer contenido innecesario? |
| Resultado de cada paso y herramienta | ¿Qué fuentes se leyeron, qué herramientas se ejecutaron y dónde se detuvo el flujo? | ¿Se distinguen los pasos correctos, fallidos y omitidos? ¿Se ven las denegaciones de permisos? |
| Duración y reintentos | ¿La ejecución se retrasó, se repitió o quedó incompleta? | ¿Se distingue un reintento seguro de repetir una acción con efectos secundarios? |
| Estado de la derivación y finalización | ¿El caso pasó a una persona u otro sistema? ¿Se aceptó o se terminó el trabajo? | ¿Los registros distinguen «enviado», «aceptado», «completado» y «sin resolver»? Consulta la guía de transferencias entre sistemas para definir el acuse y el estado de finalización del sistema receptor. |
| Señales de recursos y uso | ¿Qué ejecuciones consumieron más recursos de cómputo o usaron más servicios externos de lo previsto? | ¿Qué uso queda registrado, cuándo están disponibles esos datos y cómo se relacionan con los registros de facturación? |
Una traza sigue la solicitud hasta el fallo. Una métrica muestra con qué frecuencia ocurre. Un registro de eventos recoge la consulta fallida.
Comprueba qué captura tu sistema: algunos omiten entradas, resultados de herramientas o tipos de registro completos. El acceso, la retención y la exportación determinan qué puedes consultar.
Separa la observabilidad de la evaluación
Usa los registros de ejecución para preguntar qué pasó: qué fuente falló, si se llamó a una herramienta o cuándo ocurrió una derivación. Usa un conjunto de evaluación y criterios de revisión para saber si el resultado cumplió con el trabajo. Una traza completa puede documentar una respuesta deficiente; una ejecución con una traza breve puede producir un buen borrador.
Antes de una prueba piloto, elige algunos casos relevantes: una solicitud habitual, una fuente no disponible, información contradictoria y una solicitud fuera del trabajo. Para cada caso, define qué señal mostraría el resultado y quién lo investigaría. Revisa el costo o el uso junto con el trabajo completado y comprobado, no como una señal aislada de calidad. Consulta cómo evaluar un agente de IA y gobernanza y controles de costos.
Protege los registros además del flujo
Los registros pueden contener instrucciones, extractos de fuentes, identificadores, resultados de herramientas y otros datos sensibles.
- Conserva los campos necesarios para diagnosticar la ejecución.
- Limita el acceso y establece una retención apropiada para el trabajo.
- Enmascara u omite los datos sensibles innecesarios.
Si los registros no explican una decisión importante, añade una etapa de revisión. La falta de telemetría no demuestra que no pasó nada.
En AgentShelf
Investiga ejecuciones con los registros disponibles de actividad, errores, uso y costos en rutas compatibles. La disponibilidad de proveedores, la cobertura de registros, la respuesta ante fallos y la retención varían según la configuración.