Microsoft cierra la parte que faltaba para llevar agentes a produccion: aislamiento de red real, identidades para MCP, voz integrada y evaluaciones continuas. Repaso lo que cambia y como migrar.

Figura: Componentes de un agente en Foundry Agent Service (fuente: learn.microsoft.com)

El 16 de marzo de 2026 Microsoft anuncio la disponibilidad general de Foundry Agent Service. Y no es una nota menor. Hasta ahora muchos equipos teniamos agentes funcionando en preview, pero a la hora de pasarlos a produccion aparecian las dudas de siempre: como aislo la red, como gestiono identidades cuando el agente llama a un MCP corporativo, como se si el agente sigue respondiendo bien despues de la primera semana. El GA viene a tapar justo esos huecos.

En este articulo repaso lo que cambia con esta version, que funciona ya y que sigue en preview, y dejo un par de ejemplos para que se vea como encaja todo.

Que es exactamente Foundry Agent Service

Es el runtime gestionado de Azure AI Foundry para construir y operar agentes en produccion. Lo importante de esta GA es que se ha reescrito sobre el protocolo Responses API de OpenAI, asi que los agentes existentes migran con cambios minimos en codigo. La arquitectura sigue siendo deliberadamente abierta: puedes combinar modelos de distintos proveedores (DeepSeek para planificacion, OpenAI para generacion, LangGraph para orquestacion) bajo una capa de consistencia unica.

Y eso es lo que mas me gusta del enfoque. No te casa con un solo modelo.

Networking privado de extremo a extremo

Esta es la novedad que mas interesa a banca, sanidad y administracion publica. Foundry Agent Service ya soporta despliegues con BYO VNet (Bring Your Own VNet) y cero egreso a internet publico. El aislamiento no se queda en la inferencia: se extiende a toda la cadena de herramientas que usa el agente.

Que entra dentro de ese perimetro:

• Servidores MCP corporativos.
• Indices de Azure AI Search.
• Fabric data agents.
• Llamadas a recursos Azure mediante container injection.

La parte de container injection es interesante porque permite comunicacion local con recursos Azure manteniendo los limites de red. Si tu equipo de seguridad lleva meses bloqueando proyectos por el tema del egreso, esto les va a quitar un dolor de cabeza importante.

Figura: Arquitectura de red privada con BYO VNet, agent subnet y private endpoints (fuente: learn.microsoft.com)

Ojo con el tamano de subred: la subred delegada para el agente debe ser de /24 (Microsoft recomienda este tamano por la delegacion a Microsoft.App/environments) y no se puede compartir entre varios recursos Foundry. Si vas a montar varios proyectos, una subred dedicada por proyecto.

Cuatro formas de autenticarte contra MCP

Aqui Microsoft ha hecho los deberes. Conectar un servidor MCP ya no es solo meter una API key y rezar. Hay cuatro modos:

Key-based authentication. El de toda la vida, valido para herramientas internas donde la rotacion manual no es un problema.

Entra Agent Identity. Pensado para autenticacion servicio-a-servicio. El agente tiene su propia identidad en Entra, igual que la tendria una managed identity para una App Service.

Managed Identity. Permite aislar permisos por proyecto sin la sobrecarga de gestionar credenciales. Si vienes del mundo Azure tradicional esto te suena, porque es exactamente la misma idea aplicada al runtime de agentes.

OAuth Identity Passthrough. El mas interesante para escenarios de usuario final. El agente actua en nombre del usuario que ha iniciado sesion, accediendo a sus datos personales o a SaaS conectados (Outlook, Salesforce, lo que sea). Sin esto, escenarios tipo «agente que lee mi correo» eran un hack o una pesadilla de cumplimiento.

Voice Live: voz en tiempo real, integrada de serie

Voice Live entra en preview con esta GA y la propuesta es simple: hablar con tus agentes igual que hablas con una persona, sin montar tu la pipeline de speech-to-text, NLU, text-to-speech y vuelta.

Lo que trae integrado:

• Deteccion de actividad de voz semantica (no solo por silencio).
• Reconocimiento de fin de turno.
• Supresion de ruido en el servidor.
• Cancelacion de eco.
• Soporte de barge-in (puedes interrumpir al agente, como con Alexa).

Lo importante es que las interacciones de voz pasan por el mismo runtime de agente que las de texto. Mismo agente, misma observabilidad, mismas evaluaciones, mismo trazado. No tienes dos sistemas paralelos que mantener.

Casos de uso? Soporte telefonico, kioscos, asistentes en coche, accesibilidad. Todo lo que pedia a gritos no tener que orquestar tres servicios distintos.

Evaluaciones enterprise: tres niveles

Las evaluaciones pasan a GA con tres capas que cubren desde el desarrollo hasta produccion.

Evaluadores listos para usar. Coherencia, relevancia, groundedness, calidad de retrieval y seguridad. Sin configurar nada. Para mi el mas util del dia a dia es groundedness, sobre todo cuando metes RAG por medio.

Evaluadores personalizados. Aqui codificas criterios propios: logica de negocio, tono corporativo, requisitos de cumplimiento. Si tu equipo de marca tiene reglas de como debe hablar el bot, las metes aqui.

Monitorizacion continua en produccion. Esto es lo que separa un proyecto serio de un experimento. El servicio toma muestras del trafico real, ejecuta los evaluadores y publica los resultados en Azure Monitor. Configuras alertas y te enteras si la calidad se degrada antes de que te lo cuente un cliente.

He visto demasiados agentes que pasaban tests preciosos en dev y luego en produccion nadie sabia como iban. Esto cierra ese hueco.

Un ejemplo rapido de creacion de agente

Para hacernos a la idea, asi queda la creacion de un agente con la API nueva. La libreria pasa a azure-ai-projects (antes azure-ai-agents) y el cliente OpenAI se obtiene desde el proyecto:

from azure.ai.projects import AIProjectClient

from azure.identity import DefaultAzureCredential

 

project = AIProjectClient(

endpoint=»https://miproyecto.services.ai.azure.com/api/projects/miproyecto»,

credential=DefaultAzureCredential(),

)

 

client = project.get_openai_client()

 

response = client.responses.create(

model=»gpt-4.1″,

instructions=»Eres un asistente de soporte para Business Central.»,

input=»Como configuro un nuevo workflow de aprobacion?»,

)

Si vienes del SDK anterior, la migracion es basicamente cambiar el paquete y el cliente. Las herramientas (MCP, A2A, Azure AI Search) se conectan ahora desde una pestana Tools unificada en el portal, lo que tambien simplifica bastante el dia a dia.

Expansion regional

Hosted Agents llega a seis regiones mas: East US, North Central US, Sweden Central, Southeast Asia, Japan East y otras adicionales. Para clientes europeos con requisitos de residencia de datos, Sweden Central es la pieza que faltaba.

A quien le interesa migrar ya

Si tu agente sigue en preview y te encuentras en alguno de estos casos, el GA es para ti:

• Tu equipo de seguridad lleva semanas bloqueando el paso a produccion por el egreso publico.
• Necesitas que el agente actue en nombre del usuario contra SaaS externos.
• Estas montando un canal de voz y no quieres orquestar tres servicios.
• Llevas tiempo sin saber como esta rindiendo el agente en produccion.

Y si tu agente todavia esta en diseno, empieza directamente sobre la nueva API. La curva no es alta y te ahorras la migracion despues.

Para terminar

Foundry Agent Service GA no anade un unico feature estrella, y creo que ahi esta el valor. Junta networking privado, identidades MCP, voz integrada y evaluaciones continuas en un mismo runtime. Es justo el conjunto de cosas que separa una demo bonita de un sistema que tu CISO firma para produccion.

Fuentes

Anuncio oficial: https://devblogs.microsoft.com/foundry/foundry-agent-service-ga/

Documentacion – Foundry Agent Service: https://learn.microsoft.com/en-us/azure/ai-foundry/agents/overview

Documentacion – Private networking: https://learn.microsoft.com/en-us/azure/ai-foundry/agents/how-to/virtual-networks