Harness para agentes de IA: el de Copilot llega a Foundry

Un harness para agentes de IA que ya no tienes que construir

El 28 de octubre Microsoft anunció que el harness de Copilot, el que construyó el equipo de GitHub y que según ellos usan Copilot en VS Code, la CLI y otros productos, se ofrece ahora como servicio gestionado en Foundry Agent Service, en vista previa pública. Si me sigues, sabes que insisto en que casi todo lo que importa en un agente está en el harness y no en el modelo; conté por qué en el post sobre el harness de los agentes. Por eso me interesa cuando un gran proveedor lo vuelve un producto.

Todo lo que cuento de la herramienta viene del anuncio de Microsoft y no la he probado. Lo mío va marcado como opinión.

Qué es, según Microsoft

Para ellos, el modelo pone la inteligencia y el harness es todo lo que lo rodea: las instrucciones, el contexto, el entorno de ejecución y los controles. Su argumento es que muchos equipos acaban escribiendo la misma maquinaria (coordinar llamadas al modelo y a herramientas, mantener el contexto de trabajo, gestionar ficheros, decidir cómo seguir) y que eso no suele ser lo que diferencia a una aplicación.

Con el harness gestionado, Microsoft ejecuta el bucle del agente y el sandbox, y tú aportas el conocimiento, los procedimientos y las herramientas. La vista previa se apoya en cuatro piezas:

• Skills reutilizables, con instrucciones, scripts y recursos empaquetados como procedimientos.
• Herramientas conectadas, tanto de Foundry como servidores MCP, con la autenticación y las aprobaciones configuradas de forma explícita.
• Ejecución y delegación: trabajar con ficheros y código y delegar tareas acotadas en subagentes integrados.
• Definiciones de agente en el repositorio: puedes crearlas y probarlas en Foundry o gestionarlas junto al código de tu aplicación. Su ejemplo usa un SKILL.md y un azure.yaml desplegados con azd.

En el otro anuncio, el del blog oficial de Microsoft, dicen que funciona con más de 20 modelos de frontera o con tu propia clave, que han portado el runtime a Rust para reducir la sobrecarga de sesión y el tiempo hasta el primer token, y que soporta estándares abiertos como MCP y las agent skills. Son afirmaciones de Microsoft, sin cifras de rendimiento que pueda contrastar.

Tres niveles, una tabla útil

Lo que más me ha gustado del anuncio técnico es que no vende el harness para todo. Propone elegir según lo que necesites:

• Agentes de prompt sin el harness, cuando bastan las instrucciones y las herramientas compatibles.
• Agentes de prompt con el harness, cuando quieres skills, ejecución gestionada, ficheros, subagentes y una coordinación de herramientas más compleja sin ser dueño del harness.
• Hosted agents, cuando necesitas traer o cambiar el framework, el bucle del agente, el middleware, las dependencias o el comportamiento en ejecución, y quedarte solo con el alojamiento gestionado.

Me parece una forma sana de plantearlo: empieza por el nivel que encaje y no asumas infraestructura que no te diferencia.

Qué dice de los trabajos largos

Junto al lanzamiento, Microsoft anuncia la disponibilidad general de la recuperación ante interrupciones en los hosted agents, para trabajos de horas o días. Según su descripción, Foundry detecta la interrupción y reinicia el trabajo con su entrada original, y es tu código el que tiene que guardar el progreso y los resultados intermedios. Si el agente modifica otro sistema, además tienes que evitar duplicar acciones al reiniciar. Y avisan de que el historial de conversación por sí solo no basta para restaurar el trabajo en curso.

Es un enfoque distinto del de Infinity, que conté en este post: allí el runtime suspende al agente y lo reanuda desde lo guardado. La conclusión que me llevo, y esto ya es lectura mía, es la misma: diseña cada paso para que se pueda repetir sin hacer daño.

Las condiciones, que importan

• Es una vista previa: al crear el agente hay que elegir el harness, los agentes existentes no cambian y de momento no se puede cambiar de harness una vez creado.
• Microsoft indica que debes revisar las regiones, los modelos y las herramientas compatibles y los límites de la vista previa.
• El runtime del harness es gratuito hasta el 1 de diciembre de 2026. A partir de esa fecha, el cómputo y la memoria del sandbox se facturan a 0,0994 dólares por vCPU-hora y 0,0118 dólares por GiB-hora, según Microsoft y con posibles variaciones por región y acuerdo. La inferencia del modelo y las herramientas o servicios conectados se cobran aparte.

Lo que yo me preguntaría

Esto es opinión mía, no de Microsoft:

• ¿Dónde queda lo que te diferencia? Si el bucle del agente lo da hecho otro, el trabajo se mueve a las skills, a las herramientas y a la evaluación de resultados. Ahí hace falta especificar bien qué es un buen resultado, que es el terreno de Spec-Driven Development.
• ¿Quién controla los permisos? Las aprobaciones de las herramientas se configuran, pero alguien tiene que decidir qué se aprueba solo. Los temas de permisos, sandboxes y secretos valen igual aunque el sandbox sea ajeno.
• ¿Cuánto te ata? Microsoft dice que las plataformas siguen abiertas e interoperables, y que las skills y MCP son estándares abiertos. Aun así, antes de apostar yo comprobaría cuánto de mi definición de agente sería portable.
• ¿Te hace falta ya? Si tu equipo aún tiene dudas sobre qué quiere que haga el agente, un harness mejor no lo resuelve.

Qué me llevo

La parte que me quedo es que el harness deja de ser una ventaja y pasa a ser una pieza que se compra. Lo que va a distinguir a los equipos es lo que construyan encima: las skills, las herramientas y cómo comprueban que el agente hace lo que debe. Y eso se puede empezar a trabajar hoy, con el harness que sea.

En onext ayudamos a equipos a adoptar agentes de IA con Spec-Driven Development, a decidir qué construir y qué comprar. Si estás valorando qué harness usar, escríbenos y lo vemos juntos.