🧠 GitHub Copilot Harness en Copilot Studio (2/2): cuando el agente deja de responder y empieza a trabajar

En la primera parte de esta serie terminé con una idea que, cuanto más trabajo con este tema, más sentido me parece que tiene:

Antes diseñábamos gran parte del camino. Ahora diseñamos también el espacio en el que el agente puede encontrarlo.

Pero había dejado algo pendiente, porque encontrar el camino está muy bien.

Recorrerlo es otra cosa.

Un modelo puede razonar sobre una petición. Puede interpretar información, resumirla o proponernos una solución. Pero si queremos que un agente realmente trabaje, en algún momento tendrá que hacer cosas:

• Consultar un sistema.
• Ejecutar un proceso.
• Analizar un documento.
• Crear un archivo.
• Pedir ayuda a otro agente.
• Recordar algo que ocurrió anteriormente.
• O incluso detenerse porque la acción que quiere realizar necesita nuestra aprobación.

Y es ahí donde piezas que por separado pueden parecer simplemente otra colección de funcionalidades de Copilot Studio empiezan a encajar entre sí.

En esta segunda parte veremos cómo Tools, MCP, Workflows, Skills, Connected agents y Memory trabajan juntas dentro de GitHub Copilot harness para convertir un objetivo en acciones y resultados.

🏗️ Primero necesito ver el dibujo completo

No vengo del desarrollo puro, así que mi forma de entender este tipo de arquitecturas suele ser bastante sencilla: intento averiguar qué responsabilidad tiene cada pieza. Como vimos al explicar qué es GitHub Copilot harness y qué papel desempeña entre el modelo y el agente, empieza a resultar mucho más fácil de entender si lo miramos así.

El agente no necesita utilizar todo en cada ejecución. El harness decide qué capacidades necesita según el objetivo, el contexto y sus instrucciones.

🛠️ Tools: cuando el agente necesita hacer algo fuera de la conversación

Probablemente esta sea la pieza más sencilla de entender.

Una Tool es algo que permite que el agente haga algo que el modelo no puede resolver simplemente escribiendo una respuesta. Por ejemplo: consultar una aplicación, crear un ticket, recuperar información actual, actualizar un registro o ejecutar una acción en otro sistema.

Microsoft define las Tools precisamente como capacidades externas que permiten al agente ir más allá de responder utilizando conocimiento. El orquestador puede decidir qué herramienta utilizar basándose en el contexto de la conversación y en la descripción de esa herramienta. Y aquí aparece algo que me parece muy importante para quienes venimos de un enfoque más funcional.

Poner nombre a las cosas empieza a importar muchísimo.

No es lo mismo proporcionar al agente una herramienta llamada Ticket Tool que otra llamada Create Urgent Support Ticket acompañada de una descripción clara de cuándo debe utilizarse y qué resultado devuelve. Microsoft recomienda precisamente utilizar nombres específicos y descripciones que expliquen cuándo debe utilizarse la herramienta y qué hace. Esto cambia bastante la forma de pensar.

Porque una buena descripción ya no sirve solo para que nosotros entendamos una configuración. También ayuda al agente a tomar decisiones.

💡 En un sistema agentic, describir bien una capacidad empieza a formar parte de su comportamiento.

🔌 MCP: un “enchufe” común para nuevas capacidades

MCP puede sonar bastante más técnico de lo que necesitamos que sea para comprender su impacto. Yo lo pienso de una forma muy sencilla, si las Tools son las cosas que un agente puede utilizar, MCP es una forma estándar de presentarle un conjunto de esas capacidades. Un servidor MCP puede decirle al agente, en esencia:

“Estas son las cosas que sé hacer.”

Y el runtime puede decidir cuándo utilizar alguna de ellas.

Microsoft ya permite añadir servidores MCP como Tools en agentes powered by GitHub Copilot harness, aunque esta incorporación continúa documentada dentro de las capacidades en preview. Pero precisamente aquí aparece una evolución que me parece especialmente interesante.

MCP ya no quiere quedarse únicamente en “hacer cosas”

Microsoft tiene en preview MCP Apps para Copilot Studio. ¿Qué cambia?

Hasta ahora podemos imaginar una Tool devolviendo información que después el agente transforma en una respuesta. Con MCP Apps, una herramienta compatible podrá devolver además una experiencia visual interactiva dentro de la propia conversación: por ejemplo, una tabla que podamos ordenar o información en la que podamos hacer drill-down. Esto me parece importante porque elimina otra frontera, el chat deja de ser únicamente una sucesión de texto. Puede empezar a convertirse también en una superficie donde consultar y actuar, y para mí esa es una evolución bastante natural de los agentes.

No siempre quiero que me expliques una tabla, a veces quiero verla, explorarla y decidir sobre ella.

⚙️ Workflows: que el agente razone no significa que todo tenga que ser impredecible

Esta es probablemente una de mis ideas favoritas de todo este tema. Cuando escuchamos agentic podemos caer fácilmente en la tentación de pensar:

“Ahora la IA decide absolutamente todo.”

Pero eso no sería necesariamente una buena arquitectura. Hay decisiones donde queremos razonamiento y hay procesos donde queremos exactamente lo contrario:

Que siempre ocurran de la misma forma.

Imagina que el agente detecta que una factura necesita revisión. Puede utilizar razonamiento para identificar la excepción. Pero quizá el proceso posterior tenga que cumplir siempre una secuencia concreta: validar determinados datos, avisar a una persona, solicitar una aprobación y registrar el resultado. Ahí es donde entra un Workflow. El agente puede decidir cuándo necesita ejecutar ese proceso y el workflow garantiza cómo se ejecuta.

🧠 El agente decide qué necesita hacer.
⚙️ El workflow asegura cómo debe hacerse.

Este equilibrio me parece especialmente importante en entornos empresariales, porque autonomía no debería significar perder control.

✋ Y ahora podemos decidir cuándo el agente necesita permiso

Aquí entra una de las novedades recientes que más me gustan. Podemos escribir en las instrucciones:

“Pregunta antes de enviar un correo.”

Pero una instrucción sigue siendo una instrucción interpretada por un modelo. ¿Y si queremos algo que no dependa de esa interpretación?

Microsoft ha anunciado la posibilidad de configurar aprobación humana para determinadas llamadas a Tools. La idea es sencilla: podemos marcar una herramienta concreta para que, antes de ejecutarla, el agente se detenga y explique qué quiere hacer. La persona podrá aprobarlo, aprobarlo durante esa sesión o rechazarlo.

Microsoft utiliza ejemplos como enviar correos, cerrar tickets o procesar pagos.

Este diagrama explica muy bien una arquitectura agentic empresarial sin necesidad de entrar en profundidad técnica. La autonomía puede convivir con controles deterministas.

🧩 Skills: no todo consiste en darle más herramientas

Aquí hay otra distinción que al principio me costó entender.

Una Tool permite hacer algo y una Skill ayuda al agente a saber cómo abordar algo.

Microsoft define una Skill como una capacidad formada por nombre, descripción e instrucciones en Markdown, que además puede incluir scripts, plantillas, referencias y otros recursos. Son piezas autocontenidas que podemos crear, compartir y reutilizar. Por ejemplo, podríamos crear una Skill llamada Review Technical Architecture. No necesariamente conecta el agente a ningún sistema, puede simplemente enseñarle cómo debe realizar siempre ese tipo de revisión: qué puntos comprobar, qué evidencias buscar, qué riesgos identificar, qué estructura seguir y qué resultado entregar.

A mí me ayuda verlo así:

🛠️ Tool: dame acceso a algo.
🧩 Skill: enséñame una forma de trabajar.

De Skills individuales a un catálogo de Skills de la organización

Microsoft tiene ya en preview el Skills Catalog. La idea es que los makers puedan descubrir y reutilizar Skills aprobadas por su organización en lugar de volver a construir las mismas instrucciones y procedimientos para cada agente. Esto cambia bastante la escala de la conversación, ya no hablamos únicamente de:

“He creado una Skill para mi agente.”

Podemos empezar a hablar de:

“Esta es una forma de trabajar aprobada por mi organización y disponible para distintos agentes.”

Y eso tiene mucho que ver con consistencia, reutilización y gobierno.

🤝 Connected agents: dejar de construir un agente que sabe de todo

Otra idea que me parece bastante fácil de trasladar al mundo real es la especialización. Cuando una solución crece tenemos dos opciones:

• Podemos seguir añadiendo instrucciones, herramientas y conocimiento a un agente cada vez mayor.
• O podemos dividir responsabilidades.

Los Connected agents permiten precisamente esto: un agente puede delegar una tarea en otro agente especializado.

Si pensamos en un agente de RRHH, podríamos tener algo como esto:

No hace falta que el agente principal conozca cada detalle, necesita saber qué especialista puede resolver cada parte.

No construyas necesariamente una persona que sepa de todo. Construye un equipo que sepa repartirse el trabajo.

💾 Memory: cuando no todo empieza de cero

Hasta aquí tenemos un agente que puede actuar, utilizar procedimientos y pedir ayuda. Pero seguimos teniendo otra limitación bastante humana, tener que volver a explicar lo mismo una y otra vez.

Memory permite que el agente conserve determinados detalles de interacciones anteriores y los utilice después. Microsoft lo explica mediante un ciclo muy simple:

Capture → Store → Apply.

Captura determinadas señales, las guarda, y puede aplicarlas en futuras interacciones. Cada usuario dispone de un almacén separado, por lo que la memoria de una persona no se comparte con otra.

Lo importante aquí, para mí, no es únicamente que el agente pueda recordar es preguntarnos: ¿Realmente queremos que recuerde esto?

Porque Memory no debería convertirse en:

“Activo el toggle y listo.”

Es otra decisión de diseño

• Qué mejora la experiencia.
• Qué debería seguir siendo efímero.
• Qué contexto aporta valor y dónde empieza a dejar de aportarlo.

🧩 GitHub Copilot Harness: qué hace cada pieza

Después de ver cada componente por separado, podemos resumir su papel dentro del harness así:

Pieza	Para qué sirve
Tool	Permite al agente ejecutar una acción o acceder a una capacidad externa.
MCP	Expone herramientas al agente mediante un protocolo estándar.
Workflow	Ejecuta un proceso multietapa de forma determinista.
Skill	Enseña al agente cómo abordar un tipo de tarea.
Connected agent	Permite delegar una tarea en otro agente especializado.
Memory	Conserva contexto útil entre interacciones.

📄 Y aquí es cuando deja de parecerme un chatbot

Hay una diferencia que resume bastante bien todo lo anterior. Un chatbot suele empezar con:

“Tengo una pregunta.”

Pero cada vez más escenarios de agentes empiezan con:

“Necesito que hagas esto.”

GitHub Copilot harness está orientado precisamente a trabajos complejos y de varios pasos.

Microsoft documenta soporte nativo para crear, editar y razonar sobre Word, Excel, PowerPoint y PDF, además de la capacidad de trabajar con herramientas, Connected agents, Skills y Memory dentro de ese proceso. Además, un usuario puede adjuntar documentos a una conversación para que el agente los analice durante ese trabajo.

Pensemos, por ejemplo, en:

“Prepárame la reunión de mañana con este cliente.”

Eso podría implicar consultar datos, leer documentación, identificar temas pendientes, utilizar una herramienta, pedir ayuda a otro agente, generar un Excel, crear una presentación y entregar finalmente un briefing. Aquí ya no hablamos solamente de responder, hablamos de completar trabajo.

Un chatbot recibe una pregunta y devuelve una respuesta.
Un agente puede recibir un objetivo y trabajar hasta producir un resultado.

🧪 Cuanta más autonomía damos, menos sentido tiene probar con tres prompts y confiar

Este es probablemente uno de los aprendizajes más importantes. Si hemos creado un flujo completamente predecible, es relativamente fácil recorrer sus ramas y comprobarlas. Pero si permitimos que un agente decida qué herramienta necesita, adapte su estrategia o delegue trabajo, una demo que ha salido bien no demuestra demasiado.

Copilot Studio dispone de evaluaciones para agentes powered by GitHub Copilot harness precisamente para comprobar de forma más sistemática su comportamiento y esto conecta con una de las novedades anunciadas estos días que, personalmente, me parece más interesante.

🧠 Self-learning: el agente no se reprograma solo, y eso es importante

El nombre Self-learning for Copilot Studio Agents puede sonar bastante más inquietante de lo que realmente ha anunciado Microsoft. No significa que el agente vaya a modificar silenciosamente su configuración por su cuenta.

Lo que Microsoft está planteando es que Copilot Studio pueda analizar ejecuciones ya completadas y detectar patrones que podrían mejorarse. Por ejemplo, si el agente ejecuta una misma secuencia de herramientas repetidamente, podría sugerir al maker convertir esa secuencia en un workflow. ¿Para qué?

• Para conseguir más consistencia.
• Reducir errores.
• Y controlar costes.

Lo importante es lo que ocurre después, el maker sigue siendo quien decide si acepta la recomendación, la configura, la prueba y finalmente publica la versión refinada.

El sistema aprende de las ejecuciones.
Pero el maker sigue decidiendo qué cambia.

💸 Y entonces aparece una variable que ya no podemos ignorar: cuánto cuesta trabajar

Todo lo anterior tiene un precio. Los agentes powered by GitHub Copilot harness utilizan facturación basada en consumo mediante Copilot Credits, y aquí hay un matiz importante: la construcción, las pruebas, las evaluaciones y la ejecución pueden consumir créditos. Esto hace que el coste deje de ser únicamente una cuestión que aparece al final del proyecto. Puede convertirse también en una señal de diseño.

Si un agente necesita diez llamadas para resolver algo que podría encapsularse en un workflow, quizá no estemos únicamente ante una cuestión de precio, quizá tengamos una oportunidad para diseñarlo mejor.

De repente aparecen juntas varias conversaciones que antes podíamos tratar por separado: calidad, arquitectura, consumo y gobierno.

🔮 Lo siguiente que viene también dice mucho sobre hacia dónde va Copilot Studio

A fecha de octubre de 2026, Microsoft tiene varias capacidades en desarrollo o despliegue que refuerzan esta dirección.

Hay varias novedades del roadmap que, vistas por separado, pueden parecer pequeñas. Juntas cuentan una historia bastante distinta.

Self-learning permitirá analizar ejecuciones y proponer mejoras al maker.

El Skills Catalog permitirá compartir formas de trabajar aprobadas en toda la organización.

MCP Apps llevará interfaces interactivas al interior de la conversación.

La aprobación humana de Tools introducirá barreras deterministas antes de acciones sensibles.

Y Microsoft está trabajando también en Persistent Identity for Copilot Studio Agents, para que un agente pueda disponer de una identidad Microsoft 365 propia y gobernada. Esta última me parece especialmente simbólica, porque hemos pasado de imaginar un bot que contesta preguntas a imaginar algo que:

• Tiene capacidades
• Dispone de procedimientos
• Recuerda contexto
• Trabaja con otros agentes
• Puede solicitar nuestra aprobación
• Puede detectar patrones a partir de sus ejecuciones
• Empieza incluso a disponer de identidad propia dentro de la organización.

No creo que necesitemos ser desarrolladores para entender que la conversación está cambiando bastante.

💡 Entonces, ¿cuándo podemos decir que un agente “trabaja”?

Después de escribir las dos partes de esta serie, creo que mi respuesta sería bastante sencilla.

No trabaja porque utilice un modelo más potente.

Tampoco porque tenga muchas Tools.

Ni porque hayamos activado Memory.

Un agente empieza realmente a trabajar cuando puede convertir un objetivo en acciones y resultados, utilizando las capacidades que nosotros hemos puesto a su disposición y respetando los límites que hemos definido.

Y nuestro papel tampoco desaparece: cambia. Tenemos que decidir:

• Qué sabe.
• Qué puede utilizar.
• Qué merece convertirse en un workflow.
• Qué queremos reutilizar como Skill.
• Cuándo puede delegar.
• Qué puede recordar.
• Dónde necesita aprobación humana.
• Cómo vamos a evaluarlo.
• Y cuánto estamos dispuestos a pagar por ese trabajo.

Un chatbot responde.

Un agente razona, actúa, delega, recuerda y produce resultados.

Y nosotros seguimos siendo responsables de diseñar el sistema que le permite hacerlo.

Quizá esa sea la idea con la que me quedo después de estas dos partes. Más autonomía no significa menos responsabilidad para nosotros. Significa que nuestra responsabilidad se mueve.

De controlar cada paso… a diseñar las condiciones en las que el agente puede tomar buenas decisiones sin perder intención, seguridad ni control.

Y viendo las últimas novedades que Microsoft está poniendo sobre la mesa, tengo la sensación de que esto no ha hecho más que empezar.

📚 Fuentes oficiales

Las afirmaciones técnicas y novedades citadas en este artículo se apoyan en documentación oficial de Microsoft Learn y AI at Work Roadmap.

• GitHub Copilot harness overview | Microsoft Learn
• Harnesses in Copilot Studio | Microsoft Learn
• Tools overview for agents | Microsoft Learn
• Available tools for agents | Microsoft Learn
• Skills overview for agents | Microsoft Learn
• Memory in Copilot Studio | Microsoft Learn
• Attach files to a conversation | Microsoft Learn
• Manage costs for GitHub Copilot harness agents | Microsoft Learn
• AI at Work Roadmap | Microsoft Copilot Studio
• Compare Copilot Studio agent harnesses | Microsoft Learn