La observabilidad no es un add-on — es el orchestrator.

La mayoría de los equipos construyen primero el orchestrator y añaden observabilidad después. Nosotros hicimos lo contrario. El timeline de la traza existía antes que cualquier agent especialista, y cada agent que hemos lanzado desde entonces se construyó para escribir en él. Ese orden es por lo que podemos reproducir cualquier ejecución, auditar cualquier decisión y revertir cualquier cambio.

Construye el riel primero

Cuando construyes la traza segundo, cada agent que lanzaste antes tiene su propio formato de logging ad-hoc. Te pasas el siguiente trimestre escribiendo adapters. Cuando construyes la traza primero, cada agent nuevo hereda el formato porque no hay otro formato para elegir.

Qué contiene una traza

• trace_id y parent_id de la ejecución.
• Cada hand-off (qué especialista fue invocado, con qué entrada).
• Cada tool call (verbo, target, latencia, idempotency-key).
• Cada model call (prompt, respuesta, modelo, tokens, costo).
• Cada decisión (intent del router, confianza, estado de escalación).
• Cada resultado (éxito, soft-fail con advertencia, hard-fail con error).

Diseño replay-first

Como la traza es la fuente de verdad, podemos reproducir cualquier ejecución end-to-end. Eso es lo que hace tratable el testing de regresión sobre agents: lanza un nuevo especialista, reproduce las 10k trazas de ayer contra él, diffea las salidas, lanza o revierte.

La observabilidad también es una superficie de producto

Exponemos la traza en el dashboard del cliente. Cuando un usuario reporta un resultado raro, soporte pide el trace_id y lo miramos juntos. Eso cambia lo que significa ‘ticket de soporte’: no estamos adivinando logs, estamos mirando el mismo timeline que ve el cliente.

“La observabilidad no es una pestaña en el dashboard. Es el runtime dentro del cual viven tus agents.”