Agent Tracing

Agent Tracing es la práctica de registrar y relacionar eventos observables para reconstruir qué hizo una ejecución agente a través de turnos, herramientas, delegaciones, transferencias y resultados. El foco está en el recorrido y sus relaciones, no solamente en una colección de mensajes. La definición de trabajo del Atlas no exige un formato de trace ni un backend específico.

Un trace puede mostrar que se solicitó una operación, qué respuesta se obtuvo y cómo se conectó con otra acción. No demuestra por sí solo que el objetivo estaba bien interpretado o que el resultado es correcto. También puede ser parcial. La disponibilidad de una narración técnicamente ordenada no reemplaza evaluar la evidencia que contiene y los hechos que quedaron fuera.

Eventos observables y razonamiento privado

Los eventos relevantes pueden incluir límites de turnos del modelo, solicitudes y resultados de herramientas, delegaciones, handoffs, aprobaciones, errores y transiciones de estado. Son hechos que el sistema puede observar en sus interfaces y ejecución. No requieren registrar ni exponer private chain-of-thought.

Una explicación de decisión puede indicar que faltaba una autorización o que un resultado contradijo un supuesto, sin publicar razonamiento interno. Tampoco conviene inferir pensamientos privados a partir de una secuencia de acciones. El trace puede respaldar qué se solicitó y qué ocurrió; afirmar por qué el modelo produjo internamente una salida necesita otro tipo de evidencia y no es requisito de esta práctica.

Esta frontera permite revisión y diagnóstico sin convertir transparencia en captura indiscriminada. Lo útil es conservar la información necesaria para interpretar efectos y límites, con procedencia suficiente. Un texto generado que relata una herramienta nunca invocada no adquiere valor de evento real por estar dentro de un reporte.

Logging y relaciones de ejecución

Logging es un mecanismo general para registrar señales o eventos. Tracing enfatiza cómo se relacionan operaciones dentro de un recorrido. Puede utilizar logs, spans y otros eventos; no se opone a ellos ni redefine su concepto general. Un log con identificadores adecuados puede contribuir a una reconstrucción, mientras muchos mensajes sin correlación pueden dejar ambiguo qué solicitud produjo cada respuesta.

La pregunta específica es si el registro permite seguir la ejecución pertinente. Interesa distinguir tareas y runs, relacionar llamadas con resultados y reconocer interrupciones o cambios de responsabilidad. El orden textual de un archivo no siempre corresponde al orden causal cuando hay trabajo asíncrono o varias ejecuciones escribiendo simultáneamente.

Un estado final sin error puede informar sobre el proceso que lo emitió, no sobre toda la tarea. La relación con eventos anteriores permite descubrir que una comprobación se omitió, que un resultado era parcial o que otra ejecución produjo el artefacto. Esa interpretación necesita conocer qué instrumentación existe y qué significa cada evento.

Distributed Tracing como fundamento

Distributed Tracing es el concepto general de seguir operaciones entre componentes de un sistema. Agent Tracing aplica preguntas de recorrido a la ejecución agente, que puede ocurrir en un solo proceso o cruzar servicios. Puede reutilizar correlación y relaciones de tracing sin constituir una segunda definición del concepto de sistemas distribuidos.

La documentación de traces de OpenTelemetry describe spans, eventos y vínculos entre operaciones. Es una referencia de instrumentación general que puede aportar mecanismos de correlación. No establece un schema universal de agentes ni obliga a adoptar OpenTelemetry para que una ejecución tenga evidencia relacionable.

Una llamada remota y una delegación de trabajo tampoco son el mismo evento conceptual. Ambas pueden cruzar componentes, pero la delegación incluye responsabilidad y un resultado esperado. El trace necesita conservar la semántica pertinente del sistema, en vez de asumir que todos los cruces de proceso significan crear otro agente.

Identidad y correlación

Un recorrido útil permite identificar ejecución, tarea y operaciones relevantes. Si existen subagentes o handoffs, interesa conectar origen y destino sin perder los límites de cada participante. Los identificadores concretos dependen del runtime; el concepto no prescribe una jerarquía obligatoria de IDs ni una representación de mensajes.

La correlación evita interpretar la respuesta de una consulta como resultado de otra. También ayuda a distinguir un intento repetido de una operación diferente. Dos eventos con el mismo texto pueden pertenecer a revisiones o recursos distintos. Sin esa procedencia, el agente o el revisor pueden construir una explicación coherente sobre hechos que no corresponden al mismo caso.

En concurrencia puede no existir un orden total útil. Varias ramas avanzan con dependencias parciales. Las relaciones entre solicitud, inicio, resultado y agregación suelen aportar más que ordenar exclusivamente por timestamps. La evidencia debería conservar incertidumbre cuando faltan eventos o los relojes no permiten establecer el orden que interesa.

Herramientas y resultados

Tool Calling separa solicitud, ejecución y continuación. Un trace puede registrar esas fronteras y mostrar si una herramienta fue rechazada, falló, devolvió datos parciales o quedó pendiente. Invocar no equivale a completar, y una respuesta exitosa puede seguir siendo irrelevante para el objetivo.

También importa distinguir cancelación local de efecto remoto. Dejar de esperar una respuesta no demuestra que la operación no ocurrió. La evidencia de ese estado puede evitar repetir efectos por error y orientar Agent Checkpoints and Recovery. El trace informa sobre lo observado, sin prometer que pueda revertir la acción.

Los argumentos y resultados pueden contener datos sensibles o material excesivo. Conservar referencias, categorías de error o fragmentos pertinentes puede ser suficiente para el diagnóstico. Capturar todo por defecto aumenta exposición y volumen sin garantizar una reconstrucción más fiable. La selección depende de las necesidades reales de revisión.

Delegaciones y handoffs

Subagents and Delegation permite asignar trabajo acotado conservando una responsabilidad más amplia en el llamador. Agent Handoffs transfiere responsabilidad o control a otra ejecución. El trace puede mostrar ambas relaciones sin tratarlas como sinónimos ni deducirlas solo del nombre de una herramienta.

Interesa saber qué tarea se entregó, qué límites recibió el participante y qué resultado devolvió. Si el resultado se agregó o descartó, esa relación puede ser relevante para explicar el recorrido final. No hace falta registrar toda conversación interna para reconocer que una conclusión depende de evidencia producida por otro participante.

Un contexto enviado no demuestra que hubo un handoff efectivo. Un evento que solicita transferencia puede fallar antes de que el receptor acepte o continúe. Conservar esos estados evita asignar responsabilidad al participante equivocado cuando una tarea queda detenida entre dos ejecuciones.

Plan y estado observado

Planning organiza acciones futuras; el trace reconstruye acciones observadas. Un plan puede aportar referencias para interpretar intención, pero no es prueba de que se ejecutaron sus pasos. Un evento de cambio de estado puede mostrar progreso operativo sin demostrar aceptación de la tarea.

Agent Harness puede emitir transiciones, causas de detención y estados de solicitudes. La calidad del trace depende en parte de esa instrumentación y su correlación con operaciones reales. Un runtime puede describir de forma impecable una trayectoria que no satisface el encargo. El control técnico y la corrección semántica necesitan interpretarse por separado.

Cuando se restaura una ejecución puede ser importante distinguir eventos anteriores y posteriores al punto recuperado. Reutilizar identificadores o mezclar intentos sin esa relación puede hacer parecer que una acción ocurrió una sola vez cuando en realidad se repitió. El mecanismo concreto depende del sistema y no se configura aquí.

Tracing y observability

AI/LLM Observability tendrá un alcance más amplio sobre señales e investigación de aplicaciones y sistemas AI. Agent Tracing aporta una clase de evidencia sobre recorridos; no representa todo ese cuerpo de conocimiento. Tener un visor de traces no demuestra que existan los indicadores o condiciones necesarios para comprender el sistema en operación.

La distinción también limita este canonical. No define una arquitectura de telemetría, una política general de retención ni una plataforma de dashboards. Puede utilizar mecanismos existentes cuando la tarea necesita reconstrucción de eventos. La elección de infraestructura debe responder al caso de uso y no a la presencia del concepto en el mapa.

Tracing y Agent Evaluation

Agent Evaluation juzga comportamiento frente a criterios sobre tareas y runs. Un trace puede alimentar ese análisis: llamadas innecesarias, uso de evidencia, intentos fuera de alcance o terminación. El registro es dato; el juicio requiere criterios y contexto. Un trace extenso no equivale a una evaluación completa ni favorable.

Más eventos tampoco significan necesariamente mejor agente. Pueden reflejar trabajo útil o repetición improductiva. Un recorrido breve puede ser eficiente o haber omitido comprobaciones. La evaluación necesita relacionar la trayectoria con el resultado y el riesgo, sin convertir cantidad de llamadas o longitud del historial en una medida universal.

Para una modificación concreta, Generated Code Verification pregunta qué evidencia respalda su cumplimiento. Un trace puede confirmar que se ejecutó cierto comando; todavía importa qué comprobó y sobre qué revisión. Conservar esa frontera evita sustituir verificación por observabilidad de actividad.

Ejemplo: un resultado que parece contradictorio

Una ejecución informa que actualizó un documento y luego que el enlace sigue incorrecto. El trace muestra que la edición ocurrió sobre una copia local, mientras la lectura posterior consultó el sitio publicado. Ambas herramientas pueden haber funcionado correctamente y observar estados distintos. Sin correlación de destino y revisión, el agente podría intentar otra edición innecesaria.

Otra ejecución puede mostrar un check previsto sin evento de invocación ni resultado. Eso no permite afirmar que el check pasó. Puede estar pendiente o faltar instrumentación; la diferencia necesita comprobarse. El trace ayuda a formular la pregunta correcta sin fabricar evidencia a partir del plan.

Límites de una reconstrucción

La instrumentación puede omitir, muestrear o perder eventos. Una herramienta puede devolver menos información de la necesaria para decidir si hubo un efecto. La ausencia de un evento en un trace parcial no demuestra que la acción nunca ocurrió. Conviene conservar las condiciones de cobertura relevantes cuando afectan la conclusión.

Si cambia la instrumentación, comparar recorridos exige considerar qué eventos captura cada versión y cuáles dejaron de ser observables.

Development Context and Execution Records puede resumir evidencia para revisión y continuidad sin ser una copia completa del trace. Tampoco ese resumen es memoria activa o checkpoint por definición. Son artefactos con funciones distintas que pueden referenciarse cuando ayuda a entender el trabajo.

La práctica es útil cuando permite reconstruir decisiones operativas y efectos con suficiente fidelidad para investigar o evaluar. No necesita capturar pensamiento privado, definir toda observability ni imponer un stack de instrumentación. Su valor está en relaciones comprobables entre eventos, no en presentar una historia aparentemente completa sin límites visibles.

Fuentes

• OpenTelemetry: Traces, consultada el 2026-10-28: fundamento general de spans, eventos y vínculos. La aplicación a agentes es síntesis editorial del Atlas, sin schema de instrumentación obligatorio.