Copilot Studio en 2026: aplicaciones, flujos y agentes

Redactado por Mario Larrúa Vega.

Una solicitud de formación puede empezar con una pregunta, continuar en un formulario, necesitar una aprobación y terminar con una notificación. Cada paso plantea una necesidad distinta: conversar, recopilar datos, aplicar reglas o ejecutar una acción.

Copilot Studio está evolucionando hacia una experiencia que reúne aplicaciones, automatización y agentes. En su anuncio del 7 de octubre de 2026, Microsoft presentó aplicaciones y Copilot Managed Runtime en vista previa pública, además de novedades de conocimiento, evaluación y control. Puedes consultar el anuncio oficial.

Este artículo explica cómo interpretar esos componentes y propone un caso de aprendizaje: gestionar solicitudes de formación de una academia. Separaremos las capacidades documentadas de las decisiones de diseño del ejemplo.

Las aplicaciones de Copilot Studio siguen en vista previa y su despliegue es gradual. Microsoft indica que las características en vista previa no están destinadas a producción y pueden tener restricciones. Comprueba la disponibilidad y las condiciones de tu entorno antes de probarlas.

Qué es Copilot Studio hoy

Microsoft lo describe como un estudio gráfico de bajo código para construir y gestionar agentes y automatizaciones, conectarlos con datos y sistemas y publicarlos en canales compatibles. Su documentación incorpora también la experiencia de creación de aplicaciones en vista previa. La referencia general es la introducción a Copilot Studio.

Para entenderlo, conviene empezar por la función de cada componente:

La distribución concreta es una propuesta de arquitectura. Primero define el proceso y después decide qué componente necesita cada parte.

Qué novedades merece la pena conocer

Aplicaciones creadas mediante conversación

La experiencia de aplicaciones permite describir un problema, responder preguntas y generar una primera versión interactiva. Después puedes refinarla mediante conversación y revisar su código. Para acceder, la documentación pide la nueva experiencia habilitada y la presencia de la opción de aplicaciones en vista previa; el administrador puede desactivarla.

Compartir la aplicación no concede automáticamente acceso a datos que el usuario no tenía. Consulta los requisitos, el despliegue gradual y el comportamiento de identidad en Apps overview.

Un entorno administrado para las aplicaciones

Copilot Managed Runtime, anunciado también en vista previa pública, proporciona infraestructura administrada por Microsoft para estas experiencias, con identidad, acceso gobernado a datos, ciclo de vida, versionado respaldado por Git y visibilidad administrativa. El alcance se describe en el anuncio de octubre.

Que la plataforma administre infraestructura no resuelve por sí solo la calidad de los datos, la definición del proceso ni las autorizaciones del negocio. Esas decisiones siguen necesitando responsables y comprobaciones.

Conocimiento reutilizable con Foundry IQ

Una conexión con Foundry IQ permite utilizar una base de conocimiento que agrupa fuentes y configuración de recuperación. La documentación actual exige acceso a la base y describe una conexión Foundry IQ por agente. Incluye varias opciones de autenticación, cuya elección debes revisar según el alcance requerido. Consulta cómo conectar Foundry IQ.

En nuestro ejemplo, podría servir para recuperar la política de formación que otro equipo ya mantiene. Antes de incorporarlo, verificaríamos fuentes, permisos, referencias devueltas y preguntas fuera de alcance.

Qué significa harness y por qué aparece en los tutoriales

La documentación actual distingue varios motores de ejecución, denominados harnesses. Influyen en capacidades, configuración y facturación.

El GitHub Copilot harness de Copilot Studio no equivale al servicio GitHub Copilot: la documentación distingue ambos y explica el tratamiento de datos. Consulta Harnesses in Copilot Studio.

Esto afecta a la práctica: un tutorial de agent flows de la experiencia estándar puede mostrar opciones diferentes a uno de workflows de la nueva experiencia. Antes de copiar pasos, comprueba a qué experiencia se refiere.

Caso práctico: solicitudes de formación

La academia quiere que sus empleados consulten cursos, presenten solicitudes y conozcan su estado. Algunas peticiones requieren aprobación de un responsable.

Para un primer prototipo proponemos tres límites:

1. Solo utilizar datos ficticios y cursos de ejemplo.
2. Mantener la aprobación como decisión humana.
3. Empezar sin pagos, cambios de permisos ni altas automáticas en sistemas externos.

El proceso sería:

Persona interesada
  ├── Consulta requisitos al agente
  └── Completa la solicitud en la aplicación
             │
             ▼
       Validación de datos
             │
             ▼
       Solicitud de aprobación
             │
      ┌──────┴──────┐
      ▼             ▼
   Aprobada      Rechazada
      └──────┬──────┘
             ▼
     Registro y notificación

No estamos afirmando que la plataforma genere este proceso completo con una única instrucción. Es el diseño que queremos construir y verificar progresivamente, según las funciones disponibles.

Paso 1. Define los datos y las reglas

Antes de abrir el diseñador, escribe un modelo mínimo:

Propón también las transiciones: borrador, presentada, pendiente de aprobación y resolución. Decide qué ocurre si el curso deja de estar disponible o si una misma petición llega dos veces.

Estas reglas son requisitos de la academia ficticia. Deben validarse en el sistema que ejecuta la operación, además de reflejarse en la interfaz.

Paso 2. Genera una primera aplicación

Si tu entorno tiene habilitada la vista previa, la guía oficial permite crear una aplicación desde la opción correspondiente, describir el problema y refinar el resultado en la vista interactiva. Puedes seguir Create an app.

Esta es una descripción inicial para experimentar:

Crea un prototipo para gestionar solicitudes de formación de una academia.

Utiliza únicamente datos ficticios.
Incluye un formulario con curso y justificación.
Muestra una lista de solicitudes y su estado.
Separa la presentación de una solicitud de su aprobación.
Indica qué acciones y fuentes de datos necesitan configurarse.
No envíes correos ni ejecutes operaciones en sistemas externos.

Después revisa campos, mensajes de validación, filtros y acciones. Comprueba con qué datos está trabajando la aplicación y qué parte del proceso es una simulación.

La descripción ayuda a construir el prototipo; los permisos y conexiones deben configurarse y verificarse mediante los controles de la plataforma.

Paso 3. Construye la automatización

Los workflows documentados para el GitHub Copilot harness combinan desencadenadores, acciones, conectores, lógica y componentes de IA. También contemplan pruebas a nivel de nodo. La referencia es Workflows overview.

En nuestro diseño, la automatización debería:

1. Recibir una solicitud con identificador.
2. Validar que el curso existe y que los campos obligatorios están completos; devolver la solicitud para corregirla si falta información.
3. Comprobar si ese identificador ya se ha procesado.
4. Determinar el responsable según una regla autorizada.
5. Solicitar la decisión humana.
6. Registrar el resultado y preparar la notificación.
7. Mantener un estado de error recuperable si una dependencia falla.

Prueba primero cada paso con datos controlados. La parte estructurada del proceso debe respetar sus reglas incluso cuando un componente de IA produzca una respuesta inesperada.

La aprobación humana puede implementarse mediante las acciones y conectores disponibles para la experiencia y el entorno. Para estudiar el patrón de aprobación, también es útil la introducción a aprobaciones de Power Automate. No presupongas que todas sus opciones están presentes de la misma forma en Copilot Studio.

Paso 4. Añade un agente con una tarea limitada

El primer agente puede orientar sobre cursos y requisitos. Mantén su alcance claro: consultar información y ayudar a preparar la solicitud. La resolución la realiza el proceso de aprobación.

Unas instrucciones iniciales podrían ser:

Ayudas a preparar solicitudes de formación.

Consulta las fuentes autorizadas antes de explicar requisitos.
Si falta información, pide una aclaración.
Si no encuentras una respuesta, indícalo.
No inventes cursos, plazas, aprobaciones ni cambios de estado.
Solo afirma que una acción ha terminado cuando la herramienta lo confirme.

Prepara las conexiones por separado. Comprueba qué identidad utiliza cada herramienta y qué acceso recibe. Las instrucciones del agente no sustituyen la autorización de la operación.

La página Start building explica dónde iniciar agentes y workflows y cómo localizar las experiencias estándar.

Hooks: controles que necesitan un diseño cuidadoso

Los hooks, actualmente en vista previa para la experiencia indicada en su documentación, ejecutan workflows cuando ocurre un evento del agente. El evento previo al uso de una herramienta puede inspeccionar y bloquear una llamada.

Hay un límite decisivo: si el workflow del hook falla, agota el tiempo o devuelve algo ilegible, el agente continúa como si no hubiera devuelto nada. Microsoft indica que no deben ser la única protección para una regla crítica. Consulta Hooks overview.

En la academia, un hook puede ayudar a registrar o comprobar llamadas. El sistema que aprueba una solicitud también debe verificar que la persona tiene autorización y que el estado permite la operación.

Cómo comprobar la solución

Antes de modificar instrucciones o modelos, prepara un conjunto de casos con resultados esperados. Este sería un punto de partida editorial:

Registra identidad, canal, entradas, fuentes, herramientas ejecutadas y resultado. Repite los casos al cambiar el modelo, una conexión o una regla.

La estrategia oficial de pruebas de agentes ofrece métodos y recursos para organizar evaluaciones. Comprueba qué métodos admite tu experiencia concreta y complementa las evaluaciones de respuestas con pruebas de permisos, efectos y fallos.

Revisa el consumo desde la fase de construcción

Para agentes, workflows y aplicaciones del GitHub Copilot harness, la facturación se mide mediante Copilot Credits. La documentación indica que crear, previsualizar, probar y evaluar también puede consumir créditos: no empieza únicamente al publicar. La estructura depende de esta experiencia y no debe extrapolarse a todas las modalidades. Consulta Overview of usage-based billing.

Antes del ejercicio, confirma acceso, capacidad asignada, conectores y posibles costes de servicios externos. Después compara el consumo de casos representativos: una consulta sencilla, una búsqueda documental y una operación con varios pasos.

Un diseño que repite búsquedas o ejecuta herramientas innecesarias merece revisión, aunque la respuesta final parezca correcta.

Qué comprobar antes de compartir

El panel Review muestra bloqueos y advertencias sobre preparación y controles organizativos. No reemplaza la supervisión administrativa ni una revisión completa de la solución. Su alcance se explica en Review agent readiness and status.

Comprueba también canales, identidad, responsables, documentación, consumo y un procedimiento para retirar o actualizar la versión. Las políticas pueden impedir publicar en determinados canales; los cambios posteriores necesitan republicación para llegar a usuarios. Consulta Publish an agent.

En este laboratorio, las aplicaciones en vista previa se mantienen como prototipo de aprendizaje. Cualquier paso hacia uso real requiere revisar su estado de disponibilidad y las condiciones vigentes.

Qué merece la pena aprender de esta evolución

Copilot Studio permite explorar una combinación de interfaz, reglas, conocimiento y razonamiento. El trabajo profesional consiste en decidir dónde aporta valor cada componente y cómo comprobar el conjunto.

Para empezar, elige un proceso pequeño y define sus datos, permisos y resultados esperados. Construye por partes, mide el comportamiento y documenta qué has verificado. Ese método te permitirá aprovechar las novedades sin perder de vista la responsabilidad sobre la solución que compartes.