Hace poco, un alumno me hizo una pregunta muy interesante sobre Microsoft Copilot Studio. La duda era muy concreta, pero al mismo tiempo tocaba uno de los puntos más importantes cuando hablamos de agentes empresariales con inteligencia artificial: cómo permitir que un agente converse con IA generativa, pero evitar que esa IA intervenga en procesos donde necesitamos exactitud total.
La pregunta del alumno era, en esencia, esta:
“Si creo un asistente en Copilot Studio con varios temas, algunos pueden funcionar con IA generativa, pero otros deben ser procesos mecánicos, exactos y sin invenciones. ¿Cómo puedo estructurar un solo agente para manejar ambos casos?”
Me pareció una pregunta tan valiosa que decidí reproducirla y convertirla en este artículo, porque refleja una preocupación real de muchas empresas: queremos agentes inteligentes, pero no queremos agentes improvisando donde hay reglas, cálculos, nóminas, altas de usuarios o procesos críticos.
La clave está en separar lo conversacional de lo transaccional
En Copilot Studio podemos construir agentes que respondan de forma natural, pero eso no significa que todo deba quedar en manos de la IA generativa.
La primera decisión importante es entender que dentro de un mismo agente pueden convivir dos tipos de procesos:
| Tipo de proceso | Ejemplo | Enfoque recomendado |
|---|---|---|
| Conversacional o abierto | Preguntas sobre productividad, Teams o recomendaciones generales | IA generativa |
| Mecánico o sensible | Cálculo de sueldos, altas de usuarios, vacaciones, validaciones internas | Tema cerrado + flujo o sistema externo |
Microsoft explica que la orquestación generativa permite que el agente seleccione temas, herramientas, conocimiento u otros agentes para responder a una consulta. En cambio, la orquestación clásica depende más de temas activados mediante frases configuradas manualmente. (Microsoft Learn)
Esto nos permite diseñar una arquitectura mixta: usamos IA donde aporta valor y usamos lógica cerrada donde necesitamos control.
Qué es la orquestación generativa en Copilot Studio
La orquestación generativa permite que el agente tome decisiones sobre qué tema, herramienta, agente o fuente de conocimiento debe usar para responder. También puede completar entradas a partir del contexto de la conversación y pedir datos faltantes si los necesita. (Microsoft Learn)
Esto es muy útil para preguntas abiertas como:
“¿Cómo puedo mejorar mi productividad con Microsoft Teams?”
“¿Qué opciones tengo para organizar mejor mi trabajo?”
“Explícame cómo funciona una herramienta de Microsoft 365.”
En estos casos, la IA puede interpretar, resumir, adaptar y responder de forma más flexible.
Pero el problema aparece cuando el usuario pregunta algo como:
“Calcula mi sueldo de este mes.”
“Dime cuánto me corresponde de comisión.”
“Da de alta este usuario en Active Directory.”
“Aprueba esta solicitud interna.”
Ahí ya no quiero creatividad. Quiero exactitud.
Cómo crear temas mecánicos dentro del mismo agente
Para los procesos que no deben depender de IA generativa, mi recomendación es crear temas específicos, cerrados y controlados.
Por ejemplo, si tengo un proceso de solicitud de vacaciones, puedo crear un tema llamado “Solicitud de vacaciones” y configurarlo con frases o condiciones claras:
“Quiero pedir vacaciones.”
“Solicitar días libres.”
“Registrar vacaciones.”
“Pedir ausencia.”
Dentro de ese tema no dejo que la IA invente el proceso. Defino pasos concretos:
- Preguntar fecha de inicio.
- Preguntar fecha de fin.
- Validar empleado.
- Consultar saldo disponible.
- Enviar solicitud al sistema correspondiente.
- Mostrar una respuesta predefinida.
Copilot Studio permite configurar desencadenadores de temas, condiciones y prioridad para controlar cuándo debe ejecutarse un tema. En agentes con orquestación generativa, el agente puede elegir un tema por su nombre y descripción; en agentes clásicos, puede activarse por frases configuradas. (Microsoft Learn)
La idea es sencilla: si el proceso es sensible, no lo dejo abierto a interpretación.
Qué pasa con los temas que sí pueden usar IA
Para temas más abiertos o educativos, puedo dejar que la IA generativa trabaje con las fuentes de conocimiento disponibles.
Por ejemplo:
“Explícame cómo usar Teams para reuniones.”
“Dame consejos para ser más productivo.”
“Resume las buenas prácticas de comunicación interna.”
“Qué herramientas de Microsoft 365 me ayudan a organizar tareas.”
En estos casos, la IA aporta valor porque puede adaptar la respuesta al contexto, explicar con ejemplos y mantener una conversación más natural.
Por eso no se trata de decidir entre IA o no IA. Se trata de diseñar bien dónde sí y dónde no.
El caso más importante: procesos sensibles como cálculo de sueldos
El alumno planteó después una observación muy acertada:
“Si un proceso es muy sensible, como el cálculo de sueldos, podríamos usar un flujo de Power Automate para ir a otro agente o a otro proceso que haga el cálculo y vuelva al agente. Así eliminamos el riesgo de que la IA haga cosas por su cuenta.”
Y la respuesta es: exactamente.
Esa es una de las mejores formas de estructurar un agente seguro.
En un proceso como cálculo de sueldos, el agente no debería calcular libremente. No debería estimar, completar datos ni interpretar reglas de nómina. Lo correcto es que el agente funcione como interfaz conversacional, pero que el cálculo real lo haga un flujo, una API o un sistema especializado.
La arquitectura sería así:
- El usuario pregunta por su sueldo.
- El tema mecánico se activa.
- Copilot Studio pide los datos necesarios.
- El agente llama a Power Automate.
- Power Automate consulta el sistema correcto o ejecuta la lógica cerrada.
- El flujo devuelve el resultado validado.
- Copilot muestra la respuesta sin reinterpretarla.
Microsoft documenta que un flujo de agente puede añadirse como herramienta dentro de Copilot Studio, configurando entradas y definiendo qué debe hacer el agente cuando el flujo termina. (Microsoft Learn)
Power Automate como capa de seguridad
Power Automate puede actuar como una capa intermedia entre el agente y los sistemas críticos.
Por ejemplo, el flujo puede:
- Recibir el ID del empleado.
- Validar si el usuario tiene permisos.
- Consultar la base de datos de nómina.
- Aplicar reglas cerradas.
- Llamar a una API externa.
- Devolver un importe exacto.
- Responder con un mensaje controlado si falta información.
De esta manera, el agente no “piensa” el cálculo. Solo recoge datos, llama al proceso y muestra el resultado.
Esto reduce muchísimo el riesgo de alucinaciones, porque la IA no está generando el dato crítico. El dato viene de una fuente validada.
También puedo redirigir a otro agente o sistema especializado
Otra opción avanzada es usar Power Automate para comunicarse con otro agente, una API REST o un backend interno.
Copilot Studio permite añadir herramientas como flujos, conectores, conectores personalizados y APIs REST. Además, con orquestación generativa activa, el agente puede seleccionar herramientas de forma dinámica, aunque también se pueden llamar explícitamente desde un tema cuando necesitamos mayor control. (Microsoft Learn)
Para procesos sensibles, yo prefiero la llamada explícita desde un tema mecánico. Así el agente no decide libremente cuándo usar el flujo: el diseño del tema lo obliga a seguir una ruta concreta.
Buenas prácticas para evitar riesgos
Cuando diseño agentes empresariales en Copilot Studio, sigo estas reglas:
Primero, identifico los procesos sensibles.
Todo lo que implique dinero, permisos, datos personales, cumplimiento legal, nómina, altas, bajas o aprobaciones debe tratarse como proceso controlado.
Segundo, creo temas mecánicos para esos procesos.
No dejo que la IA responda con conocimiento general si el usuario necesita un resultado exacto.
Tercero, uso Power Automate o APIs para la lógica real.
El agente no debe calcular sueldos, aprobar procesos ni modificar sistemas por su cuenta.
Cuarto, gestiono errores con mensajes cerrados.
Si el flujo falla, el agente no debe inventar una respuesta alternativa. Debe decir algo como: “No he podido completar la consulta en este momento. Por favor, contacta con Recursos Humanos o intenta nuevamente más tarde.”
Quinto, reviso conversaciones reales.
Si detecto que la IA respondió algo que debería haber sido mecánico, creo un nuevo tema para capturar ese caso y evitar que vuelva a ocurrir.
Orquestación de agentes en Copilot Studio: cuando un agente principal coordina agentes especializados
Además de la orquestación de temas, Copilot Studio permite trabajar con una lógica más avanzada: la orquestación de agentes. En este enfoque, no se trata solo de que un agente elija entre diferentes temas internos, sino de que pueda conectarse con otros agentes especializados para delegar tareas concretas dentro de un flujo de trabajo.
Por ejemplo, puedo tener un agente principal que atiende al usuario, entiende la intención general y, cuando detecta que la solicitud requiere una capacidad específica, deriva la operación a un agente secundario, a un agente existente del entorno o incluso a un agente externo conectado mediante Microsoft Fabric, Microsoft Foundry, el SDK de agentes de Microsoft 365 o el protocolo Agent2Agent.
Tipos de integración entre agentes en Copilot Studio: agente secundario, Fabric, Foundry, SDK y Agent2Agent
En Copilot Studio, la orquestación de agentes permite ampliar un agente principal conectándolo con otros agentes que asumen tareas específicas. Esto no es lo mismo que orquestar temas dentro de un mismo agente: aquí el agente principal puede delegar parte del trabajo a agentes internos, agentes existentes en el entorno o agentes externos especializados. Microsoft plantea este enfoque para crear soluciones más modulares, donde cada agente puede estar orientado a una tarea, un conjunto de datos o una capacidad concreta. (Microsoft Learn)
Agente secundario
Un agente secundario es un agente ligero que vive dentro del agente principal. Yo lo usaría cuando quiero dividir la lógica de un mismo proyecto en bloques más ordenados, pero sin crear agentes completamente independientes. Por ejemplo, dentro de un agente documental puedo tener un agente secundario para revisar requisitos, otro para clasificar documentos y otro para preparar una respuesta final. Es útil cuando todo pertenece al mismo caso de uso, lo gestiona el mismo equipo y no necesito publicación, autenticación ni ciclo de vida separados para cada subagente. (Microsoft Learn)
Agente existente en el entorno
También puedo conectar mi agente principal con otros agentes de Copilot Studio que ya existen en mi entorno. Esta opción es muy práctica cuando ya tengo agentes publicados y quiero reutilizarlos sin reconstruirlos. Por ejemplo, un agente principal puede atender al usuario y, si detecta que la consulta corresponde a documentación interna, derivarla a un agente documental ya publicado; si detecta una consulta de soporte, puede enviarla a otro agente especializado. Este modelo ayuda a separar responsabilidades y permite que distintos equipos mantengan sus propios agentes de forma independiente. (Microsoft Learn)
Microsoft Fabric
La integración con Microsoft Fabric permite conectar un agente principal de Copilot Studio con un Fabric Data Agent. Este tipo de agente está pensado para trabajar con datos empresariales y responder consultas basadas en información gobernada dentro de Fabric. Yo lo usaría cuando el agente necesita consultar datos analíticos, modelos semánticos, lakehouses o información corporativa preparada para análisis. En este caso, el agente principal conversa con el usuario, pero delega la consulta de datos al agente de Fabric para obtener respuestas más contextualizadas y apoyadas en datos de la organización. Esta integración aparece actualmente como versión preliminar. (Microsoft Learn)
Microsoft Foundry
La integración con Microsoft Foundry permite conectar Copilot Studio con agentes creados en Microsoft Foundry. Este enfoque tiene sentido cuando necesito capacidades más avanzadas de desarrollo, modelos, razonamiento o lógica construida fuera del entorno low-code de Copilot Studio. Por ejemplo, puedo tener un agente principal en Copilot Studio para la experiencia conversacional y un agente de Foundry encargado de una tarea especializada, como análisis avanzado, razonamiento técnico, procesamiento complejo o conexión con una arquitectura de IA más personalizada. Microsoft indica que, para esta conexión, el agente debe estar creado en el nuevo portal de Microsoft Foundry y que la descripción del agente es clave para que el agente principal sepa cuándo invocarlo. (Microsoft Learn)
SDK de agentes de Microsoft 365
La opción SDK de agentes de Microsoft 365 está pensada para conectar agentes desarrollados con código. Es decir, agentes creados por equipos técnicos usando lenguajes como C#/.NET, JavaScript o Python. Yo elegiría esta integración cuando necesito más control de desarrollo, integración con aplicaciones propias, lógica personalizada o experiencias que no se pueden resolver solo con configuración visual. En este modelo, Copilot Studio actúa como agente principal y llama al agente creado con el SDK cuando la tarea requiere esa capacidad técnica concreta. (Microsoft Learn)
Agent2Agent
La opción Agent2Agent, también conocida como A2A, permite conectar Copilot Studio con agentes externos que implementan el protocolo Agent-to-Agent. Es una alternativa muy interesante cuando el agente que quiero integrar no vive necesariamente dentro del ecosistema de Copilot Studio, Fabric, Foundry o Microsoft 365 Agents SDK. Por ejemplo, puedo conectar un agente alojado en otra plataforma, construido con otro framework o publicado en una infraestructura externa, siempre que exponga un endpoint compatible con A2A. Este enfoque es útil para arquitecturas multiagente más abiertas, donde Copilot Studio actúa como orquestador principal y delega tareas a agentes externos con su propia lógica, razonamiento o flujo de trabajo. (Microsoft Learn)
La elección entre estas opciones depende del nivel de independencia, especialización y control que necesite. Si el subproceso forma parte del mismo agente, puedo usar un agente secundario. Si ya tengo agentes publicados en mi entorno, puedo conectarlos como agentes existentes. Si necesito trabajar con datos empresariales gobernados, Fabric es una opción natural. Si necesito agentes avanzados creados en una plataforma de IA más técnica, Foundry encaja mejor. Si el desarrollo requiere código y control personalizado, puedo usar el SDK de agentes de Microsoft 365. Y si quiero conectar agentes externos compatibles con un estándar de comunicación entre agentes, Agent2Agent me permite ampliar la solución más allá del entorno nativo de Microsoft.
La conclusión: un solo agente, dos comportamientos
La respuesta a la pregunta del alumno es clara: sí, puedes tener un solo agente en Copilot Studio que combine IA generativa y procesos mecánicos.
La clave está en diseñarlo con intención:
- IA generativa para preguntas abiertas.
- Temas cerrados para procesos sensibles.
- Power Automate para ejecutar lógica controlada.
- APIs o sistemas externos para cálculos críticos.
- Mensajes predefinidos para evitar respuestas inventadas.
- Revisión continua para mejorar el comportamiento del agente.
Para mí, esta es una de las ideas más importantes cuando enseñamos Copilot Studio: un buen agente no es el que usa IA para todo, sino el que sabe cuándo debe usar IA y cuándo debe obedecer un proceso exacto.
Si quieres aprender a crear agentes seguros, útiles y bien estructurados con Microsoft Copilot Studio, te invito a revisar mis contenidos y cursos sobre inteligencia artificial aplicada a negocios digitales, automatización y productividad.
Nota de transparencia:
Este contenido ha sido generado o asistido por herramientas de Inteligencia Artificial, bajo la supervisión de EL PROFE OTTO.