Ingeniería de IA
Microsoft Copilot harness: qué puedes dejar de construir en tu agente
Foundry incorpora el bucle de Copilot en preview. Qué gestiona Microsoft, qué límites tiene y cuándo sigue teniendo sentido llevar tu propio código.
El bucle del agente pasa a ser un servicio
Microsoft ha presentado el 28 de octubre el Copilot harness en Foundry Agent Service, en preview pública. Permite crear agentes con un sistema de ejecución gestionado: Microsoft opera el bucle y la sandbox; tu aplicación aporta instrucciones, skills, herramientas y un modelo compatible.
Ese bucle coordina las llamadas al modelo, el uso de herramientas y el contexto necesario para continuar una tarea. Es parte del trabajo que aparece al pasar de una respuesta de chat a un agente que procesa archivos, calcula y prepara una entrega.
La decisión práctica es cuánto de ese motor necesitas mantener. La preview ofrece una opción gestionada, con restricciones propias. No exige reescribir tus agentes actuales ni cambia automáticamente los que ya tienes en Foundry.
Tres formas de repartir el trabajo
Foundry mantiene distintas opciones. Un prompt agent configura instrucciones y herramientas sobre el servicio. Al seleccionar el Copilot harness, sigue siendo un prompt agent, pero incorpora ese runtime para coordinar skills, archivos, comandos y subtareas.
Un hosted agent permite llevar tu código y el framework que elijas dentro de un contenedor. Foundry gestiona su alojamiento; tú conservas la lógica de ejecución. Es la alternativa cuando necesitas cambiar el bucle, las dependencias o el comportamiento del proceso.
| Opción | Encaja cuando |
|---|---|
| Prompt agent | La tarea se resuelve con instrucciones y herramientas compatibles. |
| Prompt agent con Copilot harness | Necesitas coordinar pasos, skills y archivos con un runtime gestionado. |
| Hosted agent | Necesitas controlar el código, el framework o la ejecución del agente. |
Las herramientas siguen necesitando una configuración deliberada
El runtime incluye lectura y escritura de archivos, shell, acceso web y delegación a subagentes. La documentación indica que esas cinco capacidades están habilitadas inicialmente, sujetas a las políticas del servicio y de la organización. Conviene dejar activas las que requiere la tarea.
Las skills reúnen procedimientos reutilizables; las conexiones y los permisos determinan qué sistemas pueden usar las herramientas. Hay una diferencia concreta en esta preview: la configuración de aprobación de las herramientas MCP no controla las herramientas nativas del harness. Estas tienen una política de aprobación gestionada por el servicio.
Por tanto, una skill que diga «prepara un borrador» debe acompañarse del alcance técnico adecuado. Elegir un runtime gestionado sigue dejando en tu aplicación la decisión de qué recursos conectar y qué operaciones admitir.
El informe terminado debe salir del espacio de trabajo
Cada conversación tiene un workspace separado para archivos y estado de ejecución. Ese espacio sobrevive a las operaciones normales de pausa, reanudación y sustitución de la sandbox. Aun así, la documentación pide guardar las entregas importantes en Foundry Files u otro servicio duradero.
Un ejemplo propuesto sería comparar dos CSV de gasto cloud y redactar un informe por servicio. La skill define qué columnas comparar y cómo tratar una moneda distinta. El agente puede trabajar con los archivos y producir el documento. La aplicación debe comprobar los totales y conservar la entrega donde se vaya a consultar después.
El ejemplo ilustra el reparto de responsabilidades, sin atribuir una prueba a Foundry. También separa tres cosas que suelen confundirse: el historial de conversación, los archivos temporales de trabajo y el resultado que tu producto necesita conservar.
Lo que limita hoy a la preview
El harness se selecciona al crear un agente nuevo y, durante esta preview inicial, no puede cambiarse después. La disponibilidad está limitada a determinadas regiones y modelos con razonamiento y uso de herramientas. No admite BYOM, la opción de traer tu propio modelo.
Foundry gestiona la CPU, la memoria y el ciclo de vida de la sandbox, sin esos ajustes a cargo del cliente. Foundry Memory tampoco está disponible en este runtime; eso no elimina el historial ni los archivos del workspace de la conversación. Conviene revisar estos límites antes de elegir el runtime para tu aplicación.
El SDK es otra vía de integración. Su repositorio está en transición de GitHub Copilot SDK a Microsoft Copilot SDK y todavía conserva nombres de paquetes anteriores. Se comunica con el servidor de Copilot CLI mediante JSON-RPC. Que el SDK admita BYOK, con claves de un proveedor compatible, no implica que la preview de Foundry admita BYOM: son opciones de productos distintos.
La ventaja se decide con tu tarea completa
Lo probaría primero en un trabajo acotado como el informe anterior. Compararía la entrega, las llamadas a herramientas, el tiempo total y el coste con la implementación que ya tengas. El objetivo es saber si puedes reducir código de infraestructura manteniendo los controles y el resultado que necesitas.
El anuncio ofrece uso gratuito temporal del runtime antes del 1 de diciembre de 2026. Esa condición no cubre inferencia ni herramientas y servicios facturados aparte. La evaluación económica debe incluir todo el recorrido, no solo la tarifa del harness.
Un runtime gestionado puede quitar trabajo de mantenimiento, pero el criterio de aceptación sigue siendo tuyo. Si el informe suma mal o queda guardado en un lugar que el usuario no puede recuperar, el agente todavía no ha terminado la tarea.