Problema
El registro muestra que un agente pidió un análisis, otro consultó un servicio y un tercero actualizó un dato. Cuando aparece un error, ordenar los mensajes por hora no explica qué solicitud produjo la escritura ni si hubo un reintento.
En trabajo concurrente, el orden temporal y la relación causal son cosas diferentes. Dos eventos cercanos pueden no estar relacionados; una acción tardía puede proceder de una tarea que el usuario creía cancelada.
Tesis
Traza las relaciones entre unidades de trabajo y sus efectos. OpenTelemetry define spans como operaciones con contexto, tiempos y relaciones; W3C Trace Context estandariza la propagación de contexto entre servicios. Es una base técnica para correlacionar, no una certificación de autorización o corrección.
La capa de aplicación debe añadir qué se pidió, con qué alcance y qué estado quedó al terminar. Esa información permite investigar sin convertir cada conversación en un registro indiscriminado de contenido sensible.
Framework
Conserva identidad causal
Asocia la solicitud principal con delegaciones, llamadas a herramientas y reintentos. El identificador de conversación puede ayudar a localizar contexto, pero no sustituye la identidad de una operación concreta. Un chat puede contener trabajos distintos y un trabajo puede atravesar varios canales.
Distingue el intento del efecto. Si una llamada devuelve un error de conexión después de que el servicio haya aplicado el cambio, repetirla puede duplicar la acción. El registro debe permitir consultar el estado final en el sistema de destino.
Registra las fronteras importantes
Marca cuándo cambia el responsable, cuándo se concede una aprobación y cuándo una tarea queda esperando. Incluye referencias a la versión de instrucciones o política que estaba activa. No hace falta conservar cada detalle interno del modelo para reconstruir decisiones observables.
La cancelación también necesita una relación causal. Registra qué ejecución recibió la orden y qué operaciones estaban ya en curso. «Cancelado» en la interfaz del coordinador no prueba que todos los servicios hayan detenido sus efectos.
Diseña acceso y retención
Las trazas pueden contener argumentos de herramientas, identificadores y fragmentos de documentos. Define qué se redacta, quién puede consultar el registro y durante cuánto tiempo. Conserva referencias cuando el contenido completo no sea necesario para investigar.
Reconstruir una reserva cuyo resultado se perdió
Diseña el registro alrededor de un caso: el servicio crea una reserva, pero la respuesta no llega al agente. La aplicación debe relacionar el intento con el efecto consultado después. Estos campos son una propuesta de aplicación; no son nombres normalizados por OpenTelemetry.
| Campo del expediente | Ejemplo ilustrativo | Para qué sirve |
|---|---|---|
| Operación empresarial | reserva-demo | Reconocer el compromiso que se intentaba crear |
| Intento | inicial o consulta-de-reconciliación | Distinguir ejecución y recuperación |
| Relación causal | solicitud que originó la delegación | Volver a la intención del usuario |
| Estado observado | respuesta-perdida | Evitar afirmar que la reserva falló |
| Referencia de destino | identificador devuelto al consultar | Vincular el efecto con el sistema responsable |
La traza técnica conserva spans y sus relaciones. Para trabajo asíncrono, OpenTelemetry describe enlaces entre spans; eso permite conectar una ejecución posterior con su origen sin fingir que todo ocurrió dentro de una única llamada.
Ensaya la pérdida de respuesta en un servicio de prueba. El registro debería mostrar solicitud, intento ambiguo, consulta del destino y resolución. Si la consulta confirma una reserva existente, la aplicación recupera su referencia; no inicia otra creación. Si el destino no permite determinarlo, el estado queda pendiente de reconciliación.
El identificador de operación debe ser estable para ese compromiso y debe validarse en la capa que evita duplicados. Compartir un trace_id no hace idempotente una API. Tampoco un log de «aprobado» acredita autorización si no remite al objeto y a la decisión válidos. Las trazas conectan evidencias; no sustituyen los controles que las producen.
Por qué importa ahora
La delegación distribuye el trabajo entre componentes con registros distintos. Sin correlación, cada equipo puede ver su operación como correcta mientras el resultado conjunto falla. La observabilidad útil reduce el tiempo necesario para localizar la frontera donde se perdió intención o estado.
Anti-ejemplo
Caso hipotético: un agente reintenta la creación de una reserva tras un timeout. El servicio había creado la primera, pero la respuesta se perdió. El registro solo muestra una llamada fallida y otra correcta; sin identidad de operación ni consulta del efecto, nadie detecta el duplicado.
Protocolo (3 pasos)
| Paso | Relación registrada | Pregunta que responde |
|---|---|---|
| Correlacionar | Solicitud, delegación e intento | ¿De dónde procede esta operación? |
| Confirmar | Intento y estado del destino | ¿Qué cambió realmente? |
| Investigar | Política, aprobación y cancelación | ¿Bajo qué condiciones ocurrió? |
Relacionado
- AI Traces: la capa que convierte agentes en sistemas auditables
- Agent Incident Response: cómo investigar un fallo cuando quien actuó fue un agente
Fuentes consultadas
Próximo paso
Selecciona un cambio producido por un agente e intenta recorrerlo hasta la solicitud original. Si solo puedes ordenar mensajes por fecha, añade relaciones causales antes de ampliar la delegación.