Microsoft pone el entorno de Copilot a disposición a través de Foundry

El 28 de octubre de 2026, Microsoft puso el entorno de ejecución de Microsoft Copilot —la capa de orquestación multimodelo que ya impulsa Copilot Code, Copilot Studio, la aplicación GitHub Copilot, Copilot CLI y VS Code— a disposición de desarrolladores y clientes empresariales a través de Microsoft Foundry, en un anuncio en el blog oficial de Microsoft.

Microsoft describe el entorno de ejecución como todo lo que rodea al modelo: la capa de orquestación que proporciona a un agente las instrucciones, el contexto, el entorno de ejecución y los controles adecuados para llevar a cabo su trabajo, con compatibilidad con estándares abiertos como Model Context Protocol, además de habilidades de los agentes y complementos para agentes. El equipo de ingeniería de GitHub creó el entorno de ejecución de Copilot, que Microsoft ha adoptado en toda la empresa. Una publicación complementaria ese mismo día en el blog de Microsoft Foundry presentó el entorno de ejecución en Foundry Agent Service como versión preliminar pública y anunció la disponibilidad general de la resiliencia para agentes alojados de larga duración.

Microsoft afirmó que el entorno de ejecución está diseñado para funcionar con distintas familias de modelos y que es compatible con más de 20 modelos de vanguardia, además de permitir que los usuarios aporten su propia clave. También indicó que dirige el trabajo al modelo o los modelos adecuados según la tarea. La empresa señaló que ejecuta el ciclo del agente y el entorno aislado, con mecanismos de gobernanza y optimización integrados, mientras que los clientes proporcionan las instrucciones, las habilidades, las herramientas y el modelo que prefieran. El SDK de Copilot está disponible para su descarga, y el entorno de ejecución también puede ejecutarse en la nube administrada por Foundry. Microsoft afirmó que sus plataformas siguen abiertas a otros entornos de ejecución y marcos de trabajo.

Ejecución administrada en Foundry Agent Service

Según la publicación del blog de Foundry, la versión preliminar pública combina cuatro componentes básicos. Las habilidades reutilizables reúnen instrucciones, scripts y recursos de apoyo en procedimientos que un agente puede aplicar en distintas tareas. Las herramientas conectadas incluyen herramientas compatibles con Foundry y Model Context Protocol, con autenticación y aprobaciones configuradas de forma explícita. La ejecución y la delegación permiten a los agentes trabajar con archivos y código, así como asignar tareas acotadas a subagentes integrados, mientras el agente principal coordina el resultado. Las definiciones de agentes bajo control de versiones pueden administrarse junto con el código de la aplicación. El entorno de ejecución gestiona el contexto de trabajo a medida que avanzan las tareas y coordina los pasos con modelos y herramientas dentro de los límites configurados y las políticas establecidas. Además, los clientes pueden elegir un modelo de Foundry compatible sin tener que reescribir la capa de orquestación que lo rodea.

Los desarrolladores pueden crear agentes mediante la interfaz preliminar de Azure Developer CLI (azd), el portal de Foundry, Foundry Toolkit para Visual Studio Code o el complemento y la habilidad de Microsoft Foundry en la aplicación GitHub Copilot. La publicación incluye declaraciones de dos empresas. Chris Evans, director de tecnología de Confluence Technologies, afirmó que su equipo tenía una solución en funcionamiento en menos de una semana, lo que le permitió centrarse en el diseño y las capacidades, en lugar de en la infraestructura subyacente. Orlando Ribas Fernandes, director ejecutivo de Fashable, señaló que el entorno de ejecución proporciona a la empresa una base para convertir procesos complejos de abastecimiento en flujos de trabajo de agentes gobernados y cuantificables, y mantener bajo control humano las decisiones con implicaciones comerciales vinculantes.

Límites de la versión preliminar y facturación a partir de diciembre

Durante la versión preliminar, los clientes seleccionan el entorno de ejecución de Microsoft Copilot al crear un agente. Los agentes existentes no se modifican, todavía no se admite cambiar el entorno de ejecución después de la creación y Foundry administra la CPU, la memoria y la configuración de inactividad del entorno de ejecución.

La facturación por el entorno de ejecución de Copilot en Foundry Agent Service comienza el 1 de diciembre de 2026 y se basa en el consumo. El uso del entorno de ejecución es gratuito antes de esa fecha, mientras que la inferencia de modelos y las herramientas y los servicios conectados que se facturan por separado siguen sujetos a los cargos correspondientes. A partir del 1 de diciembre, el cálculo en el entorno aislado se factura a 0,0994 $ por vCPU-hora y la memoria, a 0,0118 $ por GiB-hora; los precios varían según la región y el acuerdo.

La publicación también describe tres opciones en Foundry Agent Service: agentes basados en indicaciones sin el entorno de ejecución, cuando las instrucciones y las herramientas compatibles bastan para la tarea; agentes basados en indicaciones con el entorno de ejecución de Copilot, para contar con ejecución administrada y habilidades, archivos y subagentes; y agentes alojados, cuando los equipos necesitan su propio marco de trabajo, ciclo del agente, middleware, dependencias o comportamiento de ejecución, sin renunciar al alojamiento administrado por Foundry.

Resiliencia para agentes alojados de larga duración

La resiliencia para agentes alojados de larga duración ya está disponible de forma general y está destinada a trabajos que duran horas o días. Foundry detecta las interrupciones y reinicia el trabajo con la entrada original, mientras que el código del cliente guarda el progreso y los resultados intermedios para que el agente pueda reanudarlo donde se quedó. Cuando un agente actualiza otro sistema, el flujo de trabajo también debe evitar que se dupliquen acciones al reiniciarse. Microsoft señaló que el historial de conversaciones, por sí solo, no basta para restaurar el trabajo en curso.

Creado en GitHub

Microsoft afirmó que el mismo equipo de ingenieros de GitHub que estuvo detrás de su trabajo de orquestación multimodelo creó el entorno de ejecución, y que está estandarizando sus experiencias de Copilot sobre esa base. El 4 de septiembre de 2026, GitHub presentó Project HydraFusion, una versión preliminar de investigación que crea un plan de ejecución entre modelos de varios proveedores mediante tres patrones: individual, en el que un modelo resuelve directamente la tarea; en cascada, en el que un modelo eficiente redacta una solución y un control de calidad decide si se debe recurrir a un modelo más potente; y de crítica, en el que un crítico independiente, de solo lectura y perteneciente a otra familia de modelos, revisa un borrador antes de que el modelo que lo redactó lo revise. GitHub informó que, en evaluaciones sin conexión, HydraFusion mejoró en 4,9 puntos porcentuales la calidad de las tareas verificadas, con un costo estimado un 67 % menor que Claude Opus 5 en TerminalBench 2.1; quedó a 1,5 puntos en DeepSWE, con un costo un 36 % menor; y quedó a 0,1 puntos en su CheckpointBench interno, con un costo un 65 % menor.

GitHub también había revelado el 16 de septiembre de 2026 que migró el entorno de ejecución del agente de Copilot de TypeScript a Rust in situ, y que para el 21 de agosto de 2026 ya había alcanzado las 832.378 líneas de código Rust de producción, distribuidas en 128 solicitudes de incorporación de cambios enviadas de forma incremental; el SDK de Copilot expone el entorno de ejecución a interfaces para seis lenguajes. Microsoft atribuye a esta migración el rendimiento líder del sector y las reducciones de la sobrecarga de sesión y del tiempo hasta el primer token. En pruebas de rendimiento que Stephen Toub, ingeniero distinguido de Microsoft, realizó mediante el SDK de C#, el tiempo necesario para crear un cliente y una sesión y completar un turno se redujo de 5,25 segundos antes de la migración a 292 milisegundos con el entorno de ejecución de Rust cargado en el mismo proceso; además, el pico de memoria adicional en un lote de diez clientes bajó de 1.383 MB a 126 MB.