Microsoft Abre Serverless Agent Runtime para Azure Functions

Microsoft lanzó un runtime serverless de agentes para Azure Functions en vista previa pública en Build 2026, transformando el modelo de computación dirigido por eventos de la plataforma en un anfitrión de primera clase para agentes de IA. El runtime se ejecuta junto con la infraestructura de Durable Task Scheduler, ejecutando cientos de millones de operaciones semanalmente bajo Microsoft Copilot — una señal de escala que demuestra que esto no es solo un prototipo.

La mecánica central es .agent.md: un archivo markdown que declara prompt del sistema, disparadores, conexiones de servidor MCP y herramientas. El frontmatter YAML especifica el disparador; el cuerpo markdown se convierte en instrucciones del agente. Los archivos complementarios mcp.json y agents.config.yaml cargan servidores MCP externos y catálogos de herramientas. El runtime maneja orquestración, envío de herramientas y generación de respuestas. Un agente disparado por temporizador que recopila, resume y envía un resumen diario por correo electrónico es un único archivo .agent.md — sin esqueleto Python, sin código boilerplate.

Cualquier disparador Azure Functions existente ahora genera un agente: HTTP, Timer, Service Bus, Event Hubs, SQL, Cosmos DB, o nuevos disparadores respaldados por conexión para mensajes de Teams, correo de Outlook, eventos de calendario e elementos de SharePoint. Los agentes acceden a servidores de herramientas MCP, ejecución de código y navegador aislados a través de sesiones dinámicas de Azure Container Apps, y 1.400+ conectores administrados en Microsoft 365, Salesforce, ServiceNow y SAP. Los proveedores de modelos son conectables en el lanzamiento: Microsoft Foundry, Azure OpenAI y OpenAI. Los servidores MCP publicados desde Functions serán descubiertos automáticamente por agentes Foundry una vez que se envíe la integración de Foundry Toolbox.

Microsoft respondió a dos preguntas inmediatas de profesionales. Sobre arranque en frío: "El runtime de agentes no añade arranque en frío más allá de un disparador HTTP regular en Flex Consumption. La infraestructura no es el cuello de botella — la LLM sí lo es." Sobre costo: sin prima de facturación. La ejecución se factura como Flex Consumption estándar, escala a cero por segundo, idéntico a cualquier otra función en el plan. La autenticación usa identidad administrada; los servidores MCP hospedados en Functions heredan la identidad del llamador a través de tokens OBO integrados, cerrando la brecha empresarial más grande en alojamiento de agentes de terceros.

Microsoft prueba internamente el runtime. Thiago Almeida, Principal Program Manager de Azure Functions, describió un agente .agent.md disparado por temporizador que el equipo ejecuta para auditar la postura de seguridad en todas las organizaciones de GitHub: en cada ejecución verifica protección de rama, escaneo de secretos y permisos de flujo de trabajo en todos los repositorios e informa sobre hallazgos a través de conectores y servidores MCP. Costo entre ejecuciones: cero.

El lanzamiento de Functions en Build 2026 incluye cambios que afectan cargas de trabajo de agentes. La extensión MCP pasó a GA, expandiendo desde un único disparador de herramienta a soporte completo de servidor MCP — disparadores de herramienta, recurso y prompt — en .NET, Java, Python, TypeScript y JavaScript. Sandboxes bajo demanda (vista previa privada) añaden computación aislada respaldada por microVM para pasos individuales de Durable Task Scheduler: declare qué actividades se ejecutan en sandbox, apunte a una imagen de contenedor, y la plataforma aprovisiona, escala y desmantelación por ejecución. Casos objetivo: cadenas de herramientas nativas (ffmpeg, LibreOffice, Pandoc), preprocesamiento intensivo en CPU como OCR, pasos entre runtimes (inferencia Python desde orquestrador .NET) y ejecución de código generado por LLM en sandbox.

La apuesta es que el trabajo de agentes empresariales es fontanería — identidad, conectores, alojamiento, observabilidad — y colapsarlo en Functions elimina la razón por la que los equipos construyen capas personalizadas. La restricción es la latencia del modelo: el arranque en frío y la facturación están fuera del camino crítico, pero los agentes se mueven solo tan rápido como las llamadas de LLM. Los arquitectos deben dimensionar para la complejidad del prompt y los viajes redondos de modelo, no para la sobrecarga de la plataforma.