GitHub Copilot llega a Copilot Studio
Copilot Studio cambia de motor: así funciona el nuevo GitHub Copilot harness y su modelo de pago por consumo.
Microsoft ha presentado ayer (3 de agosto de 2026) una de las transformaciones más importantes de Copilot Studio desde el nacimiento de la plataforma.
No estamos ante un simple cambio de interfaz, un nuevo diseñador o una actualización incremental. El cambio afecta a la arquitectura que impulsa los agentes y, por tanto, a lo que podemos construir con ellos.
Después de varios meses en versión preliminar, Microsoft ha anunciado la disponibilidad general del GitHub Copilot harness en Copilot Studio.
Este nuevo motor permite crear agentes mucho más capaces, adaptativos y autónomos, preparados para ejecutar procesos empresariales complejos, utilizar múltiples herramientas, analizar archivos, tomar decisiones y trabajar durante periodos prolongados.
Pero el anuncio también incluye una segunda transformación que no debemos ignorar:
los agentes que utilizan el GitHub Copilot harness se facturan por consumo, incluso cuando sus usuarios disponen de licencias de Microsoft 365 Copilot.
Así que sí, podríamos resumir el anuncio parafraseando una conocida frase cinematográfica (símil de Jukka Niiranen – Power Platform Advisor – en LinkedIn):
“Estoy simplificando el modelo de licenciamiento agéntico. Reza para que no lo simplifique más.1» 😅
Darth Vader en El Imperio contraataca
La broma refleja bastante bien la situación.
Copilot Studio se vuelve mucho más potente. También más complejo de gobernar, evaluar y presupuestar.
¿Qué es exactamente un harness?
Para comprender la importancia del anuncio, debemos distinguir dos componentes fundamentales de un agente de inteligencia artificial.
El modelo es el cerebro
El modelo de lenguaje, o LLM, es la parte que comprende las instrucciones, interpreta el lenguaje natural, razona sobre un problema y genera resultados.
GPT y Claude son ejemplos de familias de modelos que pueden desempeñar esta función.
El modelo determina gran parte de la capacidad intelectual del agente, pero no es suficiente para ejecutar un proceso empresarial.
Un modelo aislado puede responder preguntas o generar contenido, pero necesita otros componentes para consultar sistemas, utilizar herramientas, analizar documentos, ejecutar acciones y operar dentro de los límites de una organización.
El harness permite que el cerebro trabaje
El harness es todo lo que rodea al modelo y le permite realizar trabajo útil.
Incluye componentes como:
- Herramientas.
- Skills.
- Flujos de trabajo.
- Instrucciones.
- Contexto.
- Memoria.
- Fuentes de conocimiento.
- Acceso a aplicaciones empresariales.
- Conexiones con otros agentes.
- Identidad y permisos.
- Seguridad.
- Gobierno.
- Evaluaciones.
- Observabilidad.
- Control de la ejecución.
Podríamos decir que el modelo es el cerebro, mientras que el harness proporciona las manos, los ojos, las herramientas, las reglas y el entorno de trabajo.
Un modelo puede ser excelente razonando, pero necesita un buen harness para convertir ese razonamiento en acciones útiles, seguras y controladas.
Y ahí está la verdadera importancia de este anuncio.
Del chatbot al agente empresarial
Hasta ahora, la mayoría de los agentes creados en Copilot Studio utilizaban lo que Microsoft denomina actualmente Standard harness.
Esta arquitectura procede, en buena medida, de la etapa de Power Virtual Agents y del mundo de los chatbots.
Su funcionamiento está estrechamente vinculado a conceptos como:
- Topics.
- Frases de activación.
- Diálogos estructurados.
- Condiciones.
- Reglas.
- Flujos conversacionales.
- Acciones previamente definidas.
Este modelo sigue siendo perfectamente válido para muchos escenarios.
Es una buena opción cuando necesitamos conversaciones controladas, procesos predecibles, reglas de negocio conocidas o recorridos claramente definidos.
Sin embargo, resulta más limitado cuando el agente debe recibir un objetivo abierto, diseñar un plan, seleccionar herramientas, tomar decisiones durante la ejecución y adaptar su comportamiento a los resultados que va obteniendo.
La gran novedad es que Copilot Studio puede construir ahora agentes utilizando el GitHub Copilot harness, la tecnología que se encuentra detrás de algunas de las experiencias agénticas más avanzadas de Microsoft.
Esto permite trasladar a Copilot Studio capacidades de programación, planificación, razonamiento y ejecución que anteriormente quedaban fuera del alcance habitual de los makers low-code.
Agentes preparados para procesos complejos y prolongados
El GitHub Copilot harness ha sido diseñado para abordar trabajos complejos y de largo horizonte.
En lugar de limitarse a responder una pregunta o ejecutar una acción predefinida, el agente puede recibir un objetivo, analizarlo, elaborar un plan y completar una secuencia de acciones.
Entre sus capacidades encontramos:
- Planificar tareas de múltiples pasos.
- Razonar sobre problemas dinámicos.
- Resolver puntos de decisión ambiguos.
- Utilizar varias herramientas de manera coordinada.
- Analizar archivos y documentos.
- Trabajar con código.
- Utilizar skills especializadas.
- Integrar workflows.
- Conectarse con agentes y herramientas externas.
- Adaptar su estrategia según los resultados.
- Generar entregables compuestos por varias partes.
- Mantener procesos activos durante más tiempo.
Esto acerca Copilot Studio a un escenario en el que los agentes no solo conversan con el usuario, sino que asumen la ejecución de procesos empresariales completos.
Por ejemplo, un agente podría recibir una solicitud, recopilar información de varios sistemas, analizar documentos, detectar datos ausentes, aplicar criterios empresariales, generar un informe e iniciar posteriormente un proceso de aprobación.
El bucle agéntico: observar, decidir y volver a actuar
Una de las diferencias fundamentales entre una automatización tradicional y un agente moderno es el llamado bucle agéntico.
En una automatización determinista, cada paso está definido previamente.
El proceso sigue normalmente una estructura similar a esta:
- Ocurre un evento.
- Se evalúa una condición.
- Se ejecuta una acción.
- Se continúa por una rama conocida.
- El proceso finaliza.
Un agente basado en el GitHub Copilot harness puede trabajar de otra manera:
- Comprende el objetivo.
- Diseña un plan.
- Selecciona una herramienta o skill.
- Ejecuta una acción.
- Analiza el resultado.
- Evalúa si ha completado la tarea.
- Corrige o amplía su estrategia.
- Ejecuta una nueva acción.
- Repite el ciclo hasta alcanzar el objetivo o un límite.
El agente no sigue necesariamente un recorrido fijo.
Puede cambiar de estrategia, utilizar herramientas diferentes o repetir determinados pasos cuando considera que el resultado todavía no es suficiente.
Esta capacidad es precisamente lo que lo hace más potente.
También es lo que vuelve su comportamiento, duración y coste mucho menos predecibles.
Topics pierden protagonismo y las Skills pasan al centro
Uno de los cambios más visibles de la nueva experiencia de creación es que los Topics dejan de ser el elemento central.
En su lugar, las Skills se convierten en una de las principales piezas de construcción.
Una Skill representa una capacidad concreta que el agente puede utilizar para completar una tarea.
Por ejemplo:
- Consultar información de un cliente.
- Analizar un contrato.
- Revisar una factura.
- Generar una propuesta comercial.
- Comparar documentos.
- Consultar inventario.
- Crear una incidencia.
- Preparar un informe.
- Revisar código.
- Iniciar una aprobación.
- Actualizar información en Dynamics 365.
La diferencia conceptual es importante.
Con los Topics diseñamos recorridos conversacionales y comportamientos relativamente definidos.
Con las Skills proporcionamos capacidades al agente y permitimos que determine cuáles debe utilizar, en qué orden y con qué información.
Esto no significa que todos los procesos deban ser autónomos.
Significa que Copilot Studio ofrece ahora una arquitectura diferente para aquellos escenarios en los que necesitamos flexibilidad, planificación y razonamiento.
Agent o Workflow: dos enfoques complementarios
La nueva experiencia diferencia también con mayor claridad dos tipos de solución: Agents y Workflows.
Agent: adaptativo y dirigido por inteligencia artificial
Un Agent es adecuado cuando el proceso requiere:
- Interpretación.
- Razonamiento.
- Adaptación.
- Decisiones no completamente predefinidas.
- Selección dinámica de herramientas.
- Gestión de información ambigua.
- Planificación de varios pasos.
- Generación de resultados complejos.
En este modelo definimos principalmente el objetivo, las instrucciones, los límites y las capacidades disponibles.
El agente decide cómo avanzar hacia el resultado.
Workflow: determinista y dirigido por el proceso
Un Workflow es más apropiado cuando:
- La secuencia está claramente definida.
- Las reglas son conocidas.
- El proceso debe ser repetible.
- El comportamiento debe ser predecible.
- Existen controles estrictos.
- No queremos que el sistema decida libremente el siguiente paso.
En este caso definimos el recorrido que debe seguir la ejecución.
La diferencia podría resumirse así:
En un Agent definimos el objetivo y las capacidades. En un Workflow definimos el camino.
En muchos escenarios empresariales, ambos enfoques convivirán.
Un agente podrá interpretar una solicitud, investigar, recopilar datos y decidir qué debe ocurrir. Después, podrá iniciar un workflow determinista para ejecutar una operación sensible de manera controlada.
El futuro no consiste en sustituir todos los flujos por agentes.
Consiste en combinar razonamiento y determinismo en el lugar adecuado.
Un nuevo diseñador para los makers
La llegada del GitHub Copilot harness viene acompañada de una nueva experiencia de creación.
El diseñador de agentes coloca las herramientas principales directamente al alcance del maker y busca simplificar la construcción de agentes avanzados.
Desde este entorno se pueden configurar elementos como:
- Instrucciones.
- Skills.
- Herramientas.
- Fuentes de conocimiento.
- Contexto organizativo.
- Conexiones.
- Pruebas.
- Evaluaciones.
- Gestión del ciclo de vida.
Copilot Studio incorpora también un diseñador visual de workflows.
Este lienzo permite comprender y editar el proceso gráficamente, añadir nodos de agentes, combinar acciones deterministas y ejecutar evaluaciones sobre el comportamiento de la solución.
Microsoft también está preparando experiencias de creación mediante lenguaje natural.
La idea es que un usuario pueda describir su objetivo empresarial mediante una conversación y que Copilot Studio ayude a ensamblar la combinación adecuada de agentes, skills, herramientas y workflows.
Por ejemplo, un usuario podría indicar:
Necesito un sistema que revise las solicitudes de alta de proveedores, compruebe la documentación, identifique la información que falta, consulte el riesgo financiero y envíe los casos válidos a aprobación.
A partir de esta necesidad, Copilot Studio podría ayudar a definir:
- El agente responsable de interpretar las solicitudes.
- Los documentos que deben analizarse.
- Las skills necesarias.
- Los sistemas que deben consultarse.
- Los pasos que pueden automatizarse.
- El workflow de aprobación.
- Los puntos donde debe intervenir una persona.
Esto reduce considerablemente la distancia entre una necesidad empresarial y la arquitectura técnica necesaria para resolverla.
Mejoras en rendimiento y calidad
Según las evaluaciones compartidas por Microsoft utilizando procesos empresariales reales, Copilot Studio obtiene mejoras importantes cuando utiliza el GitHub Copilot harness.
Las mejoras principales se concentran en cuatro áreas.
Uso de múltiples herramientas
Los agentes pueden seleccionar, combinar y coordinar mejor distintas herramientas durante la ejecución de una tarea.
Esto es fundamental para procesos que atraviesan varias aplicaciones, fuentes de conocimiento o sistemas empresariales.
Análisis de archivos
La nueva arquitectura mejora la capacidad de interpretar, relacionar y extraer información de distintos documentos.
Un agente podría analizar una solicitud, consultar documentación complementaria, detectar contradicciones y preparar una conclusión.
Análisis de código
Los agentes pueden comprender y trabajar con código con mayor precisión.
Esto resulta útil no solo en desarrollo de software, sino también en integraciones, automatizaciones, revisión técnica y mantenimiento de soluciones.
Calidad del conocimiento
También mejora el uso del contexto organizativo y de las fuentes de conocimiento.
Esto permite generar respuestas, decisiones y entregables mejor fundamentados.
Un ejemplo: preparar una propuesta comercial
Pensemos en un proceso habitual dentro de una organización: preparar una propuesta para un cliente.
Un asistente conversacional tradicional podría recopilar información mediante preguntas y activar posteriormente un flujo.
Un agente basado en el GitHub Copilot harness podría recibir un objetivo más amplio:
Prepara una propuesta para este cliente teniendo en cuenta su historial, los productos que utiliza, las últimas reuniones, las oportunidades abiertas y nuestras condiciones comerciales.
El agente podría:
- Consultar la información del cliente en Dynamics 365.
- Revisar notas de reuniones.
- Analizar oportunidades anteriores.
- Consultar productos y precios.
- Identificar necesidades.
- Detectar riesgos.
- Definir una estrategia.
- Generar la propuesta.
- Crear un resumen ejecutivo.
- Redactar el correo de presentación.
- Iniciar un workflow de revisión.
- Incorporar los comentarios recibidos.
Aquí no existe un único recorrido conversacional.
El agente debe seleccionar herramientas, resolver contradicciones, evaluar la información disponible y producir varios entregables relacionados.
Este es el tipo de escenario para el que se ha diseñado el nuevo harness.
Tres harnesses para tres tipos de escenario
La incorporación del GitHub Copilot harness no elimina las arquitecturas anteriores.
Microsoft reconoce que no existe un único motor adecuado para todos los tipos de agente.
Copilot Studio admite actualmente tres grandes opciones.
Copilot Chat harness
Utiliza el mismo harness que Microsoft 365 Copilot Chat.
Está orientado a personalizar y ampliar las experiencias de Copilot Chat dentro del ecosistema de Microsoft 365.
Resulta adecuado cuando queremos proporcionar conocimientos, instrucciones o capacidades concretas dentro de la experiencia habitual de Copilot.
Standard harness
Es la arquitectura utilizada por la mayoría de los agentes tradicionales creados en Copilot Studio.
Continúa siendo una buena elección para:
- Agentes conversacionales.
- Procesos predecibles.
- Topics y reglas.
- Flujos de diálogo controlados.
- Automatizaciones estructuradas.
- Escenarios con costes más previsibles.
GitHub Copilot harness
Es el nuevo motor orientado a procesos empresariales agénticos y complejos.
Resulta adecuado cuando el agente necesita:
- Planificar.
- Razonar.
- Adaptarse.
- Utilizar múltiples herramientas.
- Analizar archivos.
- Trabajar durante más tiempo.
- Generar varios resultados.
- Coordinar agentes y workflows.
- Resolver situaciones ambiguas.
La decisión no consiste en determinar qué harness es mejor de forma absoluta.
La pregunta correcta es cuál se adapta mejor a cada proceso.
De Samba y Sydney a la nueva arquitectura
Dentro de la comunidad se han utilizado durante algún tiempo los nombres Samba y Sydney para describir diferentes orquestadores de Copilot.
No son las denominaciones comerciales actuales, pero ayudan a comprender la evolución de la plataforma.
Samba
Samba se ha asociado tradicionalmente al orquestador heredado de la etapa de Power Virtual Agents.
Su arquitectura se encuentra muy vinculada a Topics, reglas, activadores y recorridos conversacionales.
Microsoft denomina ahora a esta arquitectura Standard harness.
Sydney
Sydney se ha utilizado como nombre para el orquestador relacionado con experiencias más modernas de Copilot Chat.
Actualmente, Microsoft lo presenta como Copilot Chat harness.
GitHub Copilot harness
La tercera opción es el nuevo GitHub Copilot harness.
No existe un nombre en clave público equivalente a Samba o Sydney.
En algunos artefactos técnicos puede encontrarse la denominación cliagent, pero no debe confundirse con el nombre oficial del producto.
Más allá de los nombres internos, lo relevante es que Copilot Studio ofrece ahora tres arquitecturas con capacidades, comportamientos y modelos económicos diferentes.
Los agentes existentes continuarán funcionando
Microsoft ha confirmado que los agentes actuales no desaparecerán.
Los agentes basados en Copilot Chat harness o Standard harness continuarán funcionando y será posible seguir creando nuevas soluciones con estas arquitecturas.
No existe, por tanto, una obligación inmediata de migrar.
Esto es importante porque muchos escenarios no necesitan un agente autónomo.
Introducir razonamiento avanzado en un proceso sencillo puede aumentar innecesariamente:
- El coste.
- La variabilidad.
- El tiempo de respuesta.
- La complejidad.
- La dificultad de evaluación.
- El riesgo operativo.
El Standard harness continuará siendo adecuado para multitud de soluciones.
Sin embargo, cuando hablamos de verdaderos workflows agénticos y de transformación de procesos empresariales, la dirección estratégica de Microsoft parece orientarse claramente hacia esta nueva generación de agentes.
La otra gran noticia: facturación basada en consumo
Hasta ahora hemos hablado principalmente de capacidades.
Pero el anuncio incluye otra transformación igual de relevante para las organizaciones.
Los agentes que se ejecutan mediante el GitHub Copilot harness utilizan facturación basada en consumo para todo el trabajo realizado.
Esto se aplica aunque los usuarios dispongan de licencias de Microsoft 365 Copilot.
El coste puede depender de factores como:
- Los modelos seleccionados.
- El volumen de información procesada.
- El contexto organizativo utilizado.
- Las herramientas invocadas.
- El número de acciones realizadas.
- La duración de la ejecución.
- El número de iteraciones.
- La complejidad de los entregables.
Determinadas experiencias de creación asistidas por inteligencia artificial también pueden generar consumo.
Entre ellas pueden encontrarse:
- Creación mediante lenguaje natural.
- Pruebas.
- Evaluaciones.
- Otras experiencias de asistencia al maker.
Esto significa que el coste no aparece únicamente cuando el usuario final utiliza el agente.
También puede existir durante el ciclo de construcción, experimentación y validación.
Microsoft 365 Copilot no incluye el nuevo harness
Uno de los argumentos de valor de la licencia por usuario de Microsoft 365 Copilot era la posibilidad de utilizar internamente determinados agentes de Copilot Studio dentro de las condiciones de uso razonable incluidas.
Esta ventaja continúa siendo aplicable a los agentes que utilizan:
- Copilot Chat harness.
- Standard harness.
Pero no se extiende al GitHub Copilot harness.
Los agentes creados con la nueva arquitectura utilizan un modelo de pago por consumo.
En otras palabras, disponer de licencias premium de Microsoft 365 Copilot no proporciona uso ilimitado ni una bolsa gratuita para los agentes modernos.
Cada ejecución puede generar consumo de Copilot Credits.
No basta con activar la nueva experiencia
Desde la perspectiva del maker, podría parecer que el cambio consiste únicamente en entrar en Copilot Studio, activar la nueva experiencia y comenzar a construir agentes más avanzados.
Comercialmente, la situación es diferente.
La organización debe disponer de la configuración de facturación correspondiente.
Dependiendo del contrato y del entorno, esto puede implicar:
- Pago por uso.
- Capacidad precomprada.
- Vinculación con una suscripción de Azure.
- Asignación de Copilot Credits.
- Mecanismos empresariales de control presupuestario.
Por tanto, la adopción del GitHub Copilot harness no es solamente una decisión técnica.
También es una decisión:
- Financiera.
- Arquitectónica.
- Operativa.
- De gobierno.
- De gestión del riesgo.
El maker puede ver una nueva capacidad en el portal, pero la organización debe decidir quién puede utilizarla, con qué presupuesto, en qué entornos y bajo qué condiciones.
Por qué un agente moderno es difícil de incluir en una tarifa plana
El cambio de facturación está directamente relacionado con la forma en la que trabaja el nuevo harness.
En el Standard harness, buena parte de la ejecución está predeterminada.
El creador define Topics, condiciones, acciones y recorridos.
Aunque la inteligencia artificial generativa introduce cierta variabilidad, el proceso sigue siendo relativamente rígido.
Esto permite estimar mejor:
- Cuántas acciones se ejecutarán.
- Qué herramientas se utilizarán.
- Cuántos pasos tendrá el proceso.
- Cuánto durará.
- Qué volumen de recursos consumirá.
El comportamiento no es siempre completamente determinista, pero su coste resulta comparativamente más predecible.
El GitHub Copilot harness funciona de forma diferente.
El agente puede razonar sobre las instrucciones, seleccionar skills, ejecutar herramientas, revisar sus resultados y volver a intentarlo cuando considera que la tarea no está completa.
Esta flexibilidad provoca que no siempre podamos anticipar:
- Cuántas veces llamará al modelo.
- Cuántos tokens procesará.
- Cuántas herramientas utilizará.
- Cuántos archivos analizará.
- Cuántas veces corregirá su plan.
- Cuánto tiempo permanecerá activo.
- Cuántos resultados generará.
- Cuándo dará por completado el trabajo.
Ni siquiera el proveedor puede garantizar un consumo idéntico para todas las ejecuciones, porque el comportamiento depende del contexto y de las decisiones tomadas por el agente.
Por eso resulta difícil incluir estas capacidades de manera ilimitada dentro de una tarifa plana mensual por usuario.
La solución de Microsoft es trasladar ese consumo a un medidor basado en Copilot Credits.
Desde el punto de vista económico, tiene lógica.
Desde el punto de vista del cliente, introduce una nueva preocupación:
el coste deja de depender únicamente del número de usuarios y empieza a depender también del comportamiento de los agentes.
El precedente de Copilot Cowork
Este modelo resultará familiar para quienes hayan seguido la evolución de Copilot Cowork.
Durante la fase preliminar, gran parte de la conversación se centró en sus capacidades: ejecución autónoma, investigación, procesos prolongados y creación de entregables complejos.
Con la disponibilidad general apareció también la realidad del pago por uso.
El GitHub Copilot harness sigue una lógica similar dentro de Copilot Studio.
Tiene sentido porque ambas experiencias comparten principios arquitectónicos:
- Planificación.
- Razonamiento prolongado.
- Uso dinámico de herramientas.
- Evaluación de resultados.
- Reintentos.
- Ejecución de procesos no totalmente predecibles.
- Generación de múltiples entregables.
La capacidad es superior a la de un asistente conversacional tradicional.
El consumo también puede serlo.
Agents y Workflows pueden consumir créditos
Copilot Studio ya había introducido el consumo de Copilot Credits en determinados workflows y capacidades de automatización.
Con el nuevo modelo, los agentes también pueden convertirse en consumidores intensivos.
Una solución moderna podría incluir:
- Un agente que interpreta la solicitud.
- Varias llamadas a modelos.
- Skills que consultan distintos sistemas.
- Análisis de documentos.
- Un workflow que ejecuta acciones.
- Evaluaciones que verifican el resultado.
- Reintentos.
- Generación de varios entregables.
Cada una de estas capas puede contribuir al consumo total.
Esto no significa que los workflows deterministas o las licencias tradicionales hayan desaparecido.
Todo lo contrario.
Power Automate y los procesos deterministas continúan siendo fundamentales y, en muchos casos, más adecuados y eficientes.
La clave será evitar utilizar un agente costoso para resolver una tarea que puede completarse con reglas conocidas y una automatización convencional.
No todo necesita un agente autónomo
En medio del entusiasmo, conviene recordar que no todos los procesos necesitan inteligencia artificial agéntica.
Una automatización determinista continúa siendo mejor cuando:
- Las reglas están perfectamente definidas.
- El proceso es estable.
- La secuencia siempre es la misma.
- No existe ambigüedad.
- La trazabilidad debe ser estricta.
- El coste debe ser predecible.
- No es necesario interpretar información compleja.
La arquitectura adecuada puede combinar:
- Un agente para interpretar.
- Un workflow para ejecutar.
- Reglas para controlar.
- Una persona para aprobar.
- Evaluaciones para verificar.
El objetivo no debe ser introducir inteligencia artificial en todos los pasos.
Debe utilizarse allí donde aporte una ventaja real.
La arquitectura debe optimizar también el consumo
Hasta ahora, muchas decisiones de arquitectura se centraban en funcionalidad, seguridad y experiencia de usuario.
Con los agentes modernos aparece una cuarta dimensión:
la economía de la ejecución.
No basta con preguntarnos si el agente puede completar una tarea.
También debemos analizar:
- Cuánto cuesta cada ejecución.
- Qué modelo necesita realmente.
- Qué pasos requieren razonamiento avanzado.
- Qué contexto se está enviando.
- Cuántos archivos se analizan.
- Cuántas iteraciones permitimos.
- Cuándo debe detenerse.
- Qué tareas pueden trasladarse a un workflow.
- Qué resultados pueden reutilizarse.
- Qué valor empresarial produce la ejecución.
Un buen agente no será únicamente el que resuelva el proceso.
Será el que lo haga con una relación razonable entre:
- Calidad.
- Tiempo.
- Seguridad.
- Riesgo.
- Consumo.
- Valor empresarial.
El agente que no sabe detenerse
Uno de los principales riesgos de los sistemas agénticos es la ejecución innecesariamente prolongada.
Un agente puede:
- Repetir una búsqueda.
- Volver a consultar la misma fuente.
- Intentar mejorar un resultado suficientemente bueno.
- Utilizar una herramienta que no aporta valor.
- Generar variantes innecesarias.
- Entrar en un ciclo de validación.
- Continuar razonando después de alcanzar el objetivo.
En un modelo de tarifa plana, esto representa principalmente un problema de rendimiento.
En un modelo de pago por consumo, también se convierte en un problema económico.
Por tanto, será fundamental configurar:
- Límites de iteraciones.
- Tiempos máximos.
- Presupuestos.
- Condiciones de finalización.
- Reglas de escalado.
- Intervención humana.
- Alertas.
- Supervisión.
- Evaluaciones de eficiencia.
La definición de “tarea completada” pasa a ser una pieza crítica del diseño.
FinOps para inteligencia artificial
El gobierno de Copilot Studio ya no puede limitarse a controlar quién crea agentes o qué conectores están permitidos.
Las organizaciones necesitarán incorporar prácticas similares a FinOps para inteligencia artificial.
Esto implica:
- Asignar presupuestos por entorno.
- Medir el consumo por agente.
- Identificar los casos de uso más costosos.
- Detectar anomalías.
- Establecer límites.
- Revisar los modelos utilizados.
- Analizar el coste por transacción.
- Relacionar consumo y resultados.
- Comparar el agente con alternativas tradicionales.
- Retirar soluciones cuyo coste supere su valor.
También será necesario diferenciar entre:
- Coste de construcción.
- Coste de pruebas.
- Coste de evaluaciones.
- Coste de ejecución.
- Coste de supervisión.
- Coste de mantenimiento.
- Coste de los errores.
La gestión financiera ya no será una conversación posterior al despliegue.
Tendrá que formar parte del diseño desde el principio.
¿Significa esto que el nuevo harness será demasiado caro?
No necesariamente.
Un agente puede tener un coste de ejecución superior al de un chatbot tradicional y seguir ofreciendo un retorno excelente.
Pagar varios euros por una ejecución puede ser perfectamente razonable si el agente:
- Ahorra varias horas de trabajo.
- Reduce errores.
- Acelera una propuesta comercial.
- Evita una pérdida económica.
- Detecta un riesgo contractual.
- Automatiza un proceso complejo.
- Mejora el servicio al cliente.
- Permite gestionar un volumen imposible manualmente.
El problema no es pagar por consumo.
El problema aparece cuando:
- No conocemos el consumo.
- No podemos explicarlo.
- No hemos establecido límites.
- No medimos los resultados.
- Automatizamos tareas de poco valor.
- Utilizamos modelos excesivamente potentes.
- Permitimos ejecuciones innecesarias.
- Desplegamos agentes sin observabilidad.
La pregunta correcta no es simplemente cuánto cuesta un agente.
La pregunta es:
¿Cuánto valor genera por cada unidad de consumo?
La factura también forma parte de la estrategia
También debemos comprender el contexto empresarial de los grandes proveedores de nube.
Las compañías tecnológicas están invirtiendo enormes cantidades en centros de datos, aceleradores, redes e infraestructura de inteligencia artificial.
Necesitan transformar esa inversión en consumo recurrente.
Los agentes son especialmente atractivos desde el punto de vista económico porque no se limitan a generar una respuesta breve.
Pueden:
- Permanecer activos durante más tiempo.
- Realizar varias llamadas a modelos.
- Analizar grandes volúmenes de información.
- Utilizar herramientas.
- Ejecutar workflows.
- Generar varios entregables.
- Repetir tareas hasta alcanzar un resultado.
Desde la perspectiva del proveedor, esto representa:
- Más uso de modelos.
- Más consumo de infraestructura.
- Más integración con la nube.
- Más dependencia de la plataforma.
- Más ingresos variables.
- Mayor expansión dentro de cada cliente.
El GitHub Copilot harness no es únicamente una evolución técnica.
También es una pieza importante del futuro modelo comercial de Microsoft AI.
La plataforma ofrece más capacidad a los clientes y, al mismo tiempo, abre una vía para aumentar el consumo más allá de la licencia mensual por usuario.
Una decisión de negocio, no solo tecnológica
La llegada del GitHub Copilot harness cambia la forma en la que debemos evaluar los proyectos de Copilot Studio.
Antes podíamos comenzar con preguntas como:
- ¿Podemos construirlo?
- ¿Qué conectores necesitamos?
- ¿Qué Topic debemos crear?
- ¿Qué licencia necesita el usuario?
Ahora debemos añadir:
- ¿Qué harness debemos utilizar?
- ¿Necesitamos un agente adaptativo?
- ¿Qué parte debería ser determinista?
- ¿Cuántas iteraciones puede ejecutar?
- ¿Qué consumo esperamos?
- ¿Cuál es el presupuesto?
- ¿Cuál es el coste máximo por transacción?
- ¿Cómo mediremos el retorno?
- ¿Qué ocurrirá si el consumo aumenta?
- ¿Quién será responsable de supervisarlo?
El nuevo Copilot Studio pone una enorme potencia en manos de makers y organizaciones.
Pero esa potencia no es gratuita, ni técnica ni económicamente.
¿Qué significa para los makers low-code?
Una de las consecuencias más interesantes del anuncio es que capacidades anteriormente asociadas al desarrollo avanzado llegan ahora a una plataforma low-code.
Los makers podrán construir agentes capaces de:
- Planificar.
- Utilizar herramientas.
- Analizar documentos.
- Trabajar con código.
- Coordinar procesos.
- Generar entregables complejos.
- Adaptar su estrategia.
- Colaborar con workflows.
Esto reduce el umbral de entrada, pero no elimina la necesidad de conocimientos.
Seguiremos necesitando comprender:
- La arquitectura.
- Los datos.
- Los sistemas empresariales.
- La seguridad.
- Los permisos.
- Las limitaciones de los modelos.
- El diseño de evaluaciones.
- Los costes.
- El gobierno.
Las mejores soluciones surgirán probablemente de equipos mixtos formados por:
- Expertos de negocio.
- Makers.
- Desarrolladores.
- Arquitectos.
- Especialistas en seguridad.
- Responsables financieros.
- Expertos en inteligencia artificial.
La plataforma será low-code.
La transformación empresarial seguirá requiriendo criterio.
Nuevos escenarios para transformar procesos
Las posibilidades son enormes.
Podemos imaginar agentes capaces de:
- Investigar oportunidades comerciales.
- Preparar propuestas personalizadas.
- Revisar contratos.
- Clasificar documentación.
- Analizar incidencias.
- Coordinar procesos de onboarding.
- Evaluar solicitudes.
- Preparar informes financieros.
- Detectar riesgos.
- Investigar problemas técnicos.
- Generar documentación.
- Coordinar tareas entre diferentes sistemas.
- Supervisar operaciones.
- Preparar decisiones para revisión humana.
- Gestionar excepciones administrativas.
Los mejores candidatos serán aquellos procesos que combinen tres características:
- Requieren interpretar información.
- Incluyen decisiones que no pueden expresarse completamente mediante reglas.
- Necesitan interactuar con varias herramientas o sistemas.
Estos escenarios pueden justificar una arquitectura agéntica.
Los procesos simples, estables y predecibles probablemente seguirán resolviéndose mejor mediante automatizaciones tradicionales.
Una evolución apasionante, con una factura diferente
La incorporación del GitHub Copilot harness representa una de las evoluciones más importantes de Copilot Studio.
La plataforma puede crear agentes más capaces, adaptativos y autónomos.
Agentes que comprenden objetivos, elaboran planes, seleccionan skills, utilizan herramientas, revisan resultados y continúan trabajando hasta completar procesos empresariales complejos.
También cambia la forma de construir soluciones:
- Los Topics dejan de ser el centro de la experiencia moderna.
- Las Skills se convierten en capacidades reutilizables.
- Los Agents resuelven situaciones adaptativas.
- Los Workflows ejecutan procesos deterministas.
- Las soluciones híbridas combinan razonamiento y control.
Pero existe una segunda transformación que no debemos ocultar detrás del entusiasmo tecnológico:
el futuro agéntico de Copilot Studio es un futuro basado en consumo.
Los agentes de Copilot Chat harness y Standard harness mantienen sus propios modelos de licenciamiento y determinadas condiciones de uso incluidas para usuarios de Microsoft 365 Copilot.
El GitHub Copilot harness no.
Cada ejecución consume recursos y puede generar Copilot Credits porque cada agente puede razonar, actuar, revisar y repetir de formas difíciles de predecir.
Esto no convierte el anuncio en una mala noticia.
Lo convierte en una noticia que debemos analizar completa.
La nueva plataforma ofrece más capacidad que nunca, pero exige mejores prácticas de arquitectura, gobierno, evaluación, observabilidad y control financiero.
Ya no será suficiente con crear agentes que funcionen.
Tendremos que crear agentes que:
- Resuelvan el problema adecuado.
- Utilicen el harness adecuado.
- Sepan cuándo detenerse.
- Consuman de manera eficiente.
- Operen dentro de límites seguros.
- Generen más valor del que cuestan.
El gran reto no será construir agentes impresionantes.
Será construir agentes sostenibles.
Información basada en la publicación More powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio y en la frase del licenciamiento de Jukka Niiranen (Power Platform Advisor y Ex-11x Microsoft MVP) en LinkedIn.
- La frase original procede de Darth Vader en Star Wars: Episodio V – El Imperio contraataca:
“Estoy alterando el trato. Reza para que no lo altere más.” (EN: “I am altering the deal. Pray I don’t alter it any further.”)
Darth Vader se la dirige a Lando Calrissian después de cambiar unilateralmente las condiciones de un acuerdo. Lando protesta, pero Vader deja claro que tiene todo el poder y que todavía puede imponer condiciones peores.
En relación a Copilot se quedaría así: “Estoy simplificando el modelo de licenciamiento agéntico. Reza para que no lo simplifique más.”
La broma funciona porque Microsoft presenta el cambio como una simplificación del modelo de agentes, pero cada nueva capa puede hacer que el licenciamiento resulte más difícil de entender o más costoso para el cliente. ↩︎
