La era del harness de agentes: por qué la orquestación multimodelo se está convirtiendo en la verdadera plataforma de IA

Durante la mayor parte del auge de la IA generativa, el relato público giró en torno a los modelos: qué laboratorio tenía los mejores resultados en las pruebas de referencia, qué número de parámetros sonaba más impresionante, qué chatbot parecía más afinado ese mes. Ese relato no es falso, pero sí incompleto. A finales de octubre de 2026, Microsoft y GitHub hicieron explícita una capa más discreta: lo que de verdad convierte un modelo en trabajo agéntico útil es el harness, el entorno de ejecución que envuelve a los modelos con instrucciones, contexto, herramientas, entornos aislados (sandboxes), enrutamiento y gobernanza.

El 28 de octubre, Microsoft anunció que el Microsoft Copilot harness, nacido dentro de GitHub y que ya impulsa las experiencias de Copilot en toda la compañía, estaría disponible a través de Microsoft Foundry. Ese mismo día, la conferencia GitHub Universe llevó al escenario la orquestación multimodelo con el nombre de Copilot Fusion y vinculó a ese harness la continuidad de las sesiones, los agentes en la nube y la ventana Agents de VS Code. El mensaje fue tajante: quien quiera competir con varios modelos necesita un harness excelente para completar trabajo real.

Este artículo se centra en esa capa de plataforma (el bucle del agente, el enrutamiento multimodelo, los entornos aislados, MCP y las habilidades, y la cuestión de quién controla el entorno de ejecución) y en cómo se relaciona con el giro hacia el work OS y con los campos de batalla del navegador, el IDE y el sistema operativo que analizamos anteriormente.

Qué es realmente un harness

La propia definición de Microsoft tiene la virtud de la sencillez. Si el modelo aporta la inteligencia, el harness es todo lo que lo rodea: la capa de orquestación que proporciona a un agente las instrucciones, el contexto, el entorno de ejecución y los controles adecuados para realizar un trabajo significativo. Un harness que merezca comercializarse, añade la compañía, admite estándares abiertos como MCP y las habilidades de agentes (agent skills), además de complementos de agentes.

Este enfoque importa porque desplaza el producto. Un modelo de frontera es un ingrediente. Una ventana de chat es una superficie. El harness es la planta de producción: decide cómo se divide una tarea, qué modelo procesa cada parte, qué herramientas pueden invocarse, dónde se ejecuta el código, cómo se reintentan los fallos, cuánto dura una sesión y qué puede auditar una empresa a posteriori.

También explica por qué construir uno es difícil. Los modelos cambian constantemente. Los ecosistemas de herramientas también. La latencia, el coste en tokens y la calidad se equilibran de forma distinta según la carga de trabajo. Mantener un enrutador y una infraestructura de evaluación que abarquen varios proveedores resulta penoso si cada equipo de producto inventa los suyos. La apuesta de Microsoft es que el mismo harness que GitHub diseñó para desarrolladores exigentes puede convertirse en un producto para todos los demás a través de Foundry, como SDK descargable o como servicio gestionado en la nube: los clientes aportan sus instrucciones, habilidades, herramientas y elección de modelos, mientras Microsoft ejecuta el bucle del agente y el entorno aislado con la gobernanza y la optimización integradas.

El punto de inflexión del 28 de octubre: Foundry y Universe

Microsoft Foundry y un entorno de ejecución de Copilot común a toda la compañía

En la entrada del Official Microsoft Blog que presenta el harness, Tina Schuchman, vicepresidenta corporativa de Foundry, y Vladimir Fedorov, director de tecnología de GitHub, describen un entorno de ejecución ya adoptado en toda la compañía. Impulsa Copilot Code, Copilot Studio, la aplicación GitHub Copilot, la interfaz de línea de comandos, VS Code y otros productos. Su disponibilidad en Foundry se presenta como una forma, para desarrolladores y empresas, de crear de manera totalmente gestionada agentes que razonan, utilizan herramientas y completan tareas complejas y de larga duración, sin cambiar de harness cada vez que cambian de modelo.

Varias afirmaciones técnicas merecen destacarse, porque definen el relato de plataforma:

• Multimodelo por diseño. El harness está concebido para funcionar con distintas familias de modelos, con más de 20 modelos de frontera y la posibilidad de usar claves propias (BYOK), de modo que el trabajo pueda dirigirse al modelo adecuado para cada tarea en lugar de imponer uno por defecto en todas partes.
• Entorno de ejecución en Rust. Microsoft afirma haber portado recientemente el entorno de ejecución del harness a Rust, con reducciones en la sobrecarga de las sesiones y en el tiempo hasta el primer token, y acompaña esa reescritura de la promesa de un «rendimiento líder en el sector».
• Postura abierta e interoperable. Las plataformas siguen siendo lo bastante abiertas para que los clientes puedan recurrir a otros harness y marcos de trabajo; el argumento es la comodidad y la mejora compartida, no un bloqueo estricto que impida las alternativas.
• Mejoras acumulativas. Basta con mejorar el harness una vez para que se beneficien todas las superficies que funcionan sobre él: un argumento clásico de círculo virtuoso de plataforma.

GitHub Universe: Fusion, sesiones y sistema de entrega de software

El planteamiento de la conferencia inaugural de Universe, a cargo de Jay Parikh, vicepresidente ejecutivo de CoreAI en Microsoft, presenta GitHub como un sistema integral de entrega de software para los desarrolladores y para sus agentes. Los desarrolladores marcan el rumbo y siguen siendo responsables; los agentes implementan y verifican; lo que importa es el trabajo terminado, no más código por sí mismo.

Dentro de esa visión, Copilot Fusion es el gran anuncio en materia de orquestación multimodelo. Cada tarea requiere modelos distintos, y los desarrolladores no deberían tener que gestionar cada elección de modelo para obtener el resultado adecuado al precio adecuado. Fusion evalúa lo que necesita una tarea en razonamiento, generación de código, depuración y uso de herramientas, y después decide cómo ejecutarla con uno o varios modelos. GitHub cita el Artificial Analysis Coding Agent Index: Fusion Max obtuvo una puntuación a menos de dos puntos de la de Opus 5.5 Max, con la mitad de coste y un 40 % menos de tiempo por tarea.

En torno a Fusion se articulan productos que solo tienen sentido si existe un harness compartido por debajo:

• Copilot projects ejecuta el trabajo de los agentes en varios repositorios, en sesiones paralelas y totalmente gestionadas, con un único lugar para seguir el progreso y decidir los siguientes pasos.
• La continuidad de las sesiones permite que una misma sesión de agente en la nube pase de la aplicación GitHub Copilot a VS Code, a la interfaz de línea de comandos y a la web: se inicia en el teléfono durante la reunión diaria, se dirige desde el ordenador de sobremesa y se consulta en github.com, mientras el agente sigue trabajando en la nube.
• Copilot automations crea en un repositorio flujos de trabajo basados en IA, activados manualmente, por un evento o según un calendario, que pueden aprender de sus resultados para proponer mejoras sujetas a aprobación humana.
• Copilot code review Max ofrece una revisión más exhaustiva cuando un cambio lo requiere; GitHub afirma haber obtenido la mejor puntuación F1 en ReviewBench para problemas de gravedad alta, y mantiene las versiones Lite y Balanced para la rapidez del día a día.
• El modelo comercial. Desde ese día, los clientes de GitHub Enterprise pueden usar las funciones de Copilot sin una suscripción independiente a Copilot y pagar por los créditos de IA que consuman; la modalidad de autoservicio llegará próximamente, según la compañía.

El registro de cambios de VS Code publicado ese mismo día hace tangible el harness para los desarrolladores: el Copilot harness, construido sobre el Microsoft Copilot SDK, pasa a ser la opción predeterminada para las nuevas sesiones tanto en el editor como en la ventana Agents. Las sesiones en la nube pueden iniciarse en VS Code y continuar en la aplicación Copilot, en el móvil, en github.com o en Copilot CLI; los mensajes directos de Slack o Teams pueden derivarse a esos mismos clientes. Un Agent Host aísla las sesiones de las ventanas individuales, de modo que el trabajo continúa después de cerrar una carpeta. Una función experimental de uso del ordenador puede interactuar con aplicaciones de escritorio previa aprobación aplicación por aplicación. Un protocolo abierto, el Agent Host Protocol (AHP), permite que clientes de terceros se mantengan sincronizados con las sesiones en curso. Un Customization Marketplace (en versión preliminar) reúne habilidades, servidores MCP y complementos. Los Copilot connectors (en versión preliminar) aportan contexto de servicios como Slack, Notion y Microsoft Learn sin necesidad de instalar un servidor MCP local.

En conjunto, el 28 de octubre fue menos una avalancha de funciones que una declaración: el entorno de ejecución es el producto.

Anatomía de la capa de plataforma

El bucle del agente

Todo sistema de agentes serio converge en un bucle: reunir contexto, planificar o elegir el siguiente paso, invocar herramientas o generar artefactos, observar los resultados y, por último, continuar o detenerse para consultar a una persona. El harness es el dueño de ese bucle. Cuando Microsoft afirma que «ejecuta el bucle del agente y el entorno aislado», reivindica la propiedad de la máquina de estados que mantiene la coherencia de una tarea de larga duración a través de las llamadas a modelos, los fallos de herramientas y los cambios de superficie.

Por eso la continuidad de las sesiones es una función del harness y no un simple detalle de interfaz. Si el bucle reside en la nube, bajo un entorno de ejecución gestionado, cerrar el portátil no debería interrumpir el trabajo. Si solo reside en el proceso de un editor local, lo interrumpirá.

El enrutamiento multimodelo

El enrutamiento es el núcleo económico y cualitativo de la era del harness. Un modelo excelente en razonamiento profundo puede resultar demasiado lento o caro para modificaciones rutinarias; un modelo de código rápido puede flaquear en la planificación. La afirmación pública de Fusion (calidad cercana a la de los modelos de frontera con la mitad de coste y bastante menos tiempo en un índice público de agentes de programación) es exactamente lo que los compradores quieren oír: la orquestación como optimizador de coste y latencia, y no solo como recurso para mejorar la calidad.

El planteamiento de Microsoft en torno a Foundry va más allá: confiar en el proveedor para evaluar los nuevos modelos y enrutar de forma inteligente, en lugar de reconstruir ese equipo científico en cada empresa. Que los clientes se fíen o no de esa caja negra será una de las cuestiones decisivas en las compras de 2027.

Entornos aislados y permiso para actuar

Los agentes adquieren valor cuando pueden actuar: editar archivos, ejecutar pruebas, accionar controles del escritorio, actualizar incidencias. Por la misma razón se vuelven peligrosos. Los entornos aislados, los puntos de aprobación y los controles de políticas no son, por tanto, funciones accesorias: marcan la diferencia entre una demostración y una plataforma desplegable. El experimento de uso del ordenador en VS Code resulta revelador: cada aplicación requiere aprobación, las organizaciones pueden desactivar la función mediante políticas y la capacidad se presenta como experimental. Es el harness haciendo trabajo de producto: ofrece potencia sin dejar de mantener configurable el alcance de los posibles daños.

MCP, habilidades y la frontera abierta de un entorno de ejecución cerrado

El Model Context Protocol se presenta como un puerto USB-C para las aplicaciones de IA: una forma estándar de conectar los asistentes con datos, herramientas y flujos de trabajo. Las Agent Skills, especificadas en agentskills.io, empaquetan flujos de trabajo reutilizables como directorios con un archivo SKILL.md obligatorio (nombre y descripción en un encabezado YAML, más instrucciones en Markdown) y, opcionalmente, scripts, referencias y recursos, que se cargan mediante divulgación progresiva. La extensión oficial MCP Skills (io.modelcontextprotocol/skills, SEP-2640 en estado Final) vincula ese formato a los recursos de MCP mediante skills/list, skills/get y resources/read, con comprobaciones de integridad de manifiestos y resúmenes criptográficos.

La entrada de Microsoft sobre el harness menciona expresamente MCP y las habilidades de agentes como estándares que todo harness serio debe admitir. El marketplace y los conectores de GitHub muestran su expresión comercial: descubrimiento y contexto con un solo clic, siempre bajo las políticas de la empresa. La tensión estratégica es evidente. Los protocolos abiertos hacen portables las herramientas y las habilidades; un harness gestionado hace que el bucle fidelice. Portabilidad en la periferia y fuerza de atracción en el entorno de ejecución: es el patrón clásico de las plataformas.

¿Quién controla el entorno de ejecución?

El control del harness decide mucho más que las cifras de latencia. Decide:

1. Qué modelos son de primera categoría. Un menú desplegable con más de 20 modelos parece abierto; son los valores predeterminados del enrutador y su batería de evaluaciones los que determinan qué se usa realmente en la mayoría de las tareas.
2. Dónde residen la memoria y el estado de las sesiones. La continuidad entre teléfono, IDE, interfaz de línea de comandos y web es un mecanismo de retención tanto como una comodidad.
3. Qué herramientas resultan fáciles de usar. Los marketplaces, los conectores y los servidores MCP avalados determinan lo que los agentes pueden hacer desde el primer día.
4. Cómo es la seguridad. Los valores predeterminados de los entornos aislados, la política de uso del ordenador, las listas de complementos autorizados y los registros de auditoría residen en el harness, no en los pesos del modelo.
5. Quién se queda con el margen. La comercialización por créditos de las funciones de Copilot para GitHub Enterprise desplaza el centro de gravedad comercial hacia un trabajo de agentes medido por uso, que se ejecuta en el bucle de otro.

Por eso la era del harness conecta directamente con nuestros análisis anteriores. En De los chatbots al work OS, el asistente se convierte en el lugar donde el trabajo empieza y termina; los conectores y un MCP con capacidad de escritura transforman el chat en un centro de mando. En Navegador, IDE y SO: los tres campos de batalla de las interfaces de IA, el IDE ya mostraba que el valor se concentra en la revisión, la gobernanza y el sistema de registro. El harness es el eslabón que faltaba: el entorno de ejecución que permite a cualquier superficie (work OS, IDE o anfitrión de agentes del sistema operativo) ejecutar agentes multimodelo sin reinventar la orquestación.

Qué vigilar a partir de ahora

Algunas pruebas prácticas mostrarán si el harness se convierte de verdad en la plataforma:

• Transparencia de las evaluaciones. La referencia de Fusion a Artificial Analysis es un comienzo; las empresas exigirán que el enrutamiento sea explicable tarea por tarea y el derecho a anular el enrutador.
• Vías de salida. La afirmación de Microsoft de que se puede recurrir a otro harness solo tiene valor si la exportación de habilidades, configuraciones de herramientas y semántica de sesiones es real.
• Habilidades entre proveedores. Si las Agent Skills sobre MCP llegan a ser tan anodinas como los contenedores, la competencia se desplazará hacia la fiabilidad y el precio.
• Cargas de trabajo ajenas a la programación. La programación encajó primero porque los cambios de código pueden revisarse; la propuesta agéntica más amplia de Foundry aún debe demostrar que completa con seguridad y a gran escala los flujos de trabajo empresariales más rutinarios.
• La fuerza de atracción de la infraestructura. Las ampliaciones de infraestructura que GitHub comunica para 2026 (4 millones de núcleos de CPU, 160 PB de almacenamiento de alta velocidad, 50 Tb/s de capacidad de red, además de una migración a Azure en varias regiones) recuerdan a los compradores que las plataformas de agentes son también plataformas intensivas en capital.

El modelo no es el producto

Los modelos de frontera seguirán avanzando a saltos. Precisamente por eso, vincular una empresa a un único modelo como plataforma es una estrategia frágil. La capa duradera es la que puede cambiar de modelo, mantener el bucle en marcha, aislar los efectos secundarios, hablar MCP y habilidades, y mejorar todas las superficies conectadas cuando mejora el entorno de ejecución.

El 28 de octubre no inventó esa idea. La industrializó: el harness multimodelo de GitHub, probado sobre el terreno, estandarizado en todo Copilot, abierto a través de Foundry e integrado en productos que tratan a los agentes como trabajadores de pleno derecho. En la era del harness de agentes, la verdadera plataforma de IA no es la ventana de chat ni los pesos del modelo. Es el entorno de ejecución que decide cómo se programa, se acota y se paga la inteligencia.

Lecturas relacionadas

• De los chatbots al work OS: cómo los asistentes de IA se comen el SaaS empresarial
• Navegador, IDE y SO: los tres campos de batalla de las interfaces de IA
• Llegan los agentes siempre activos: Claude Duet, Muse Wonder y Perplexity Teammates

Imágenes: ilustraciones originales creadas para AndBeyond.Tech; no aparecen logotipos ni personas reales.