Microsoft’s Foundry team has added OpenTelemetry-based tracing to its agent framework, giving developers a way to see end-to-end execution across heterogeneous LLM-powered agents.

Por qué los sistemas multiagente necesitan algo más que archivos de registro (logs)

Un simulacro típico de respuesta ante incidentes impulsado por IA utiliza un agente comandante que orquestra varios agentes especialistas: uno analiza los logs, otro detecta anomalías en las métricas, un tercero vincula los síntomas con los runbooks, y un enrutador elige el mejor modelo de lenguaje para cada subtarea. Cada especialista puede llamar a un modelo diferente —por ejemplo, una variante “gpt-5-mini”— e invocar sus propias herramientas. Cuando algo sale mal, los ingenieros se quedan mirando logs aislados que muestran lo que hizo cada componente, pero sin una visión de cómo encajan todas las piezas.

Sin un trace unificado, la causa raíz se esconde en el traspaso entre agentes. El comandante podría enviar una solicitud que el lector de logs procesa correctamente, pero el especialista en métricas interpreta mal los datos y sugiere el runbook equivocado. Depurar esa cadena manualmente requiere tiempo y propicia errores.

Cómo OpenTelemetry une el flujo de trabajo

OpenTelemetry define dos conceptos fundamentales: traces y spans. Un trace es un identificador único que sigue una solicitud desde su entrada hasta la respuesta final. Un span registra una única operación —como una llamada a un modelo de lenguaje o una invocación de herramienta— dentro de ese trace.

Cuando un agente recibe una solicitud, extrae el Trace ID entrante de los metadatos de la solicitud y crea un child span que hereda el mismo ID. El child span registra su hora de inicio, duración, atributos (nombre del modelo, herramienta utilizada) y cualquier error. El proceso se repite para cada agente descendente (downstream), construyendo un árbol que refleja el flujo lógico de la tarea global.

OpenTelemetry también admite Baggage, un transportador ligero para pares clave-valor personalizados. Al adjuntar un “drill-id” u otro contexto de negocio al baggage en la parte superior del trace, cada span descendente hereda automáticamente ese identificador. Un procesador de spans luego promueve el baggage a atributos regulares, lo que facilita la consulta de todos los spans pertenecientes a un simulacro de incidente en particular.

Cómo es la nueva superficie de trazabilidad

Con la instrumentación implementada, Azure Monitor (o cualquier backend compatible con OpenTelemetry) genera una jerarquía visual:

  • Nombre / ID del agente – muestra qué componente realizó la operación.
  • Uso de herramientas – registra qué servicio o función externa fue llamada.
  • Versión del modelo – registra el LLM exacto utilizado, lo cual es útil para rastrear regresiones tras una actualización del modelo.
  • Consumo de tokens – captura cuántos tokens se enviaron al modelo y cuántos se recibieron, ayudando a los equipos a gestionar los costes.
  • Latencia / duración – resalta dónde aparecen los cuellos de botella, ya sea en la inferencia del modelo o en la E/S de las herramientas.

En el ejemplo del simulacro de incidentes, el root span del comandante genera child spans para cada especialista, y cada especialista genera más hijos para sus llamadas al modelo. Al hacer clic en cualquier nodo, se revela el conjunto completo de atributos, de modo que un ingeniero puede ver instantáneamente los detalles de cada operación.

Lo que está en juego para las operaciones centradas en IA

  • Velocidad del análisis de causa raíz – Los equipos rastrean un fallo hasta el span exacto que lanzó un error, reduciendo el tiempo medio de resolución.
  • Visibilidad de costes – El recuento de tokens aparece junto a la latencia, lo que permite al departamento financiero detectar un uso descontrolado antes de que las facturas de la nube se disparen.
  • Optimización del rendimiento – Los spans de alta latencia entre agentes señalan dónde el almacenamiento en caché, la selección de modelos o el rediseño de herramientas podrían aumentar el rendimiento.

Qué esperar a continuación

Los proyectos construidos sobre LangChain, el SDK de OpenAI u otras capas de orquestación pueden adoptar las mismas convenciones semánticas para GenAI, allanando el camino para traces que fluyan a través de proveedores de la nube y despliegues locales (on-premise).

Las organizaciones simplemente deben habilitar el SDK de OpenTelemetry en sus agentes y enviar los datos a Azure Monitor o a un colector de código abierto.

Conclusión

OpenTelemetry proporciona a los sistemas de IA multiagente el pegamento que les faltaba para convertir un conjunto disperso de logs en una narrativa coherente. Al propagar un único Trace ID a través de LLMs heterogéneos, enrutadores y llamadas a herramientas, los desarrolladores pueden localizar fallos, monitorizar costes y optimizar el rendimiento sin tener que reinventar la infraestructura de trazabilidad.