AIREITERCambiar de modelo no debería obligarte a rehacer toda la orquestación, pero precisamente ese tipo de trabajo suele echar por tierra los plazos de un agente. Microsoft Copilot harness en Microsoft Foundry es la respuesta gestionada de Microsoft: la misma capa de ejecución que está detrás de Copilot Code, Copilot Studio, la aplicación GitHub Copilot, la CLI y Visual Studio Code. Ahora llega a la vista previa pública, con el runtime gratuito hasta el 1 de diciembre de 2026 (blogs.microsoft.com). Es un buen momento para experimentar, pero conviene mantener las cargas de producción en el stack actual hasta resolver los límites de la preview que detallamos más abajo.
Qué hace realmente Microsoft Copilot harness
Microsoft Copilot harness es la capa de orquestación gestionada que rodea al modelo y convierte el razonamiento en trabajo terminado. Microsoft aporta el bucle del agente, el sandbox, la gobernanza y la optimización; el desarrollador pone las instrucciones, las skills, las herramientas y el modelo.
La explicación de Microsoft es bastante directa: «Si el modelo aporta la inteligencia, el harness es todo lo que hay alrededor del modelo» (blogs.microsoft.com). En la práctica, el harness mantiene el contexto de trabajo a medida que avanza la tarea, coordina las llamadas al modelo y a las herramientas, ejecuta archivos y código dentro de un sandbox, delega subtareas acotadas en subagentes integrados y aplica los límites y las políticas configurados (devblogs.microsoft.com).
| Responsabilidad | Qué gestiona Microsoft Foundry | Qué aportas tú |
|---|---|---|
| Bucle del agente y ejecución en sandbox | Sí | No |
| Gobernanza, aprobaciones y optimización | Sí | Configuración |
| Instrucciones y skills | No | Sí |
| Herramientas, servidores MCP y conocimiento | No | Sí, con la autenticación que configures |
| Selección del modelo | Lista compatible | El despliegue que elijas |
Enrutamiento multimodelo con más de 20 modelos frontier y BYOK
Microsoft Copilot harness admite más de 20 modelos frontier de distintas familias mediante configuraciones bring-your-own-key (BYOK), y dirige cada trabajo al modelo o modelos adecuados según la tarea (blogs.microsoft.com). Microsoft no ha publicado en el anuncio la lista completa de esos 20 modelos, así que conviene comprobar qué disponibilidad exacta tiene tu región de Foundry antes de diseñar una arquitectura multimodelo. La promesa es dejar de mantener un router propio: «Tú aportas las instrucciones, las skills, las herramientas y eliges el modelo».
Uno de los primeros desarrolladores resumió así el atractivo de la propuesta: no tener que reescribir la capa de orquestación cada vez que cambia el modelo — @ai_fengshou.
Un runtime en Rust que ya impulsa varios productos
El runtime de Microsoft Copilot harness se ha trasladado recientemente a Rust. Según Microsoft, el cambio redujo la sobrecarga de las sesiones y el tiempo hasta el primer token (blogs.microsoft.com). No hay porcentajes de mejora ni tablas de latencia publicadas, así que por ahora conviene tomarlo como una indicación general.
Microsoft afirma que este mismo harness ya impulsa Copilot Code, Copilot Studio, la aplicación GitHub Copilot, GitHub Copilot CLI, Visual Studio Code y otras superficies de Microsoft y GitHub Copilot (blogs.microsoft.com). La compañía describe esa base compartida como probada con millones de usuarios y cientos de casos de uso reales (blogs.microsoft.com).
El harness también ofrece extensibilidad abierta mediante Model Context Protocol (MCP), agent skills y agent plugins (blogs.microsoft.com).
Qué cambió el 28 de octubre de 2026
El 28 de octubre de 2026 Microsoft anunció dos movimientos relacionados: Microsoft Copilot harness entró en la vista previa pública de Foundry Agent Service y la resiliencia para ejecuciones largas de agentes alojados pasó a disponibilidad general (devblogs.microsoft.com).
La terminología también está cambiando. Lo que la documentación de Copilot Studio todavía denomina GitHub Copilot harness ahora aparece como Microsoft Copilot harness en la terminología de producto, aunque las distintas páginas se están actualizando en momentos diferentes (microsoft.com).
Foundry Agent Service ofrece ahora tres niveles de abstracción: prompt agents sin harness, prompt agents con Microsoft Copilot harness en preview y hosted agents, donde el desarrollador controla el framework (devblogs.microsoft.com). La resiliencia para ejecuciones largas —la capacidad de un hosted agent para recuperarse de interrupciones durante flujos que duran horas o días— es la parte que ya está disponible de forma general.
Cómo se construye un agente con harness en Foundry
Un agente de Foundry con harness se define de forma declarativa y se guarda junto al código de la aplicación (devblogs.microsoft.com). Los desarrolladores lo crean y prueban en Foundry, mantienen sus definiciones bajo control de versiones y lo despliegan con Azure Developer CLI (azd) o desde el portal de Foundry (devblogs.microsoft.com).
Las skills reutilizables encapsulan el método de trabajo
Las skills reutilizables agrupan instrucciones, scripts, recursos de apoyo y procedimientos que los agentes pueden aplicar en distintas tareas. El ejemplo documentado utiliza una skill research-brief ubicada en skills/research-brief/SKILL.md. Esta obliga al agente a confirmar la pregunta, la audiencia, el alcance y el periodo temporal; recopilar pruebas con herramientas aprobadas; citar fuentes y fechas; separar hechos de interpretaciones y señalar las evidencias contradictorias.
Las herramientas conectadas siguen bajo control
Las herramientas conectadas permiten que los agentes utilicen herramientas de Microsoft Foundry y herramientas MCP con autenticación y aprobaciones configuradas explícitamente. Esa aprobación funciona como control de gobernanza, pero, como muestran los comentarios de Reddit que veremos más adelante, también puede convertirse en una fuente de fricción cuando los usuarios finales se encuentran una y otra vez con diálogos de consentimiento.
Ejecución, archivos y delegación de tareas
Los agentes trabajan con archivos, ejecutan código y delegan tareas acotadas en subagentes integrados, mientras el agente principal coordina los resultados. La comparación del harness de Copilot Studio añade que el harness heredado de GitHub crea y edita de forma nativa archivos de Word, Excel, PowerPoint y PDF, además de admitir skills y memoria (learn.microsoft.com).
Definiciones bajo control de versiones y una sola línea para activar el harness
Las definiciones de los agentes viven junto al código. El ejemplo de Foundry declara el harness en azure.yaml (devblogs.microsoft.com):
harness:
type: microsoft_copilot_previewEl ejemplo conecta un prompt agent llamado research-brief con una skill research-brief-skill, búsqueda web (public-research) y Code Interpreter (research-analysis). Como entradas de entorno utiliza FOUNDRY_PROJECT_ENDPOINT y MODEL_DEPLOYMENT_NAME (devblogs.microsoft.com). El despliegue y la invocación se realizan con la CLI de preview:
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."También se puede trabajar desde el portal de Foundry, el Foundry Toolkit para Visual Studio Code y el plugin de Foundry para la aplicación GitHub Copilot (devblogs.microsoft.com).
Qué tipo de agente de Foundry encaja mejor con tu tarea
No existe un nivel de abstracción universalmente correcto. La recomendación de Microsoft es elegir el nivel que resuelva las necesidades de la aplicación con la menor responsabilidad posible sobre la infraestructura (devblogs.microsoft.com). Durante la preview, la elección queda fijada al crear el agente, así que hay que tomarla antes de pulsar el botón de creación.
| Enfoque | Cuándo usarlo | Qué obtienes | Qué pierdes |
|---|---|---|---|
| Prompt agent sin harness | Las instrucciones y las herramientas compatibles son suficientes | La opción más sencilla y con menos responsabilidades | No hay skills, gestión de archivos, subagentes ni una orquestación avanzada |
| Prompt agent con Microsoft Copilot harness (preview) | Necesitas skills, ejecución gestionada, archivos, subagentes y coordinación compleja de herramientas | Bucle y sandbox gestionados, skills reutilizables y una ejecución más completa | Se aplican los límites de la preview; Microsoft controla una mayor parte del runtime; hay restricciones de modelos, herramientas y regiones compatibles |
| Hosted agent | Debes aportar o modificar el framework, el bucle, el middleware o las dependencias | Máximo control con alojamiento gestionado por Foundry | Tú te encargas de los checkpoints, la reanudación y de evitar acciones duplicadas |
Entre las primeras señales de clientes que cita Microsoft están Confluence Technologies, que lanzó una solución en menos de una semana al centrarse en el diseño en lugar de la infraestructura, y Fashable, que utiliza el harness en flujos de sourcing gobernados mientras mantiene bajo control humano las decisiones con implicaciones comerciales vinculantes (devblogs.microsoft.com).
Cuánto costará después del 1 de diciembre de 2026
La facturación del runtime de Microsoft Copilot harness comenzará el 1 de diciembre de 2026 con un modelo basado en consumo. El uso del runtime será gratuito antes de esa fecha, pero la inferencia del modelo, las herramientas con facturación independiente y los servicios conectados se cobrarán aparte durante todo el periodo.
| Recurso del sandbox | Precio desde el 1 de diciembre de 2026 |
|---|---|
| Cómputo del sandbox | $0.0994 por vCPU-hora |
| Memoria del sandbox | $0.0118 por GiB-hora |
Los precios pueden variar según la región y el acuerdo con el cliente (devblogs.microsoft.com). Durante la preview, Foundry gestiona la CPU, la memoria y la configuración de inactividad del entorno de ejecución (devblogs.microsoft.com), y remite a documentación específica para consultar las regiones, los modelos, las herramientas y los límites compatibles.
En Copilot Studio, los agentes que utilizan el harness heredado de GitHub se facturan mediante Copilot Credits con un modelo basado en uso. Es una superficie de facturación distinta de la medición del sandbox de Foundry (learn.microsoft.com). Para calcular el coste de un piloto, multiplica las vCPU-horas y GiB-horas observadas del sandbox por las tarifas anteriores y suma después los cargos por tokens del modelo y por herramientas.
Límites de la preview que debes revisar antes de empezar
La letra pequeña determina si un piloto puede sobrevivir al salto a producción. Estas restricciones proceden de la propia publicación de Microsoft en Foundry, salvo cuando se indica que han sido detectadas por usuarios.
- La elección del harness no se puede cambiar por ahora. El harness se selecciona al crear el agente; los agentes existentes no se modifican y actualmente no es posible cambiarles el harness después de crearlos. Un lector señaló precisamente este punto: «eliges el Copilot harness al crear el agente. Los agentes existentes no cambian y todavía no se admite cambiar el harness después de la creación» — @navaneethan_es.
- Las regiones y los modelos están limitados. Foundry remite a la documentación para consultar la lista completa de regiones, modelos, herramientas y límites de la preview. El resumen de un usuario habla de aproximadamente nueve regiones, sin cobertura de Oriente Medio y todavía sin BYOM completo — @HeshamSaadZaki. Tómalo como la lectura de un usuario que hay que verificar en la documentación, no como una tabla oficial de regiones.
- La recuperación de ejecuciones largas corre por tu cuenta. Foundry reinicia el trabajo alojado interrumpido y vuelve a proporcionar la entrada original, pero la aplicación debe guardar el progreso, reanudar desde checkpoints y evitar acciones duplicadas, como crear dos veces el mismo informe externo. El historial de la conversación por sí solo no restaura un trabajo en curso.
- El lanzamiento no incluye benchmarks ni cifras de SLA. Hay que esperar afirmaciones cualitativas como «rendimiento líder del sector», pero no tablas de latencia, rendimiento o precisión.
Qué problemas están encontrando los primeros usuarios del Copilot harness en producción
Los usuarios de Copilot Studio que trabajan con el harness heredado de GitHub señalan preocupaciones recurrentes sobre la diferencia entre preview y producción. Estos testimonios describen la experiencia del GitHub Copilot harness en Copilot Studio antes de la preview de Foundry. Los incluimos como una inferencia basada en el origen compartido que describe Microsoft (blogs.microsoft.com), no como mediciones de Foundry.
Los malditos conectores ni siquiera aguantan conectados un día en producción. — u/roberts2727 en r/copilotstudio
A veces los flujos funcionan; otras veces el agente no les pasa nada en absoluto. — u/donstazz en r/copilotstudio
Los usuarios de negocio no pueden hacer estos registros de aplicaciones, etc. Tiene que hacerlo un administrador de TI. Para cada agente, uno por uno. — u/Teemu_St en r/copilotstudio
Problemas señalados en esos hilos:
- Respuestas más lentas en agentes respaldados por SharePoint, descritas como significativamente más lentas que las alternativas en r/copilotstudio.
- Agentes que funcionan en el panel de pruebas de Studio, pero fallan después del despliegue en Teams o M365 Copilot con errores genéricos en r/copilotstudio.
- Inestabilidad de conectores y flujos, además de problemas recurrentes de autenticación y consentimiento para MCP en r/copilotstudio.
- Confusión sobre la facturación: si una licencia de M365 Copilot cubre el runtime del harness o si siguen aplicándose Copilot Credits, según r/microsoft_365_copilot.
Nada de esto invalida la preview de Foundry, pero sí marca la lista de comprobaciones para el piloto: prueba con tu fuente de conocimiento real, tu canal real y el flujo de consentimiento real de los usuarios finales antes de comprometer fechas.
Preguntas frecuentes
¿Microsoft Copilot harness es lo mismo que GitHub Copilot harness?
Sí. Es la misma línea tecnológica creada a partir de GitHub, ahora bajo el nuevo nombre de Microsoft. Algunos documentos de Copilot Studio todavía utilizan la denominación anterior mientras se completa la transición.
¿Qué modelos admite el harness de Foundry?
Más de 20 modelos frontier, además de BYOK y enrutamiento basado en la tarea. Microsoft no ha publicado la lista completa, así que debes consultar la documentación de Foundry para tu región (consulta también la sección sobre modelos multimodales).
¿Puedo migrar un agente existente de Foundry al harness?
No se puede cambiar directamente durante la preview. Lo recomendable es hacer una evaluación en paralelo: inventaría prompts, herramientas, autenticación y necesidades de estado; recrea el agente con microsoft_copilot_preview en un proyecto de preview y compara calidad, latencia, uso del sandbox y recuperación antes de hacer el cambio.
¿Una licencia de M365 Copilot cubre el uso del harness?
No automáticamente. Foundry mide el cómputo y la memoria del sandbox por separado de la inferencia del modelo, mientras que Copilot Studio factura esta familia de harness mediante Copilot Credits. Comprueba qué medidor corresponde a la superficie que utilizas.
¿Debería usar el harness o un hosted agent?
Usa el harness si quieres un bucle, un sandbox, skills y subagentes gestionados sin tener que encargarte de la orquestación. Elige un hosted agent cuando necesites controlar el framework o el runtime y puedas asumir la gestión de checkpoints e idempotencia.
Empieza en preview con el patrón de la skill research-brief, mide el coste del sandbox y de los tokens frente a un prompt agent sin harness que ejecute la misma tarea y mantén producción en el camino que ya conoces hasta que la migración, las regiones y el comportamiento del consentimiento estén documentados para tu tenant.