Un equipo que construye sobre Azure tiene las piezas enfrente —Azure AI Foundry, Semantic Kernel, modelos de Azure OpenAI— y un agente que funciona y hace lo correcto en una demo. La pregunta que decide si sobrevive al contacto con producción no es qué modelo eligieron. Es si, cuando tres agentes coordinan y el output está silenciosamente mal, alguien puede abrir el trace y ver por qué. En el stack de Microsoft la respuesta es buena, si lo cableas deliberadamente. Así encajan las piezas.
Este es el complemento específico de Azure al argumento general de que OpenTelemetry es el contrato de tracing. Los mismos instintos aplican en Google —lo escribimos por separado— y todo el punto de apoyarse en OTel es que los dos sigan siendo comparables.
La forma del stack
Cuatro capas, y ayuda mantenerlas distintas:
- Plataforma — Azure AI Foundry (el antiguo Azure AI Studio), incluyendo su servicio de agentes, es donde los agentes se construyen, despliegan y corren. Foundry tiene funciones de tracing y evaluación de primera clase; trátalas como la puerta de entrada, no como toda la casa.
- Framework — Semantic Kernel y AutoGen, ahora convergiendo en el Microsoft Agent Framework, son donde vive la lógica de orquestación. Esta es la capa que decide qué se vuelve un span.
- Modelos — Azure OpenAI (las series GPT y o) más el catálogo de modelos. El modelo es un componente; la evaluación lo elige, el trace lo vigila.
- Backend de telemetría — Azure Monitor y Application Insights, donde aterrizan traces, métricas y logs y donde de verdad los consultas.
Haz que hable OpenTelemetry, no solo Azure
La única decisión que mantiene sano a este stack es instrumentar en OpenTelemetry con las convenciones semánticas GenAI, y dejar que Application Insights sea el backend en lugar del formato. Semantic Kernel y el Agent Framework emiten OTel; Azure Monitor ingiere OTel nativamente. Así puedes tener la experiencia nativa completa de Azure —el tracing de Foundry, las consultas de App Insights, las herramientas de evaluación integradas— mientras los spans en sí siguen siendo telemetría estándar y portable.
¿Por qué insistir en esto si estás "en Azure de todos modos"? Porque el cliente regulado que quiere la telemetría guardada en su propio store, la plataforma de evaluación sobre la que quieres correr LLM-as-judge, y el futuro multi-nube al que aún no te comprometiste son todos baratos si el trace es OTel y caros si es un blob con forma de Application Insights. Usa el backend de Azure a fondo; no dejes que se vuelva lo único que puede leer tus traces.
Qué capturar en el span
Las herramientas de Azure registrarán con gusto las llamadas al modelo y la latencia. Los spans que de verdad salvan el turno de las 3 a.m. llevan más:
- Fronteras de agente y razonamiento — qué agente actuó, por qué eligió la tool que eligió, la confianza que adjuntó. El servicio de agentes de Foundry te da las fronteras; tú agregas el contexto semántico.
- Versiones — prompt, config de tool y revisión de agente en cada span, para que el drift de un agente adaptativo sea atribuible.
- Atributos de token y costo —
gen_ai.usage.*en cada generación, porque el costo en un agente de diez pasos se compone y Azure te factura cada token recomputado.
El Collector y Purview hacen la gobernanza
Para trabajo regulado —y muchas tiendas Azure lo son— pon un Collector de OTel entre los agentes y Application Insights y haz la redacción de PII ahí, una vez, antes de que la telemetría salga del perímetro. Combínalo con Microsoft Purview para la historia de gobernanza y linaje que piden los auditores. El patrón importa más que los nombres de producto: redacta en el Collector, gobierna en la plataforma, y el texto del prompt y los argumentos de tools que llegan al backend ya están limpios.
La evaluación honesta
El stack de Microsoft es un buen lugar para correr agentes con observabilidad real, y el camino integrado de Foundry-más-App-Insights es genuinamente conveniente —su principal riesgo es exactamente esa conveniencia—. Es fácil terminar con forma de Azure de arriba a abajo, traces incluidos, y descubrir el lock-in solo cuando quieres salir. Apóyate en la integración para la experiencia del operador; mantén los spans en OTel para que la experiencia sea una elección y no una jaula. Hazlo, y obtienes lo mejor del stack —el tracing de Foundry, el poder de consulta de App Insights, las evaluaciones integradas— sobre telemetría que aún puedes levantar y llevarte.
Cierre
En Azure, el modelo es la decisión fácil y el trace es la que decide si puedes operar la cosa. Foundry, Semantic Kernel y Application Insights te dan una historia de observabilidad real de fábrica —tómala, y mantén los spans en OpenTelemetry para que la historia siga siendo tuya—. Usa el stack de Microsoft a fondo. Solo asegúrate de que tus traces podrían dejarlo.