De elegir modelos a diseñar sistemas: la era del AI Harness

El 28 de octubre GitHub anunció la disponibilidad general de Copilot Fusion. En vez de escoger un modelo para cada tarea, eliges Fusion y el sistema decide qué modelos y patrones de ejecución utilizar. La documentación de GitHub describe opciones como resolver con un modelo, escalar una respuesta para que otro la revise o generar una respuesta y pedir a otro modelo que la critique.

El modelo sigue importando, pero cambia la pregunta. Durante estos últimos años hemos comparado nombres y versiones: ¿cuál razona mejor?, ¿cuál escribe mejor código?, ¿cuál tiene más contexto? Ahora aparece otra pregunta, más arquitectónica: ¿qué sistema decide cómo usar modelos, datos y herramientas para completar el trabajo?

En un artículo anterior sobre qué es un harness y dónde vive, expliqué por qué dos herramientas con el mismo modelo pueden comportarse de forma distinta. Aquí quiero dar un paso más: ¿qué cambia cuando el propio sistema empieza a elegir y combinar modelos?

El modelo no es el sistema #

Un modelo genera respuestas y puede decidir, dentro de los límites de su interfaz, qué acción pedir. Pero para realizar trabajo útil necesita que algo le dé contexto, conecte herramientas, controle permisos y gestione qué ocurre cuando una acción falla o el resultado no es suficiente.

Ese conjunto de decisiones y componentes es lo que llamamos harness. Microsoft describe el harness de Agent Framework como el runtime que coordina llamadas al modelo y a las herramientas, mantiene el contexto y aplica políticas de aprobación. El término se usa con matices distintos, pero ayuda a entender dónde vive buena parte del comportamiento de un agente.

En una revisión de pull request, el modelo puede analizar el cambio, pero el resultado dependerá también de qué archivos recibe, qué herramientas usa, si ejecuta tests y qué condiciones debe cumplir antes de decir «terminado».

Aplicación
└── Tarea: revisar este cambio
    └── Harness
        ├── Contexto e instrucciones
        ├── Herramientas y permisos
        ├── Uno o varios modelos
        └── Verificación y límites

El modelo importa; el sistema que lo rodea determina cómo se convierte esa capacidad en trabajo.

¿El modelo se vuelve intercambiable? #

En parte. En el podcast semanal CompartiMOSS Unplugged solemos decir que el modelo es una “comodity”, en este caso concreto esto es, si una aplicación habla con una capa de orquestación y no directamente con un proveedor, esa capa puede seleccionar modelos sin reescribir toda la aplicación. Copilot Fusion es un ejemplo concreto: según GitHub, enruta cada tarea y puede orquestar modelos distintos para producir una respuesta.

Pero «intercambiable» no quiere decir «idéntico». Los modelos difieren en calidad, coste, latencia, límites y comportamiento con herramientas. Una interfaz común reduce el acoplamiento; no elimina la necesidad de probar cada combinación.

No asumiría que cualquier agente cambia de modelo como quien cambia una cadena de conexión. Hay que definir el resultado esperado y medirlo con tareas representativas, la selección automática es útil cuando se ajusta a unas políticas y criterios que podemos evaluar; si no, solo hemos escondido la decisión en otra caja negra.

Y una precisión importante: Copilot Fusion es una capacidad concreta de GitHub Copilot, no un estándar universal ni sinónimo de todos los harnesses. Es una señal de hacia dónde se mueve el producto, no una prueba de que cualquier aplicación vaya a poder delegar ya todas sus decisiones a un router mágico.

MCP, skills, agentes y harness: cada pieza en su sitio #

Se habla de modelos, agentes, MCP, skills y harnesses como si fueran sinónimos intercambiables, esto lo estoy viendo últimamente mucho en LinkedIn en artículos con infografías producidos por IA sin ningún criterio. No lo son:

La arquitectura oficial de MCP separa el host, los clientes y los servidores. Los servidores ofrecen capacidades; el host conserva el control de la conversación, los permisos y la integración con el modelo. Dicho de otra manera: MCP conecta capacidades, pero no define por sí solo cómo un agente debe resolver una tarea.

Las Agent Skills empaquetan instrucciones reutilizables que un agente carga cuando son pertinentes. Una skill puede explicar cómo hacer una revisión de seguridad; MCP puede proporcionar un escáner; el harness decide cómo usar ambos y con qué permisos.

Esta separación no es solo teórica, si una skill intenta ser un runtime, MCP acaba con todas las reglas de negocio o el agente recibe permisos de administrador «por comodidad», la arquitectura ya empieza a oler muy feo.

Copilot Fusion y GitHub Copilot harness no son lo mismo #

Antes mencioné Copilot Fusion como ejemplo de selección y orquestación de modelos. El nombre GitHub Copilot harness puede llevar a pensar que hablamos de lo mismo, pero Microsoft usa ese término para una opción de runtime de Copilot Studio. Fusion enruta modelos dentro de GitHub Copilot; el harness de Copilot Studio coordina agentes y herramientas para tareas de varios pasos. Son conceptos relacionados, pero no intercambiables.

¿Y qué pinta Foundry aquí? La documentación de Copilot Studio describe sus harnesses como runtimes distintos, con capacidades y costes diferentes. Además, permite conectar un agente de Microsoft Foundry como agente especializado al que puede delegar un agente principal creado con GitHub Copilot harness. Foundry aporta ese agente conectado; no es donde se ejecuta el harness de Copilot Studio.

No es una distinción puramente comercial: saber qué producto ejecuta cada parte ayuda a entender dónde se orquesta el trabajo y quién gobierna sus datos y costes. Los nombres se parecen; la arquitectura no tiene por qué hacerlo.

El trabajo del developer sube de nivel #

Si el harness decide más cosas, alguien tiene que diseñarlas y gobernarlas. El trabajo de ingeniería cambia de foco, no desaparece.

Como developers y arquitectos tendremos que decidir:

• qué tareas conviene resolver con un flujo determinista y cuáles justifican autonomía;
• qué datos y herramientas puede usar cada agente;
• qué acciones necesitan aprobación humana;
• cómo se escogen y evalúan los modelos;
• qué límites ponemos a latencia, coste e iteraciones;
• y qué evidencias deben existir antes de considerar una tarea completa.

Más autonomía también puede añadir consumo y latencia sin mejorar el resultado en problemas simples, como advierte Microsoft. No todos los procesos necesitan un agente que planifique, delegue, reintente y se reúna consigo mismo para tomar café. A veces una regla explícita sigue siendo mejor arquitectura.

No creo que dejemos de elegir modelos; creo que dejará de ser una decisión aislada. El trabajo importante estará en definir objetivo, contexto, herramientas, permisos y verificación, y dejar que el runtime combine modelos dentro de esos límites cuando tenga sentido.

El developer no desaparece del bucle. Se mueve hacia arriba en la pila de abstracción: de escribir cada línea a diseñar el sistema que permite producir, revisar y validar software con agentes. La pregunta ya no es solo «¿qué modelo pongo?». También es: ¿qué harness necesito para que este sistema haga el trabajo correcto, con el nivel de autonomía adecuado y sin llevarse algo por delante?

Recursos #

• GitHub: Route and orchestrate models with GitHub Copilot Fusion
• GitHub Docs: About GitHub Copilot Fusion
• Microsoft Learn: Agent Harness
• Microsoft Learn: Compare Copilot Studio agent harnesses
• Microsoft Learn: Add a Foundry agent as a connected agent
• Model Context Protocol: Architecture
• Agent Skills: Specification