Microsoft Copilot Studio está cambiando la forma en la que construimos agentes. Y detrás de conceptos como GitHub Copilot harness, Skills, Memory o Connected agents hay algo más importante que una nueva colección de funcionalidades: está cambiando la forma en la que repartimos la responsabilidad entre el maker y el runtime.
Si has entrado últimamente en Microsoft Copilot Studio, seguramente hayas tenido una sensación parecida a la mía. El producto sigue siendo reconocible, pero alrededor de los agentes empiezan a aparecer conceptos nuevos por todas partes: Skills, Memory, Connected agents, MCP, workflows… y, en medio de todos ellos, uno con un nombre especialmente llamativo:
GitHub Copilot harness.
Y reconozco que mi primera reacción al verlo fue bastante inmediata:
🤔 ¿Qué pinta GitHub Copilot dentro de Copilot Studio?
La respuesta corta es: bastante.
Pero probablemente no de la forma que parece por el nombre.
GitHub Copilot harness no significa que nuestros agentes de Copilot Studio estén ejecutándose sobre el servicio GitHub Copilot. Microsoft lo define como un framework de autoría y orquestación de Microsoft Copilot Studio. Comparte tecnología subyacente y componentes de SDK con GitHub Copilot, pero Microsoft especifica que los datos del cliente no se envían ni se procesan mediante el servicio GitHub Copilot cuando nuestros agentes se ejecutan en Copilot Studio. Los compromisos de privacidad, seguridad, cumplimiento y residencia de datos continúan siendo los de Microsoft Copilot Studio.
Y una vez aclarado esto, podemos entrar en lo realmente interesante. Porque GitHub Copilot harness no es simplemente otra opción dentro de Copilot Studio. Cambia la forma en la que el agente trabaja.
🪢 Entonces… ¿qué es exactamente un harness?
La palabra harness no forma parte precisamente del vocabulario tradicional de Power Platform, pero el concepto es bastante más fácil de entender de lo que parece.
Microsoft define un harness como la capa operativa situada entre el modelo y la configuración del agente. Es decir, determina cómo recibe contexto el modelo, cómo utiliza las instrucciones y las herramientas que ponemos a su disposición, cómo interpreta los resultados y cómo continúa avanzando hasta completar una tarea.
Dicho de una forma mucho menos académica:
🧠 El modelo aporta la capacidad de razonar
🪢 El harness organiza cómo trabaja
Y esta diferencia es importante. Cuando hablamos de IA generativa tendemos a mirar muchísimo el modelo.
- Qué modelo estamos utilizando.
- Cuál razona mejor.
- Cuál dispone de más contexto.
- Cuál obtiene mejores resultados.
Pero un modelo, por muy bueno que sea, no conoce por sí solo nuestros procesos empresariales ni sabe cómo queremos que se comporte nuestro agente.
- Necesita instrucciones.
- Necesita contexto.
- Necesita herramientas.
- Necesita límites.
- Y necesita una capa capaz de organizar todas esas piezas mientras intenta conseguir un resultado.
Eso es el harness.
Por eso creo que definir GitHub Copilot harness simplemente como “la nueva experiencia de Copilot Studio” se queda bastante corto. Estamos hablando también del runtime que organiza el trabajo del agente.
🎯 El verdadero cambio: de diseñar el camino a definir el resultado
Y aquí es donde, para mí, empieza la parte realmente interesante. Si llevamos tiempo trabajando con Copilot Studio estamos bastante acostumbrados a construir una parte importante del comportamiento del agente de forma explícita. Creamos topics, definimos triggers, utilizamos variables, añadimos condiciones, construimos ramas y decidimos qué ocurre después de cada paso. En mayor o menor medida, dibujamos el camino que queremos que recorra el agente. Ese enfoque no desaparece, de hecho, Microsoft sigue posicionando el Standard harness precisamente para escenarios donde necesitamos consistencia, control explícito y procesos relativamente acotados. Su contexto puede distribuirse entre topics, variables, herramientas, subagentes y otros componentes, proporcionando al maker mucho control sobre la ejecución.
GitHub Copilot harness desplaza parte de esa responsabilidad. Está pensado para escenarios donde el trabajo empieza a ser más pesado: tareas de mayor duración, archivos y conjuntos de datos mayores, razonamiento iterativo, agentic loops, tareas paralelas, memoria persistente o conversaciones entre subagentes que necesitan compartir contexto. Y eso modifica nuestro papel. Con Standard harness tendemos a explicar con mayor detalle cómo queremos que ocurra algo. Con GitHub Copilot harness podemos dedicar más esfuerzo a definir qué queremos conseguir, qué recursos puede utilizar el agente y cuáles son sus límites, dejando que el runtime tome más decisiones sobre cómo llegar hasta allí.
No dejamos de diseñar el camino
Dejamos de tener que decidir necesariamente cada uno de sus pasos
Ahora vuelve mentalmente a la primera captura del artículo. Allí no tenemos delante un gran canvas de ramas. Tenemos una superficie donde conviven las instrucciones del agente con piezas como Model, Skills, Tools, Knowledge, Connected agents y Memory. La captura actual de Microsoft muestra además Microsoft IQ dentro de esa misma superficie. No es casualidad en el GitHub Copilot harness, Microsoft reúne las piezas fundamentales de autoría alrededor del agente y apuesta por un enfoque mucho más natural-language-first. En lugar de definir por adelantado una gran cantidad de flujos conversacionales y ramificaciones, podemos describir mejor el agente, conectarle los recursos que necesita y establecer los límites que deben guiar su comportamiento.
Ahí está el cambio.
ANTES
Diseñábamos gran parte del camino
AHORA
Diseñamos también el espacio en el que el agente puede encontrar ese camino
No significa que el agente pueda hacer cualquier cosa. Significa que una parte mayor de la decisión sobre cómo alcanzar el objetivo ocurre durante la ejecución.
🏗️ Esto también cambia nuestro trabajo como makers
Si cambia el runtime, inevitablemente cambia aquello a lo que debemos prestar atención cuando construimos un agente. La nueva superficie de autoría hace que esto resulte especialmente visible. Ya no miramos únicamente topics, condiciones y acciones. Alrededor del agente empiezan a adquirir mucho más protagonismo sus Instructions, Knowledge, Tools, Skills, Model, Connected agents y Memory. A primera vista parece simplemente una lista de funcionalidades, pero podemos leerla de otra forma.
Instructions: ¿quién eres y cómo debes comportarte?
Knowledge: ¿qué sabes?
Tools: ¿qué puedes hacer?
Skills: ¿qué procedimientos o formas de trabajar conoces?
Model: ¿con qué capacidad razonas?
Connected agents: ¿a quién puedes pedir ayuda?
Memory: ¿qué puedes recordar?
Y yo añadiría una pregunta más:
¿Qué NO puedes hacer?
Porque cuanto más peso trasladamos al runtime, más importantes se vuelven las instrucciones, los límites y el contexto con el que estamos trabajando. Esto significa que algunas cosas que antes podíamos considerar casi “documentación” empiezan a tener peso arquitectónico.
- Cómo describimos una capacidad.
- Cómo delimitamos el propósito del agente.
- Qué contexto ponemos a su disposición.
- Cómo separamos responsabilidades.
- Qué dejamos bajo razonamiento y qué queremos mantener completamente controlado.
Diseñar un agente empieza a parecerse menos a dibujar exclusivamente una conversación y más a diseñar un sistema.
Y cuando empezamos a pensar en agentes como sistemas, también aparece inevitablemente otra conversación: cómo gobernarlos cuando empiezan a crecer en número y autonomía.
⚔️ Entonces, ¿GitHub Copilot harness sustituye al Standard harness?
No.
Y creo que merece la pena decirlo claramente porque es probablemente una de las conclusiones más fáciles, y más equivocadas, a las que podemos llegar. Microsoft mantiene los agentes basados en Standard harness completamente soportados junto a los agentes powered by GitHub Copilot harness.
Y la propia documentación insiste en una idea que me parece especialmente sensata:
Ninguno de los dos harnesses es universalmente mejor.
Standard harness resulta especialmente apropiado cuando trabajamos con procesos relativamente cortos y acotados, necesitamos un comportamiento consistente y valoramos el control explícito sobre la ejecución. GitHub Copilot harness cobra más sentido cuando el problema requiere procesos largos, razonamiento profundo, gran cantidad de contexto, coordinación entre herramientas y sistemas, adaptación a resultados intermedios o varios outputs. Y aquí hay un detalle de la documentación de Microsoft que me parece especialmente importante. Tener acceso a un runtime más potente no significa que debamos utilizarlo para todo. Si aplicamos un harness más pesado sobre un problema sencillo podemos acabar introduciendo más razonamiento, más latencia y mayor consumo de Copilot Credits sin conseguir necesariamente un resultado mejor.
💡 Más autonomía no significa automáticamente mejor arquitectura
Creo que esta debería convertirse en una regla bastante importante cuando diseñemos agentes.
Si lo reducimos a las diferencias que realmente influyen en una decisión de arquitectura, podemos verlo así:
| Aspecto | Standard harness | GitHub Copilot harness |
|---|---|---|
| Mejor encaje | Procesos cortos, acotados y estructurados | Procesos largos, complejos y con múltiples pasos |
| Contexto | Más distribuido entre topics, variables, herramientas y subagentes | Contexto compartido más amplio entre recursos y agentes |
| Control | Mayor control explícito sobre la ejecución | Mayor autonomía del runtime para decidir cómo avanzar |
| Adaptación | El maker define más rutas, condiciones y excepciones | Puede reevaluar resultados y adaptar los siguientes pasos |
| Latencia y consumo | Más proporcionado para tareas sencillas y predecibles | Puede implicar mayor latencia y consumo de Copilot Credits |
| Elegirlo cuando… | La consistencia y la predictibilidad son prioritarias | El razonamiento, la coordinación y la adaptación aportan valor |
🧭 Entonces, ¿cómo elegir?
Yo evitaría empezar por la tecnología, empezaría por el problema.
Si tengo una conversación estructurada, un conjunto conocido de acciones y un comportamiento donde la consistencia y la predictibilidad son requisitos del producto, Standard harness puede seguir siendo exactamente la arquitectura que necesito. Por ejemplo, pensemos en un proceso interno de soporte donde siempre necesitamos recoger determinada información, consultar un conjunto conocido de fuentes y terminar ejecutando una lógica relativamente estable. Ahí conocer bien el camino no es una limitación, es una ventaja.
Ahora imaginemos algo bastante diferente. Un agente debe preparar de extremo a extremo una reunión importante con un cliente. Tiene que consultar correos, notas de reuniones, CRM e incidencias de soporte. Después necesita identificar riesgos y oportunidades, detectar información contradictoria, preparar un briefing, quizá generar distintos documentos y terminar proponiendo acciones. Ya no tenemos una interacción corta con un único resultado. Tenemos contexto distribuido, varias herramientas, múltiples pasos, reasoning y diferentes outputs. Ese tipo de trabajo empieza a justificar un runtime capaz de reevaluar continuamente dónde está y qué debería hacer después.
Por eso mi pregunta ya no sería:
“¿Cuál es el harness más potente?”
Sería:
¿Cuánto pesa realmente el problema que quiero resolver?
Y elegiría el runtime proporcional a ese peso.
⚠️ Y hay otra razón para pensarlo antes de empezar
La elección no es simplemente un toggle que podamos cambiar alegremente después.
Microsoft indica actualmente que los agentes creados con GitHub Copilot harness no pueden transferirse al Standard harness, ni los del Standard harness al GitHub Copilot harness. El harness se elige al crear el agente. Esto refuerza todavía más algo que hasta ahora quizá no nos planteábamos con tanta intensidad:
🏗️ Elegir el harness empieza a ser una decisión de arquitectura
Y como cualquier decisión arquitectónica debería partir del escenario, de sus requisitos, de sus limitaciones y del resultado que queremos conseguir. No de cuál sea la opción más nueva del menú.
💡 Entonces… ¿qué es lo que realmente está cambiando?
Podemos quedarnos con la palabra harness.
O con las nuevas pestañas.
O con que existe una nueva forma de crear agentes mediante lenguaje natural.
Pero creo que eso sería quedarse en la superficie. Para mí, el cambio interesante está en cómo repartimos la responsabilidad entre nosotros y el runtime. Seguimos siendo responsables de diseñar el agente, pero cada vez será más importante que sepamos definir correctamente el objetivo, el contexto, las capacidades, las instrucciones, los límites y los criterios con los que evaluaremos que el trabajo está bien hecho.
El “cómo” no desaparece.
Simplemente una parte de ese “cómo” puede empezar a decidirse dinámicamente durante la ejecución.
✨ IDEA FINAL
ANTES
Diseñábamos gran parte del camino
AHORA
Diseñamos también el espacio en el que el agente puede encontrar ese camino
Y quizá esa sea la mejor forma de entender qué supone GitHub Copilot harness para Microsoft Copilot Studio.
No es otro Copilot.
No es solamente otra interfaz.
Es una forma diferente de repartir el trabajo entre maker, modelo y runtime.
Y eso sí cambia bastante las reglas del juego.
🔜 Continuará…
Hasta aquí hemos hablado del cambio de arquitectura.
Pero queda una pregunta bastante importante:
¿Qué capacidades hacen posible que el agente pueda asumir realmente esa responsabilidad?
Ahí empiezan a entrar Tools, MCP, Workflows, Skills, Connected agents y Memory.
Y ahí es donde la cosa se pone todavía más interesante.
👉 En la segunda parte: GitHub Copilot Harness en Copilot Studio (2/2): cuando el agente deja de responder y empieza a trabajar.
📚 Fuentes oficiales
La información de este artículo ha sido contrastada exclusivamente con documentación oficial de Microsoft Learn, revisada en octubre de 2026.
- Microsoft Learn — Agents powered by the GitHub Copilot Harness overview
- Microsoft Learn — Compare Copilot Studio agent harnesses
- Microsoft Learn — Agents overview
- Microsoft Learn — Edit and manage your agent flow in the designer
Nota editorial: Microsoft Copilot Studio está evolucionando rápidamente. Los estados, capacidades y experiencias descritos corresponden a la documentación oficial disponible en octubre de 2026 y pueden cambiar posteriormente.
Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.