Microsoft Foundry Agent Service: cómo desplegar agentes con identidad, tools y trazas

Microsoft Foundry Agent Service es el runtime gestionado de Microsoft para ejecutar agentes basados en prompts o código. La keyword principal es Microsoft Foundry Agent Service; la intención es de implementación: un equipo Azure quiere saber cuándo usarlo, cómo dar tools a un agente y qué controles necesita antes de producción.

TL;DR

La decisión no es entre 'gestionar todo' o 'hacer magia con un prompt'. Foundry puede encargarse del endpoint, escalado, identidad Entra, sesiones, versionado y trazas; tu equipo sigue siendo responsable de la política de acceso, la validación de negocio, los límites de coste y la aprobación de acciones mutantes.

Mi postura: empieza con un prompt agent si tu workflow cabe en instrucciones y un conjunto estrecho de tools. Elige un hosted agent cuando tu código necesita orquestación propia, protocolos o estado. No empaquetes un microservicio normal como agente solo por subirte al término: si un if y una API determinista resuelven la tarea, será más barato y comprobable.

Qué es y qué no es Agent Service

Un agente combina modelo, instrucciones y tools. En Foundry, la Responses API es el punto de entrada común: permite usar modelos del catálogo y herramientas de plataforma desde un prompt agent, un contenedor propio o un proceso que ya existe. Esa capa no convierte cualquier respuesta en una decisión correcta; organiza el runtime alrededor de ella.

El servicio actual distingue dos rutas. Un prompt agent se define por configuración y Foundry ejecuta el runtime; un hosted agent es tu código —Agent Framework, LangGraph, OpenAI Agents SDK o un runtime propio— empaquetado y ejecutado con endpoint e identidad administrados. No confundas esta generación con los 'Agents (classic)': Microsoft marca el portal y SDK clásicos como deprecados, con retirada anunciada para marzo de 2027.

La frontera citable es sencilla: Foundry administra cómo se ejecuta y observa un agente; tu producto determina qué puede hacer, contra qué datos y quién responde cuando se equivoca.

Un runtime gestionado reduce trabajo de plataforma; Toolbox, identidad, aprobación y evaluación siguen siendo decisiones de ingeniería explícitas.

Prompt agent, hosted agent o tu proceso actual

Usa un prompt agent para un copiloto interno que consulta documentación, resume un expediente o prepara una propuesta sin orquestación de aplicación compleja. La ganancia es operativa: no mantienes contenedor ni servidor. Antes de abrirle una tool de escritura, define scopes, retención, casos de denegación y un modo de revisión humana.

Usa un hosted agent cuando necesitas código propio, webhooks, una API no compatible con Responses, una máquina de estados, workers, bibliotecas existentes o un protocolo específico. El servicio ejecuta cada sesión en un sandbox aislado y proporciona identidad y endpoint, pero no audita si tu función de Python respeta el tenant. Tu backend debe derivar identidad y permisos de credenciales fiables, no de parámetros que el modelo inventa.

Mantén tu proceso fuera de Foundry si ya tienes una aplicación sana y solo quieres acceder a modelos o a una tool concreta. Migrar runtime sin una necesidad de escalado, distribución, identidad o estado añade otra superficie de despliegue. La portabilidad razonable es aislar tu lógica de negocio y tratar la integración con Foundry como un adaptador.

Toolbox: centraliza capacidades, no confianza

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Un Toolbox es un paquete versionado de tools que se expone por un endpoint MCP. Sirve para evitar que cada agente tenga su propia copia de URLs, credenciales, allowlists y políticas. Un consumidor puede seguir el default_version para recibir una versión promovida, mientras un entorno de prueba se conecta a una URL versionada e inmutable antes de aprobarla.

La ventaja real no es que MCP sea moderno; es que puedes gobernar una colección. Empieza con dos tools de lectura, por ejemplo búsqueda web y documentación interna. Después añade una integración remota, separada por dominio y con una conexión de proyecto. Un Toolbox que mezcla GitHub de escritura, facturación, producción y búsqueda pública es una forma elegante de esconder una política pésima.

La documentación es explícita con un detalle que muchos omiten: cuando una tool devuelve require_approval: always, el endpoint MCP no bloquea tools/call; el runtime debe presentar la acción y esperar confirmación. No declares aprobación en metadata y des por resuelto el control. Prueba que tu interfaz y tu executor lo imponen realmente.

Un piloto reproducible con Azure Developer CLI

El quickstart oficial permite crear un hosted agent de ejemplo, usar una Toolbox y ejecutarlo localmente antes de desplegar. Este flujo es deliberadamente pequeño: valida el endpoint, el descubrimiento de tools/list y el comportamiento de una tool de lectura antes de conectar recursos sensibles.

Lo que conviene comprobar

PowerShell / terminal

mkdir foundry-toolbox-pilot
cd foundry-toolbox-pilot
azd ai agent init -m "https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/responses/04-foundry-toolbox/azure.yaml" --src src/toolbox-agent

azd ai toolbox create docs-tools --from-file ./src/toolbox-agent/toolbox.yaml
azd env set TOOLBOX_NAME docs-tools
azd ai agent run

# En otra terminal: comprueba tools y una consulta de solo lectura
azd ai agent invoke --local "Enumera las tools disponibles y no ejecutes ninguna acción mutante."

Fija versiones de azd, la extensión microsoft.foundry, Python y las dependencias del sample en tu CI. El comando scaffold es una base, no una arquitectura aprobada. Revisa el azure.yaml, el toolbox.yaml, las conexiones y cualquier endpoint antes de asociarlo a recursos de empresa.

Identidad, secretos y aislamiento

Al desplegar un hosted agent, Foundry crea una identidad Entra dedicada para ese agente. Esa identidad puede usar el endpoint del proyecto y el almacenamiento de sesión por defecto; para Storage, Search u otros recursos debes conceder roles específicos. Ese diseño es preferible a copiar una clave de administrador en el contenedor, pero mínimo privilegio sigue significando una asignación por recurso y entorno.

No guardes API keys ni OAuth tokens dentro de la imagen ni en el repositorio. Foundry permite resolver valores desde project connections al iniciar el sandbox. Para tools MCP, la conexión decide la identidad downstream; separa conexiones de desarrollo y producción y rota las credenciales con el mismo rigor que las de cualquier servicio.

Las tools externas pueden sacar datos fuera del perímetro de cumplimiento de Foundry. Documenta ese flujo antes de activar un conector: datos enviados, proveedor, región, retención, scopes y respuesta ante un fallo. La red privada y RBAC ayudan, pero no corrigen una tool que devuelve demasiado contexto al modelo.

Despliegue, trazas y evaluación

La secuencia sana es build local, prueba de tools y casos negativos, despliegue de una versión, espera a estado activo, canary con identidad de prueba y solo después promoción. Los hosted agents pueden desplegarse como contenedor o desde código fuente empaquetado; elige el primero si ya controlas la imagen y el segundo para un inner loop sencillo, no por comodidad ciega.

Foundry puede inyectar la conexión de Application Insights y habilitar OpenTelemetry. Eso permite ver latencia, excepciones, llamadas de modelo y dependencias, pero puede incluir contenido personal o de cliente en trazas. Define redacción, muestreo, retención y quién puede leer Application Insights antes de celebrar que ya tienes observabilidad.

Evalúa tres capas por separado: resultado final (¿la respuesta sirve?), trayectoria (¿eligió la tool permitida?) y ejecución (¿respetó identidad, timeout y coste?). Cada fallo de producción debe convertirse en un caso de dataset antes de cambiar instrucciones o modelo. Sin ese bucle, el versionado solo te deja volver atrás sin saber por qué.

Checklist antes de producción

Elegir una tarea que justifique autonomía y escribir el contrato de entrada, salida, tools permitidas y acciones prohibidas.
Crear una Toolbox versionada de bajo riesgo; probar su endpoint versionado y promover a default_version solo tras revisión.
Conceder RBAC mínimo a la identidad de agente y usar una conexión distinta por entorno; no meter secretos en código o imagen.
Forzar confirmación en runtime para tools mutantes y probar una denegación, no solo el camino feliz.
Trazar sin registrar secretos: decidir qué prompts, outputs y argumentos se redactan, durante cuánto tiempo y quién los consulta.
Medir éxito, tool calls, errores, latencia, coste y tasa de escalado a humano con un dataset de casos normales, ambiguos y hostiles.

Preguntas frecuentes

¿Qué es Microsoft Foundry Agent Service?

Es una plataforma gestionada para construir, ejecutar, escalar y observar prompt agents y hosted agents, con modelos, tools, identidad y endpoints de Foundry.

¿Cuándo conviene un hosted agent?

Cuando necesitas ejecutar código propio, una orquestación o protocolo personalizado, estado de aplicación o una integración que no cabe en la configuración de un prompt agent.

¿Toolbox sustituye a una política de permisos?

No. Centraliza configuración, versiones y credenciales de tools; tu runtime y backend deben imponer scopes, aprobación y reglas de negocio.

¿Foundry gestiona por sí solo la aprobación humana?

No. La metadata de una tool puede pedir aprobación, pero el runtime que llama la tool debe detener la acción y esperar confirmación.

¿Puedo usar LangGraph u OpenAI Agents SDK?

Sí. Los hosted agents pueden ejecutar código con esos frameworks; no necesitas reescribir toda la orquestación para usar el runtime gestionado.

¿Las trazas son privadas por defecto?

Trátalas como datos sensibles. Revisa contenido capturado, permisos de Application Insights, retención y redacción antes de usarlas con tráfico real.

Cómo lanzar un piloto seguro con Microsoft Foundry Agent Service

Escoger una tarea de lectura. Empieza con una consulta de documentación o búsqueda interna que no cambie sistemas externos.
Crear un proyecto y modelo. Configura un Foundry project y un deployment de modelo compatible en una región soportada.
Scaffold del agente. Inicializa el sample oficial con Azure Developer CLI y revisa azure.yaml antes de ejecutar.
Crear Toolbox mínima. Añade una o dos tools de solo lectura y guarda la URL de la versión concreta para pruebas.
Ejecutar localmente. Comprueba tools/list, una respuesta útil, timeout y comportamiento ante una tool no permitida.
Asignar identidad mínima. Da a la identidad del agente solo los roles necesarios para los recursos que realmente consume.
Configurar trazas seguras. Conecta Application Insights, redacta campos sensibles y limita quién puede consultar los spans.
Desplegar canary. Publica una versión, invócala con una identidad de prueba y compara resultado, trayectoria, latencia y coste con el dataset.
Promover con evidencia. Cambia el Toolbox o el agente por versiones revisadas y conserva un rollback probado antes de ampliar permisos.