Volver al catálogo
Microsoft Copilot Studio
Edición 2026. Un análisis técnico en profundidad de Microsoft Copilot Studio, que cubre Generative Orchestration, Agent Flows, herramientas, Enterprise Grounding y mucho más (2026).
Reproduciendo ahora
Click play to start
0:00
0:00
1
Generative Orchestration
Descubre el cambio de paradigma de las clásicas frases desencadenantes a Generative Orchestration en Microsoft Copilot Studio. Aprende cómo la IA selecciona dinámicamente Topics y herramientas basándose en descripciones, eliminando por completo la necesidad de un mapeo conversacional rígido. Este episodio explica cómo el enrutamiento inteligente maneja consultas con múltiples intenciones sin esfuerzo.
2
Agent Authoring basado en IA
Aprende a usar el lenguaje natural para acelerar el proceso de creación de tu bot. Exploramos el Agent Authoring basado en IA, que te permite generar Topics, prompts y flujos complejos simplemente describiéndolos. Comprende cómo se utilizan los LLMs en tiempo de compilación (build-time) para crear prototipos de agentes rápidamente.
3
Topics y Nodes
Sumérgete en la anatomía estructural de un agente. Este episodio desglosa los Topics de tipo System frente a los Custom, y la lógica determinista de los Nodes necesaria para reglas de negocio específicas. Aprende a trazar rutas conversacionales precisas utilizando variables y condiciones.
4
Estado y Variables
Dale memoria a tu agente. Descubre cómo trabajar con variables en Copilot Studio para pasar contexto entre Topics, eliminando las preguntas repetitivas. También exploramos el uso de variables de entorno para almacenar de forma segura los secretos de Azure Key Vault.
5
Entities y Slot Filling
Extrae datos estructurados a partir de lenguaje natural no estructurado. Este episodio explica las prebuilt entities, las listas cerradas personalizadas, las regex entities y la magia del proactive slot filling, que permite a la IA saltarse preguntas cuando el usuario proporciona la información por adelantado.
6
Enterprise Knowledge Grounding
Convierte tus datos empresariales existentes en un experto conversacional. Aprende a conectar SharePoint, Dataverse y sitios web públicos como fuentes de conocimiento (Knowledge) para Generative Answers. Descubre los límites y las capacidades de aplicar grounding a tu IA.
7
Tenant Graph Grounding
Desata todo el poder de Microsoft Graph y la búsqueda semántica para una recuperación de alta precisión. Este episodio explora el Tenant Graph Grounding, utilizando las licencias de Microsoft 365 Copilot para buscar en documentos empresariales masivos con una profunda comprensión semántica.
8
Prompt Tools
Capacita a tu agente para realizar tareas específicas de procesamiento de datos o resumen sobre la marcha. Aprende a crear Prompt Tools, definir plantillas, especificar inputs y configurar formatos de respuesta directamente dentro de Copilot Studio.
9
Agent Flows
Conecta Copilot Studio con automatizaciones de backend complejas y de múltiples pasos utilizando Agent Flows. Este episodio detalla cómo añadir flujos de Power Automate como herramientas, haciendo hincapié en el límite crítico de ejecución de 100 segundos y los requisitos de respuesta síncrona.
10
Power Platform Connectors
Aprovecha miles de APIs existentes en los ecosistemas de Microsoft y de terceros. Descubre cómo utilizar los Power Platform Connectors como herramientas activas en tus agentes de Copilot Studio para interactuar con servicios externos sin esfuerzo.
11
Computer Use Tool
Automatiza sistemas heredados que carecen de APIs utilizando automatización basada en visión. Descubre la versión preliminar de la Computer Use Tool, que aprovecha modelos como Claude Sonnet 4.5 para interactuar con interfaces gráficas de usuario a través de un ratón y teclado virtuales, con todas las medidas de seguridad empresariales.
12
Autenticación de usuarios
Asegura tu agente y desbloquea experiencias personalizadas. Profundiza en la autenticación de usuarios en Copilot Studio, comparando 'Authenticate with Microsoft' con las configuraciones manuales de OAuth2. Aprende a configurar scopes y a garantizar el acceso con privilegios mínimos.
13
Voz e IVR
Saca a tu agente del teclado y llévalo a la línea telefónica. Descubre las capacidades de Interactive Voice Response (IVR) de Copilot Studio. Aprende sobre el reconocimiento de voz, DTMF (entradas de teclado), barge-in y la personalización de las voces de los agentes con SSML.
14
Agent Analytics
No puedes mejorar lo que no mides. Este episodio desglosa el panel de Analytics en Copilot Studio, explicando la vista híbrida para sesiones conversacionales frente a autónomas, y cómo exportar transcripciones para un análisis profundo.
15
Model Context Protocol
Prepara a tus agentes para el futuro con el estándar abierto para el contexto de IA. Aprende a integrar Copilot Studio con servidores externos de Model Context Protocol (MCP) para ingerir Resources, Tools y Prompts de forma dinámica.
Episodios
1
Generative Orchestration
4m 05sDescubre el cambio de paradigma de las clásicas frases desencadenantes a Generative Orchestration en Microsoft Copilot Studio. Aprende cómo la IA selecciona dinámicamente Topics y herramientas basándose en descripciones, eliminando por completo la necesidad de un mapeo conversacional rígido. Este episodio explica cómo el enrutamiento inteligente maneja consultas con múltiples intenciones sin esfuerzo.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 1 de 15. La mayoría de los creadores de bots dedican horas a intentar predecir y mapear cada posible frase que un usuario podría escribir. Añades cincuenta variaciones de una petición de soporte, y el sistema sigue fallando cuando alguien escribe una frase que no habías previsto. Generative Orchestration elimina por completo esa necesidad mediante el matching dinámico de descripciones.
A menudo, cuando la gente escucha la palabra generativo en este contexto, asume que significa generar texto conversacional. Ese no es el caso aquí. Generative Orchestration se centra estrictamente en el routing dinámico y la selección de tools. Es la inteligencia la que decide qué acción tomar, en lugar de simplemente escribir una respuesta.
En la orquestación clásica, construyes un topic y defines manualmente una lista de trigger phrases. El motor de NLU se basa en esas frases exactas para hacer el routing del usuario. Generative Orchestration elimina las trigger phrases por completo. En su lugar, escribes una descripción clara en texto plano para cada topic y tool en tu agente. El Large Language Model subyacente lee la query del usuario, evalúa todas tus descripciones disponibles y determina dinámicamente el mejor match. Ya no estás mapeando inputs a triggers. Simplemente estás describiendo lo que hacen tus tools.
Esto cambia por completo cómo un agente gestiona inputs complejos. Imagina a un usuario que pregunta: ¿Qué tiempo hace en Seattle y cuándo abre la tienda?
En un setup clásico, esto se rompe. El sistema detecta dos intents contradictorios y, o bien adivina uno, o lanza un error de fallback. Generative Orchestration lo gestiona sin esfuerzo. El modelo parsea la frase completa y reconoce dos objetivos distintos. Escanea tus descripciones. Primero, encuentra una tool del tiempo. Extrae Seattle de la query del usuario, se lo pasa a la tool del tiempo como un parámetro de input y la ejecuta. Luego, recuerda la segunda mitad del prompt del usuario. Vuelve a escanear tus topics, encuentra el que está descrito para gestionar el horario comercial de la tienda y lo activa.
Aquí está la clave. El agente crea un chain con estas acciones automáticamente. Gestiona la petición del tiempo y luego hace una transición fluida al topic del horario de la tienda, combinando los resultados. No escribes ninguna lógica de routing ni código de transición para que esto ocurra.
Este cambio significa que la calidad de tu agente ahora depende completamente de la calidad de tus descripciones. Si la descripción de tu tool del tiempo simplemente dice tiempo, el modelo podría tener problemas para hacer el routing con precisión. Si la descripción dice recupera las condiciones meteorológicas actuales para un nombre de ciudad específico, el routing se vuelve exacto. Además, si un usuario hace trigger de esa tool del tiempo pero olvida especificar la ciudad, el motor generativo nota automáticamente que falta un parámetro requerido. Generará dinámicamente una pregunta para pedirle la ciudad al usuario antes de ejecutar la tool.
Tu conclusión principal es esta. Generative Orchestration convierte el routing de un frágil ejercicio de matching de frases a una búsqueda inteligente de capacidades, liberándote para que te centres en lo que tu agente puede hacer en lugar de adivinar cómo lo pedirá el usuario.
Si quieres apoyar el programa, puedes encontrarnos buscando DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!
2
Agent Authoring basado en IA
3m 51sAprende a usar el lenguaje natural para acelerar el proceso de creación de tu bot. Exploramos el Agent Authoring basado en IA, que te permite generar Topics, prompts y flujos complejos simplemente describiéndolos. Comprende cómo se utilizan los LLMs en tiempo de compilación (build-time) para crear prototipos de agentes rápidamente.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 2 de 15. Normalmente, montar un flow conversacional implica arrastrar nodes a un canvas, conectar manualmente árboles lógicos y adivinar cada posible trigger phrase que tu usuario final podría escribir. Pero, ¿y si pudieras simplemente decirle a una IA exactamente lo que quieres montar y dejar que genere la lógica estructural por ti? Este mecanismo se llama authoring de agents basado en IA.
Es fundamental distinguir esto del comportamiento de la IA en runtime. Los developers suelen confundir la IA generativa en build time con la IA generativa en runtime. El runtime es cuando un usuario real hace una pregunta y el agent genera dinámicamente una respuesta utilizando una knowledge base externa. El authoring en build time es completamente diferente. Aquí es cuando usas un asistente de IA dentro del studio para construir el framework estático del propio agent.
Empiezas en el authoring canvas. En lugar de hacer clic para añadir elementos individuales, interactúas con el authoring pane de Copilot. Supongamos que necesitas un flow para gestionar devoluciones de hardware. Escribes una descripción en inglés sencillo pidiendo un topic que le pregunte al usuario su número de pedido, compruebe si el artículo es un portátil o un dispositivo móvil, y luego proporcione la dirección de envío de devolución correcta según el tipo de equipo.
Al enviar ese prompt, el modelo de comprensión de lenguaje natural procesa tus instrucciones y las mapea directamente al schema de nodes interno de Copilot Studio. Genera automáticamente un conjunto de trigger phrases diversas que un usuario real podría decir para iniciar este flow específico. Coloca un node de pregunta en el canvas para capturar el número de pedido y le asigna una variable. Establece un node de condición para ramificar la lógica entre un portátil y un dispositivo móvil. Luego, rellena los nodes de mensaje finales con direcciones de devolución de placeholder. Todo el esqueleto del topic aparece en tu pantalla al instante.
Aquí está la clave. Este proceso de authoring es estrictamente iterativo. No estás obligado a aceptar la generación inicial como producto final. Si miras el flow generado y te das cuenta de que necesitas capturar la fecha de compra, no tienes que romper manualmente las conexiones e insertar un nuevo node. Simplemente le dices al Copilot de authoring que añada una pregunta pidiendo la fecha de compra justo antes de pedir el número de pedido. El modelo subyacente analiza el estado actual de tu canvas, entiende el punto de inserción secuencial y modifica el flow de forma segura.
Como la IA traduce el lenguaje natural directamente a componentes estándar de Copilot Studio, conservas el control arquitectónico total. Los nodes generados no son cajas negras. Son exactamente los mismos elementos que habrías creado manualmente. Puedes hacer clic en las ramas de condición, ajustar los tipos de variables o reescribir el texto del prompt a mano. El modelo de lenguaje simplemente se encarga del ensamblaje mecánico del canvas.
El verdadero poder del authoring basado en IA no es que escriba flows conversacionales impecables al primer intento, sino que transforma el lento proceso mecánico de conectar nodes en un diálogo rápido sobre la intención de negocio. Gracias por estar ahí. Espero que hayas aprendido algo nuevo.
3
Topics y Nodes
3m 53sSumérgete en la anatomía estructural de un agente. Este episodio desglosa los Topics de tipo System frente a los Custom, y la lógica determinista de los Nodes necesaria para reglas de negocio específicas. Aprende a trazar rutas conversacionales precisas utilizando variables y condiciones.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 3 de 15. Incluso los agentes de IA más avanzados tarde o temprano necesitan lógica determinista para reglas de negocio específicas. Cuando un cliente pregunta sobre tu política de devoluciones o el horario de la tienda, no te puedes permitir una suposición probabilística de un modelo de lenguaje. Necesitas una respuesta estricta y garantizada. Los Topics y los Nodes te dan ese control estructural exacto.
Piensa en un Topic como un path de conversación discreto. Es un árbol de diálogo predefinido que dicta exactamente cómo tu agente gestiona un intent específico. Tu agente en general es, en esencia, una colección de estos Topics trabajando juntos para enrutar al usuario. Un punto frecuente de confusión es la distinción entre los System topics y los Custom topics. Es más sencillo de lo que parece. Los System topics gestionan los comportamientos fundamentales del agente. Estos controlan eventos core como saludar a un usuario, finalizar una conversación, escalar a un humano o capturar un error cuando el agente no entiende el input. Puedes modificar su texto para que coincida con la voz de tu marca, pero no puedes eliminarlos. Son elementos permanentes de la arquitectura del sistema. Los Custom topics son los paths que tú mismo creas, bajo tu control total, para gestionar tus escenarios de negocio específicos.
Dentro de cada Topic, la conversación se ejecuta de arriba a abajo a través de pasos individuales llamados Nodes. Los Nodes son los bloques de construcción funcionales del path. Para comprender cómo interactúan, imagina un Custom topic diseñado para gestionar consultas sobre el horario de la tienda.
Cuando el usuario activa este Topic, el primer paso de tu flow podría ser un Question node. Un Question node lanza un prompt al usuario pidiendo información y espera un tipo específico de respuesta. En este caso, el agente pregunta qué ciudad planea visitar el usuario. Cuando el usuario responde, el Node captura esa respuesta.
Esto introduce la gestión de Variables. El Question node almacena automáticamente la respuesta del usuario en una Variable. Ahora tienes una pieza de state distinta en memoria, lo que te permite enrutar la conversación dinámicamente según lo que el usuario acaba de decir.
Aquí es donde la cosa se pone interesante. En lugar de dar una respuesta genérica, añades un Condition node para evaluar esa Variable. Un Condition node actúa como una bifurcación lógica en el camino. Comprueba el state actual de tu Variable contra las reglas que definas. Si la ciudad almacenada es Nueva York, el Node dirige el flow por un branch. Si la ciudad es Londres, dirige el flow por otro. Puedes añadir tantos branches como necesites para los diferentes states, además de un branch de fallback si la Variable no coincide con ninguna ciudad conocida.
Finalmente, al final de cada branch condicional, colocas un Message node. Un Message node simplemente muestra texto o contenido multimedia al usuario. El branch de Nueva York llega a un Message node que indica que la tienda abre a las nueve de la mañana. El branch de Londres llega a otro Message node que indica que abre a las diez.
Al hacer chaining de los Nodes de Question, Variable, Condition y Message, dictas exactamente cómo fluye la lógica. La conclusión más importante aquí es que los Topics aíslan tus reglas de negocio deterministas en paths predecibles, asegurando que tu agente responda de forma fiable cuando la precisión importa más que la generación.
Gracias por escucharnos. ¡Hasta la próxima!
4
Estado y Variables
3m 54sDale memoria a tu agente. Descubre cómo trabajar con variables en Copilot Studio para pasar contexto entre Topics, eliminando las preguntas repetitivas. También exploramos el uso de variables de entorno para almacenar de forma segura los secretos de Azure Key Vault.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 4 de 15. La forma más rápida de frustrar a un usuario es hacerle repetir la información que te acaba de dar. Si tu bot pide un nombre, lanza un nuevo workflow, y luego vuelve a pedir el nombre, la experiencia de usuario se rompe por completo. El mecanismo que evita esta amnesia es el state y las variables.
Una variable en Copilot Studio almacena datos extraídos del usuario o recuperados de un sistema backend. La decisión más importante que tomas al crear una variable es definir su scope. Los oyentes suelen confundir las variables a nivel de topic con las variables globales. Una variable a nivel de topic es estrictamente local. Solo existe mientras su topic padre esté activo. En el momento en que ese topic termina, la variable se borra de la memoria. Una variable global, en cambio, persiste durante toda la conversación. Cualquier topic puede leerla, y cualquier topic puede sobrescribirla.
Es tentador convertir cada dato compartido en una variable global. No lo hagas. Abusar de las variables globales genera cambios de state impredecibles cuando los topics se interrumpen entre sí. En su lugar, pasa las variables locales directamente entre topics. Piensa en un topic llamado Greeting. Le pide al usuario su nombre y lo guarda en una variable local. El saludo termina, y el flujo se redirige a un nuevo topic llamado Talk to Customer. Para pasar el nombre, configuras el topic Talk to Customer para que reciba valores de otros topics. Defines una variable de input en este topic de destino. Luego, de vuelta en tu topic Greeting, el node de redirección te pedirá automáticamente que mapees un valor a ese input. Pasas la variable local del nombre a través del node. El topic de destino la captura, el bot continúa la conversación usando el nombre correcto, y tu state global se mantiene limpio. Cuando ese topic de destino termina su trabajo, también puede devolver valores al topic original que lo llamó usando variables de output.
Eso cubre los datos generados durante un chat. Ahora, la segunda parte tiene que ver con los datos que tu agente necesita incluso antes de que empiece un chat. Si tu agente se conecta a sistemas externos, necesita credenciales. Nunca debes guardar API keys o connection strings en variables de conversación. Para esto, usas environment variables. Las environment variables viven completamente fuera de la sesión del usuario. Guardan datos de configuración que se aplican al propio agente, permitiéndote mover tu bot de un entorno de desarrollo a testing, y finalmente a producción, sin hacer hardcoding de los valores.
Presta atención a esta parte. Al tratar con datos muy sensibles, las environment variables se integran directamente con Azure Key Vault. En lugar de pegar una contraseña en Copilot Studio, creas una environment variable marcada como secret. Esta variable guarda una referencia a una key específica en tu Azure Key Vault. Durante el runtime, el agente recupera de forma segura el secret para autenticar la petición al backend. El secret nunca se expone en el canvas de creación, nunca se imprime en los logs del chat, y se excluye de tus exportaciones de source control.
El state más seguro es un state con scope, así que mantén las variables de conversación locales siempre que sea posible, pásalas explícitamente entre topics, y delega siempre las credenciales del sistema a environment variables seguras. ¡Gracias por escuchar, happy coding a todos!
5
Entities y Slot Filling
4m 35sExtrae datos estructurados a partir de lenguaje natural no estructurado. Este episodio explica las prebuilt entities, las listas cerradas personalizadas, las regex entities y la magia del proactive slot filling, que permite a la IA saltarse preguntas cuando el usuario proporciona la información por adelantado.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 5 de 15. Creas un bot para recibir pedidos, pero obliga a los usuarios a pasar por cinco preguntas tediosas. El usuario ya te ha dado todos los detalles en su primer mensaje, pero tu bot ignora ese contexto y se los sigue preguntando uno por uno. Este comportamiento rígido frustra a los usuarios, y es exactamente el problema que resuelven las entities y el slot filling.
Las entities son la forma en que Copilot Studio reconoce conceptos del mundo real a partir de un lenguaje natural desordenado. Piensa en una entity como un data type específico que tu bot está entrenado para detectar dentro de una frase. En lugar de analizar la frase completa «me gustaría gastar veinte pavos», la IA simplemente busca la entity de dinero y extrae el valor veinte.
Copilot Studio viene con un gran conjunto de prebuilt entities. Estas manejan conceptos de datos estándar out of the box. Las prebuilt entities reconocen edad, fechas, colores, números, nombres y dinero. Normalizan los datos automáticamente. Tanto si el usuario escribe veinte dólares, el símbolo del dólar seguido de 20, o veinte pavos, la prebuilt entity de dinero extrae el valor numérico exacto y la moneda.
Pero tu negocio funciona con una terminología específica. Para capturarla, creas custom entities. Hay dos tipos principales de custom entities que vas a usar. El primero es una closed list entity. Defines una lista estricta de elementos permitidos y luego le asignas sinónimos a cada uno. Si vendes equipamiento de montaña, podrías crear una entity de categoría de producto con un elemento principal llamado senderismo. Luego añades sinónimos como trekking, excursionismo y caminatas. Cuando el usuario escribe cualquiera de esos sinónimos, la IA mapea su input directamente al valor principal de senderismo.
El segundo tipo personalizado es la entity de expresión regular, o regex. Usas entities regex cuando los usuarios necesitan proporcionar strings formateados en lugar de palabras específicas. Un caso de uso común es un ticket de soporte o un ID de pedido. Si tu sistema usa números de seguimiento que siempre empiezan con las letras TRK seguidas de cinco dígitos, defines ese patrón usando regex. La IA escaneará el mensaje del usuario y extraerá limpiamente ese string exacto, ignorando cualquier texto que lo rodee.
Identificar la entity es solo el primer paso. Necesitas almacenar esos datos para usarlos. Esta acción se llama slot filling. Mapeas una entity extraída a una variable, llenando el slot con los datos del usuario.
Aquí es donde la cosa se pone interesante. Copilot Studio usa una feature llamada proactive slot filling. Por defecto, el motor de comprensión de lenguaje natural evalúa cada mensaje del usuario contra todas las variables que requiere tu topic de conversación. Si la IA detecta las entities requeridas en el input inicial del usuario, llena esos slots inmediatamente.
Imagina a un usuario que activa tu topic de compra diciendo: «Quiero comprar botas de senderismo por menos de 100 dólares». Tienes una closed list entity personalizada para la categoría de producto, y estás usando la prebuilt entity de dinero para el presupuesto. Gracias al proactive slot filling, la IA procesa toda esa frase de una sola vez. Aísla senderismo, lo mapea a tu variable de categoría, y lo almacena. Aísla 100 dólares, lo mapea a tu variable de presupuesto, y lo almacena.
Como esos slots ya están llenos, el bot se salta automáticamente los nodos de pregunta de «¿Qué categoría buscas?» y «¿Cuál es tu presupuesto?» por completo. El flujo de conversación se los salta y pasa directamente a la siguiente pieza de información que falta.
Al definir entities estrictas y confiar en que el proactive slot filling se encargue de la extracción, dejas de escribir decision trees rígidos y empiezas a crear agentes conversacionales que respetan el tiempo del usuario.
Eso es todo por este episodio. Gracias por escuchar, ¡y sigue creando!
6
Enterprise Knowledge Grounding
4m 37sConvierte tus datos empresariales existentes en un experto conversacional. Aprende a conectar SharePoint, Dataverse y sitios web públicos como fuentes de conocimiento (Knowledge) para Generative Answers. Descubre los límites y las capacidades de aplicar grounding a tu IA.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 6 de 15. La parte más difícil de crear un agente conversacional solía ser predecir cada pregunta del usuario y escribir manualmente las respuestas. Te pasabas semanas diseñando árboles de diálogo, solo para que los usuarios preguntaran algo un poco fuera del guion y llegaran a un callejón sin salida. Enterprise Knowledge Grounding le da la vuelta por completo a este modelo. En lugar de escribir las respuestas, los datos existentes de tu empresa se encargan de todo el trabajo pesado.
Un Large Language Model genérico es muy elocuente, pero no sabe absolutamente nada sobre tu empresa específica. Enterprise Knowledge Grounding cierra esta brecha conectando el copilot directamente con tus datos empresariales reales, como sitios web públicos, directorios de SharePoint, archivos subidos y tablas de Dataverse.
Imagina un escenario de atención al cliente. Necesitas un agente que responda preguntas sobre tu hardware. En lugar de crear cientos de custom topics, subes los manuales de tus productos en PDF al copilot y pegas la URL de tu sitio de documentación pública. Cuando un usuario pregunta cómo resetear un modelo de router específico, el copilot busca en esas fuentes conectadas, recupera el texto relevante y sintetiza una respuesta directa. También proporciona un link de referencia al manual o página web específica, para que el usuario pueda verificar la información.
Un punto de confusión muy común es dónde vive exactamente este conocimiento dentro de la arquitectura. Puedes vincular el conocimiento en dos lugares distintos: a nivel de agente o a nivel de topic.
El conocimiento a nivel de agente es global. Actúa como una red de seguridad en todo el copilot. Si un usuario hace una pregunta y no se dispara ningún topic creado manualmente, el sistema hace un fallback a este pool global de conocimiento. Busca en todas tus fuentes conectadas a nivel de agente para generar una respuesta. Esto significa que obtienes valor inmediato sin necesidad de escribir flujos de conversación personalizados.
Aquí está la clave. A veces necesitas un control estricto sobre los datos que utiliza la IA, y ahí es donde entra en juego el conocimiento a nivel de topic. Esto lo configuras arrastrando un nodo de Generative Answers directamente al canvas de creación de un custom topic específico.
Si un usuario dispara un custom topic para procesar una reclamación de garantía, no quieres que la IA obtenga respuestas de tu sitio web de marketing general. Al usar un nodo de Generative Answers dentro de ese topic específico, puedes restringir su data source exclusivamente a una carpeta de SharePoint que contenga documentos de garantía legal. El scope de la IA se limita exactamente al contexto de ese paso de la conversación.
Al conectar estas fuentes empresariales, el sistema gestiona el acceso de forma inteligente. Para sitios web públicos, el copilot simplemente indexa las páginas públicas. Para fuentes internas como SharePoint, el copilot utiliza las credenciales de Entra ID de la persona que interactúa con el bot. Respeta estrictamente los permisos de archivo existentes. Si un empleado no tiene acceso a un documento interno específico en SharePoint, el copilot no leerá ese documento ni lo utilizará para responder a su pregunta.
Para datos estructurados, puedes conectarte directamente a tablas de Dataverse, lo que permite que el copilot base sus respuestas en los registros en tiempo real de tus aplicaciones empresariales.
Usar un nodo de Generative Answers dentro de un custom topic te permite controlar con precisión los límites exactos del conocimiento de la IA en puntos específicos de una conversación, evitando que los datos globales generales ensucien workflows altamente específicos. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue desarrollando!
7
Tenant Graph Grounding
3m 45sDesata todo el poder de Microsoft Graph y la búsqueda semántica para una recuperación de alta precisión. Este episodio explora el Tenant Graph Grounding, utilizando las licencias de Microsoft 365 Copilot para buscar en documentos empresariales masivos con una profunda comprensión semántica.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 7 de 15. La búsqueda estándar por keywords falla en el momento en que un usuario hace una pregunta con matices sobre una política interna. No necesitas mejores keywords. Necesitas un sistema que entienda el significado real de la pregunta en datasets masivos. Ahí es exactamente donde entra en juego Tenant Graph Grounding.
Tenant Graph Grounding aporta una comprensión semántica profunda directamente a los datos de tu empresa. Primero, aclaremos un malentendido común. Esto no es la búsqueda estándar de Dataverse, y no tiene nada que ver con hacer scraping de webs públicas. Es una capacidad avanzada de retrieval empresarial que conecta tu copilot directamente con Microsoft Graph. Está construida específicamente para gestionar el conocimiento interno complejo almacenado en todo tu tenant.
Para usar esta funcionalidad, tu entorno debe cumplir unos requisitos estrictos. Necesitas una licencia de Microsoft 365 Copilot. Tus datos deben estar indexados por el Semantic Index para Copilot. Y lo más crucial, tu copilot debe estar configurado con autenticación de Microsoft Entra ID. Esto no es opcional. El copilot debe pasar de forma segura la identidad de la persona que hace la pregunta a Microsoft Graph.
Imagina un copilot interno de Recursos Humanos diseñado para buscar en manuales de empleados gigantescos. Estos manuales suelen vivir en SharePoint o OneDrive como documentos enormes. Las herramientas de retrieval estándar a menudo se atascan con archivos grandes, pero Tenant Graph Grounding soporta archivos de hasta 512 megabytes. Cuando un empleado pregunta por un caso muy específico, como la política de baja por paternidad o maternidad para un cuidador secundario que trabaja a tiempo parcial, un motor de búsqueda tradicional busca esas palabras exactas. Si el manual usa una redacción diferente, la búsqueda falla.
Aquí está la clave. Como esta funcionalidad usa el Semantic Index, mapea las relaciones conceptuales entre la query del usuario y los datos de la empresa. Entiende que la query sobre la baja por paternidad o maternidad se mapea conceptualmente con una sección titulada tiempo libre familiar, incluso si las keywords no coinciden perfectamente.
El flujo lógico opera completamente dentro del límite seguro de tu tenant. Un usuario envía un prompt al copilot. El copilot usa el token de Entra ID de ese usuario específico para hacer una query a Microsoft Graph. Entonces, Microsoft Graph busca en el Semantic Index, pero solo mira los archivos que ese usuario específico ya tiene permisos para leer. Si un documento está restringido, Graph simplemente lo ignora para ese usuario.
Graph recupera las coincidencias semánticas más relevantes y se las devuelve al copilot. Luego, el copilot usa esos chunks de datos exactos para generar una respuesta precisa y grounded. Toda la transacción ocurre con una precisión casi instantánea, saltándose la latencia y la inexactitud de intentar crear tus propios índices de búsqueda custom sobre datos de SharePoint.
Tenant Graph Grounding traslada toda la carga de retrieval de tu lógica custom directamente a la infraestructura semántica de Microsoft 365, garantizando que tu copilot respete los límites de datos empresariales existentes mientras ofrece una precisión contextual inigualable. Si quieres apoyar el programa, puedes encontrar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!
8
Prompt Tools
4m 20sCapacita a tu agente para realizar tareas específicas de procesamiento de datos o resumen sobre la marcha. Aprende a crear Prompt Tools, definir plantillas, especificar inputs y configurar formatos de respuesta directamente dentro de Copilot Studio.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 8 de 15. A veces no necesitas crear una API compleja ni integrar un servicio de parsing externo para procesar los datos entrantes. Simplemente necesitas un Large Language Model que examine un string de texto desordenado y lo procese exactamente como quieres. Ahí es donde entran en juego los Prompt Tools.
Primero, debemos aclarar un punto de confusión común. Los Prompt Tools son completamente diferentes de las Generative Answers. Las Generative Answers escanean una base de conocimientos externa o un sitio web para responder dinámicamente a las preguntas de los usuarios. Los Prompt Tools no buscan respuestas. Son instrucciones específicas y muy elaboradas que le indican a un Large Language Model que ejecute una tarea estrictamente definida sobre los datos que proporcionas.
Piensa en un Prompt Tool como una función reutilizable donde la lógica subyacente está escrita en lenguaje natural en lugar de código. Lo creas definiendo un prompt template, especificando variables de input y proporcionando reglas contextuales estrictas.
Considera un escenario común. Recibes un bloque de comentarios de clientes no estructurados y divagantes. Quieres extraer el sentimiento subyacente y generar una lista limpia de action items específicos. En lugar de escribir expresiones regulares complejas o un script de parsing personalizado, creas un Prompt Tool.
Empiezas definiendo los inputs. En Copilot Studio, creas una variable de input llamada feedback text y defines su tipo de datos. Este sencillo paso le indica a la herramienta que espere un string dinámico cada vez que el sistema la invoque.
A continuación, escribes el prompt template. Este es el conjunto de instrucciones principal que se envía al modelo de lenguaje. Escribes con precisión lo que el modelo debe hacer. Le indicas que lea la variable feedback text, determine si el tono es positivo, negativo o neutral, e identifique cualquier tarea que el equipo de atención al cliente deba gestionar basándose en el texto.
Aquí está la clave. El template es prácticamente inútil sin un contexto estricto. No basta con pedirle al modelo el sentimiento y esperar que responda bien. Defines la estructura de salida exacta dentro del contexto del prompt. Le indicas explícitamente al modelo que devuelva el resultado formateado como un objeto JSON estricto que contenga una key de sentiment y un array de action items. Prohíbes el relleno conversacional. Este contexto transforma una respuesta genérica y coloquial del modelo de lenguaje en un payload de datos estructurado y predecible que tus sistemas downstream realmente pueden parsear.
Cuando tu agente activa esta herramienta durante una conversación en directo, el flujo de ejecución está completamente automatizado. El agente toma la respuesta del cliente en tiempo real y la pasa a tu input de feedback text. La herramienta inyecta dinámicamente ese string en tu template, envía el paquete de instrucciones completo al modelo y devuelve el JSON estructurado. El agente puede entonces usar esos action items extraídos para actualizar automáticamente una base de datos o redirigir al usuario a una cola de soporte especializada.
Defines la herramienta una sola vez, y el agente la llama automáticamente cada vez que detecta la necesidad de procesar texto no estructurado. Un Prompt Tool bien diseñado traslada la carga del procesamiento de texto complejo desde el código de tu aplicación hacia el modelo de lenguaje, permitiéndote extraer datos perfectamente estructurados del caos total usando nada más que unas pocas líneas de inglés sencillo. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!
9
Agent Flows
3m 55sConecta Copilot Studio con automatizaciones de backend complejas y de múltiples pasos utilizando Agent Flows. Este episodio detalla cómo añadir flujos de Power Automate como herramientas, haciendo hincapié en el límite crítico de ejecución de 100 segundos y los requisitos de respuesta síncrona.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 9 de 15. Tu agente necesita ejecutar un workflow complejo de backend que abarca varios sistemas. Quizás necesite consultar una base de datos aislada, filtrar los datos y actualizar un sistema de inventario, todo a la vez. Una sola API call no puede gestionar esa orquestación. La solución es un Agent Flow.
Los Agent Flows conectan Copilot Studio con Power Automate. Permiten empaquetar una automatización de varios pasos como una tool independiente que tu agente puede ejecutar de forma autónoma. El agente se basa completamente en el nombre y la descripción que le des al flow. Basándose en ese texto, el agente decide si el flow puede resolver la petición del usuario. Cuando encuentra un match, el agente extrae los parámetros necesarios de la conversación, se los pasa al flow, espera a la ejecución y usa el output final para generar una respuesta.
La estructura de un Agent Flow es estricta. Debe empezar con un trigger específico diseñado para Copilot, que define explícitamente los inputs de texto o numéricos. Debe terminar con una acción específica que responda a Copilot, definiendo los outputs de texto o numéricos. Todo lo que hay entre esos dos nodos es lógica estándar de Power Automate. Puedes iterar sobre arrays, llamar a conectores personalizados o parsear archivos.
Imagina un escenario donde tu agente necesita recuperar el historial de pedidos de una base de datos SQL legacy. El usuario pide sus pedidos recientes. El agente hace trigger del flow, pasando el string del ID de cliente como input. Dentro del flow, construyes la lógica para conectarte a la base de datos SQL, ejecutar la query y formatear las filas raw de la base de datos en un string JSON limpio. Luego, el flow devuelve ese string formateado al agente a través del nodo de respuesta. El agente lee el string, extrae los detalles del pedido y responde al usuario en lenguaje natural.
Aquí está la clave. La ejecución debe ser completamente síncrona. El agente inicia el flow y mantiene la conexión abierta, esperando la respuesta. Si creas un flow asíncrono, no funcionará como una tool del agente. No puedes incluir pasos que pausen la lógica. Si tu flow envía un email de aprobación y espera a que un humano haga clic en un botón, el agente fallará. El patrón de la tool requiere un retorno inmediato de datos.
Esto nos lleva a un límite estricto del sistema. Tienes exactamente cien segundos. Desde el momento en que el agente hace trigger del flow, la lógica tiene cien segundos para ejecutar cada paso, hacer la query a la base de datos, formatear el output y devolver la respuesta. Si el servidor SQL legacy está bajo carga, o si tu flow itera sobre demasiados registros, la ejecución superará el límite de timeout. Cuando eso pasa, el agente corta la conexión por completo y devuelve un mensaje de error al usuario.
Para gestionar este límite, debes mantener la automatización con un scope muy ajustado. Si un proceso de backend tarda cinco minutos, no lo ejecutes dentro del Agent Flow. En su lugar, usa el flow para lanzar un background job externo y devolver inmediatamente un tracking ID al agente.
Tu arquitectura de automatización debe respetar la ventana de timeout. Diseña tus flows para que se ejecuten rápidamente, recuperen exactamente lo que se necesita y devuelvan el control al agente, asegurando que el usuario nunca se quede hablando con una conexión bloqueada.
Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!
10
Power Platform Connectors
4m 34sAprovecha miles de APIs existentes en los ecosistemas de Microsoft y de terceros. Descubre cómo utilizar los Power Platform Connectors como herramientas activas en tus agentes de Copilot Studio para interactuar con servicios externos sin esfuerzo.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 10 de 15. Pasas días escribiendo y manteniendo integraciones de API personalizadas solo para que tu agente pueda comunicarse con el mundo exterior. Mientras tanto, miles de wrappers preconstruidos ya están en tu entorno, listos para ejecutarse. Hoy, vamos a ver los conectores de Power Platform.
Los conectores son wrappers de API estandarizados. Proporcionan una forma predecible para que Microsoft Copilot Studio se comunique con servicios externos. Antes de ver cómo funcionan, debemos aclarar una confusión común. Los usuarios suelen confundir usar un sistema externo como fuente de conocimiento con usarlo como herramienta. Si tu agente hace una query a una base de datos solo para recuperar datos y fundamentar sus respuestas conversacionales, eso es conocimiento pasivo. Usar un conector como herramienta es diferente. Es una operación activa. Le estás dando al agente la autoridad para ejecutar acciones, crear registros o hacer trigger de procesos externos en nombre del usuario.
Hay tres categorías de conectores disponibles. Los conectores estándar cubren los servicios básicos de Microsoft y los endpoints públicos comunes. Los conectores premium requieren una licencia específica y se conectan a sistemas empresariales como Salesforce o ServiceNow. Si el sistema al que necesitas acceder es una API interna propietaria, puedes crear un conector personalizado. Un conector personalizado es simplemente un wrapper de OpenAPI que tú mismo defines. Una vez registrado en tu entorno, se comporta exactamente igual que los estándar y premium. Al agente no le importa quién lo creó.
Veamos cómo funciona esta lógica con un escenario concreto. Quieres que tu agente compile un resumen del proyecto y lo envíe por correo electrónico a tu equipo de ingeniería. En lugar de construir manualmente una request HTTP, añades el conector de Office 365 Outlook directamente a tu copilot como una acción. Cada conector expone operaciones específicas. En este caso, seleccionas la acción de enviar un correo electrónico.
Esta es la parte importante. No escribes código procedimental para dictar exactamente cuándo se envía este correo. En su lugar, defines los parámetros que el conector necesita para funcionar. El conector de Outlook necesita una dirección de destino, un asunto y el cuerpo del mensaje. Configuras estos inputs y proporcionas una descripción clara en lenguaje natural de lo que hace la acción.
Copilot se basa completamente en esa descripción para determinar cuándo hacer trigger de la herramienta. Cuando un usuario le pide al agente que envíe la actualización de estado semanal al equipo de ingeniería, el agente evalúa sus herramientas disponibles. Hace match entre la request del usuario y la descripción de tu conector de Outlook. A continuación, el agente extrae dinámicamente el nombre del destinatario y el texto del resumen de la conversación en curso. Mapea esos valores extraídos a los inputs del conector y ejecuta la acción.
Una vez que la API externa procesa la request, el conector devuelve una respuesta al agente. Esto puede ser un simple código de éxito o un payload con detalles específicos sobre la transacción. El agente recibe estos datos, verifica que la acción se haya completado y genera una respuesta en lenguaje natural que le informa al usuario que el correo electrónico se ha enviado.
Al estandarizar la interfaz, estos wrappers eliminan la necesidad de gestionar tokens de autenticación, headers y el manejo de errores para cada servicio individual. Configuras la conexión una sola vez y el agente orquesta la ejecución. Los conectores transforman tu agente de una interfaz conversacional estática en una herramienta operativa que realmente modifica el estado en toda tu infraestructura. Eso es todo por este episodio. ¡Gracias por escuchar y sigue construyendo!
11
Computer Use Tool
3m 27sAutomatiza sistemas heredados que carecen de APIs utilizando automatización basada en visión. Descubre la versión preliminar de la Computer Use Tool, que aprovecha modelos como Claude Sonnet 4.5 para interactuar con interfaces gráficas de usuario a través de un ratón y teclado virtuales, con todas las medidas de seguridad empresariales.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 11 de 15. Si una aplicación no tiene API, la automatización tradicional se topa con un muro. O escribes scripts frágiles que se rompen en cuanto un botón cambia de sitio, o aceptas introducir los datos a mano. La herramienta de Computer Use resuelve esto permitiendo que tu IA literalmente vea la pantalla y opere la máquina por sí misma.
Disponible en preview, esta funcionalidad permite que tu agent interactúe con una interfaz gráfica de usuario usando un ratón y un teclado virtuales. Se basa en Computer-Using Agents, impulsados por modelos con capacidad de visión como Claude 3.5 Sonnet de Anthropic. Hay que aclarar lo que no es. Esto no es el tradicional Robotic Process Automation. El RPA estándar se basa en hooks estructurales subyacentes, como etiquetas del DOM o IDs de elementos de la UI. La herramienta de Computer Use opera completamente a nivel de píxeles.
El flujo lógico es un loop continuo. La herramienta hace una screenshot del entorno de escritorio y se la pasa al modelo. El modelo analiza el layout visual, razona sobre la petición del usuario y calcula las coordenadas exactas para su siguiente movimiento. Devuelve instrucciones al sistema. El sistema las traduce en mover el cursor virtual a una posición X e Y específica, hacer clic con el ratón o enviar un string de pulsaciones de teclas. Tras ejecutar la acción, la herramienta hace otra screenshot para evaluar el nuevo estado de la pantalla, verificando si se ha abierto una ventana o ha aparecido texto, antes de decidir su siguiente paso.
Imagina un escenario en el que necesitas extraer datos de una aplicación legacy de escritorio de Windows y meterlos en un formulario web moderno. El agent mira la screenshot de la app legacy, localiza visualmente el número de factura y guarda esa información. Luego devuelve instrucciones para mover el ratón a la ventana del navegador, hacer clic dentro del campo del formulario web de destino y teclear los dígitos. Navega por la interfaz exactamente como lo haría un operador humano, guiándose completamente por el contexto visual de la pantalla.
Darle a un modelo de IA control físico sobre un escritorio requiere controles de seguridad estrictos. Aquí está la clave. Nunca haces deploy de esto en un servidor de producción o en la estación de trabajo principal de un usuario. El agent debe operar dentro de una máquina virtual o un container dedicado y aislado. Le concedes a este entorno los privilegios mínimos absolutos necesarios para completar la tarea específica. Como el modelo puede navegar por navegadores web por su cuenta, tienes que aplicar controles de red estrictos. Aplicas una URL allow list para que el agent solo pueda acceder a dominios aprobados, evitando que interactúe con sitios web no fiables o servicios externos. También te aseguras de que la máquina virtual no tenga datos sensibles fuera del workload inmediato.
Al tratar la interfaz gráfica de usuario como un stream de entrada visual más, cierras la brecha entre el razonamiento inteligente y el software legacy inaccesible sin escribir ni una sola línea de código de integración. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!
12
Autenticación de usuarios
3m 47sAsegura tu agente y desbloquea experiencias personalizadas. Profundiza en la autenticación de usuarios en Copilot Studio, comparando 'Authenticate with Microsoft' con las configuraciones manuales de OAuth2. Aprende a configurar scopes y a garantizar el acceso con privilegios mínimos.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 12 de 15. Un agente es tan poderoso como los datos a los que puede acceder. Pero si tu agente consulta un sistema privado y, por error, le muestra tu calendario personal a un empleado totalmente distinto, tienes un fallo de seguridad enorme. Para evitarlo, debes configurar correctamente la autenticación de usuarios.
El error más común que cometen los desarrolladores aquí es confundir las credenciales del maker con las credenciales del usuario final. Si incrustas tus propias API keys o credenciales de service principal en una acción del agente, el bot ejecuta esas acciones como si fueras tú. Cualquier persona que chatee con el agente se saltará sus propios límites de seguridad y accederá a los datos usando tus permisos. La autenticación de usuarios obliga al agente a ejecutar las consultas exactamente como la persona que escribe el prompt, basándose por completo en su identidad única.
En Copilot Studio, eliges principalmente entre dos estados de autenticación: Autenticar con Microsoft y Autenticar manualmente. Autenticar con Microsoft es la vía más directa para herramientas internas. Si tu agente opera exclusivamente dentro de Microsoft Teams o Power Apps, esta configuración usa automáticamente el token de Microsoft Entra ID de la persona que ha iniciado sesión en la aplicación. No hay un prompt de login por separado. El contexto del usuario simplemente fluye hacia el agente.
Cambias a Autenticar manualmente cuando tu agente vive en un sitio web externo personalizado, o cuando necesitas un control estricto y granular sobre los permisos. Este método se basa en configurar una conexión OAuth2 a un proveedor de identidad, que normalmente es un App Registration en Microsoft Entra ID.
Pongamos un escenario concreto. Estás creando un agente que consulta la agenda personal de un empleado. Configuras Autenticar manualmente y lo vinculas a tu App Registration de Entra ID. Aquí está la clave. El agente no obtiene acceso total a toda la cuenta de Microsoft del usuario. En su lugar, defines scopes estrictos en tu configuración. Configuras el nodo de autenticación para que solicite un scope específico llamado Calendars dot Read.
Cuando un usuario le pide al agente su agenda, el agente pausa su lógica y muestra una tarjeta de login en el chat. El usuario hace clic en el enlace, se autentica a través de su navegador y ve una pantalla que le pide que conceda al agente acceso de lectura a su calendario. Una vez que da su consentimiento, Microsoft Entra ID genera un access token y lo devuelve de forma segura al agente.
Este access token está vinculado estrictamente a ese usuario individual y restringido únicamente al scope del calendario. Cuando el agente hace la petición HTTP real para obtener la agenda, incluye este token. La API del backend inspecciona el token, confirma la identidad del usuario y devuelve de forma segura solo sus eventos de calendario específicos. Configurar bien la autenticación de usuarios es lo que transforma un chatbot genérico en un asistente personalizado, demostrándole a tus sistemas backend exactamente quién está pidiendo los datos para que nunca filtres información privada entre sesiones.
Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.
13
Voz e IVR
4m 39sSaca a tu agente del teclado y llévalo a la línea telefónica. Descubre las capacidades de Interactive Voice Response (IVR) de Copilot Studio. Aprende sobre el reconocimiento de voz, DTMF (entradas de teclado), barge-in y la personalización de las voces de los agentes con SSML.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 13 de 15. El futuro del servicio al cliente no es solo texto en una pantalla. La gente sigue llamando a las líneas de soporte y, cuando lo hace, espera una respuesta inmediata e inteligente en lugar de un árbol de menús interminable. Para superar esta brecha, necesitas conectar tu IA directamente a las redes de telefonía. De eso hablamos hoy: Voz e IVR.
Coger un agente creado en Copilot Studio y hacer que responda al teléfono implica configurarlo para un canal de telefonía, generalmente a través de Dynamics 365 o Azure Communication Services. Esto transforma tu lógica en un sistema de respuesta de voz interactiva, o IVR, apoyándose en el reconocimiento de voz nativo para convertir el audio de la llamada en texto, y en motores de text-to-speech para responder. Pero traducir la lógica de chat a lógica de voz requiere gestionar las realidades físicas de una llamada de teléfono.
Piensa en un cliente que llama a una línea de soporte. El bot responde y empieza a leer un saludo legal obligatorio o una lista de opciones. La persona que llama ya sabe que necesita el departamento de facturación. Si esto fuera un chat de texto, simplemente escribiría su pregunta. Por teléfono, habla por encima del bot. Esto requiere una funcionalidad llamada Barge-in. Sin el Barge-in activado, el sistema ignora el audio entrante hasta que el bot termina completamente su reproducción. Con el Barge-in activo, el reconocedor de voz escucha de forma simultánea. En el momento en que detecta que el usuario está hablando, detiene al instante el output de text-to-speech del bot y procesa el audio entrante. Esto replica el flujo natural de la conversación humana y evita que quienes llaman se sientan atrapados por una máquina.
Después de interrumpir al bot, se le pide a la persona que llama un número de cuenta. Podría decir los números en voz alta, pero a lo mejor está en una habitación llena de gente. En su lugar, teclea los números en su pantalla. Esto nos lleva al DTMF, o Dual-Tone Multi-Frequency. La gente suele confundir el manejo de DTMF con los inputs de texto estándar, pero son mecanismos totalmente distintos. El DTMF gestiona las interacciones del teclado del teléfono a nivel global en toda la red de telefonía. Cuando una persona que llama pulsa una tecla, la red envía un tono de frecuencia específica. Copilot Studio captura estos tonos directamente. Tú configuras nodos de input para que escuchen secuencias DTMF, extraigan los dígitos resultantes y los guarden como variables. Puedes forzar un número máximo de dígitos, configurar timeouts y definir un carácter de terminación, como por ejemplo indicarle al usuario que pulse la tecla almohadilla cuando termine de teclear.
Aquí está la clave. Solo capturar el input no es suficiente; la forma en que tu agente responde determina si la persona que llama cuelga. El text-to-speech por defecto puede sonar plano. Para solucionar esto, usas SSML, o Speech Synthesis Markup Language. En lugar de enviar texto plano al motor de voz, envuelves tus respuestas en etiquetas de markup. SSML te permite controlar el pitch, ajustar la velocidad del habla y forzar pronunciaciones específicas. Si el nombre de tu empresa es un acrónimo, puedes usar SSML para forzar al motor a leerlo letra por letra en lugar de adivinar cómo suena como palabra. Puedes insertar silencios precisos, añadiendo una pausa de medio segundo después de una instrucción compleja para que la persona que llama procese la información.
Desarrollar para voz requiere tratar la línea de teléfono como una interfaz única, teniendo en cuenta las interrupciones, los tonos del teclado y el ritmo del audio. Los agentes de voz más efectivos no obligan a los usuarios a usar menús de audio rígidos; combinan un Barge-in fluido y un manejo preciso del DTMF para, simplemente, apartarse del camino de la persona que llama. Gracias por escuchar. ¡Hasta la próxima!
14
Agent Analytics
3m 13sNo puedes mejorar lo que no mides. Este episodio desglosa el panel de Analytics en Copilot Studio, explicando la vista híbrida para sesiones conversacionales frente a autónomas, y cómo exportar transcripciones para un análisis profundo.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 14 de 15. Por fin haces deploy de tu agente, lo pruebas tú mismo y todo parece perfecto. Una semana después, la satisfacción del usuario cae y los procesos en background fallan en silencio. El problema no es tu build inicial, es tu falta de visibilidad del comportamiento en producción. La herramienta para solucionarlo es Agent Analytics.
Agent Analytics proporciona una visión unificada de cómo rinde tu agente una vez que gestiona workloads reales. Lo primero que ves es la página de Summary. Esta funciona como centro de control. Recopila KPIs como el total de sesiones, el engagement rate, el resolution rate y el escalation rate. En lugar de adivinar si tu agente está ayudando a los usuarios, los AI insights del Summary analizan el intent del usuario y te muestran exactamente qué topics están logrando resoluciones exitosas y cuáles hacen que los usuarios abandonen la sesión o pidan un humano.
Aquí está la clave. Copilot Studio hace tracking de dos tipos de sesiones fundamentalmente distintos, y el dashboard las presenta en una vista híbrida. Primero, tienes las sesiones conversacionales. Son exactamente lo que parecen. Un usuario abre una ventana de chat y habla con el agente. Las analytics registran los turnos de diálogo, el sentimiento del usuario y el triggering de los topics. Segundo, tienes las sesiones autónomas. Estas se ejecutan completamente en background. Se disparan por eventos externos, como la creación de un nuevo record en una base de datos o un email entrante, no porque un usuario escriba un mensaje. No hay interfaz de chat. Las analytics registran si el agente completó con éxito su lógica en background o si dio un error.
Necesitas ambas vistas para mantener a un agente sano. Imagina un escenario en el que estás revisando este dashboard híbrido. Tus métricas conversacionales parecen estar bien, pero notas un pico repentino en las tasas de fallo. Al filtrar por tipo de sesión, ves que todos los errores están ocurriendo en las sesiones autónomas. Un proceso disparado por un evento, que se supone que actualiza los estados de los pedidos, está fallando en background. El dashboard de Summary te dice que hay un fallo, pero no te dice la línea exacta de lógica que lo causó.
Aquí es donde pasas del dashboard a la raw data. Copilot Studio almacena logs de ejecución detallados en Microsoft Dataverse como transcripts. Descargas el transcript específico de la sesión autónoma fallida. Leer el transcript te da el trace paso a paso de la ejecución. Puedes ver la variable exacta que pasó un valor inválido, localizar el node que está fallando y arreglar la lógica sin tener que recrear el error a ciegas.
El dashboard te dice dónde mirar, pero el transcript te dice qué arreglar. Si quieres ayudar a que sigamos haciendo estos breakdowns técnicos, puedes apoyar el programa buscando DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y a seguir desarrollando!
15
Model Context Protocol
4m 00sPrepara a tus agentes para el futuro con el estándar abierto para el contexto de IA. Aprende a integrar Copilot Studio con servidores externos de Model Context Protocol (MCP) para ingerir Resources, Tools y Prompts de forma dinámica.
Hola, soy Alex de DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 15 de 15. Pasas semanas creando plugins personalizados para que tu agente consulte tus bases de datos internas y lance acciones. Luego se lanza una nueva plataforma y te encuentras reescribiendo todas esas mismas integraciones desde cero. La solución a este ciclo interminable de trabajo redundante es el Model Context Protocol.
El Model Context Protocol, o MCP, es un estándar abierto que conecta modelos de IA con fuentes de datos y tools externas. Al adoptar un estándar abierto, garantizas la compatibilidad futura de tus agentes. Escribes la lógica de integración una sola vez, la alojas en un servidor MCP y cualquier cliente de IA compatible puede usarla al instante. Copilot Studio actúa como uno de estos clientes.
Imagina un escenario en el que tu equipo de ingeniería depende de 50 scripts de diagnóstico internos diferentes y archivos de log en tiempo real. No quieres crear y mapear manualmente 50 acciones distintas dentro de Copilot Studio. En su lugar, configuras tu agente para que se conecte directamente a tu propio servidor MCP interno. Cuando el agente se inicializa, le pregunta al servidor qué puede hacer. El servidor responde con una lista de capacidades, otorgándole inmediatamente al agente acceso a las 50 tools de ingeniería y a los resources de archivos en vivo.
Un servidor MCP expone tres componentes principales a tu agente. Estos son Resources, Tools y Prompts. Los Resources son fuentes de datos de solo lectura. Cuando tu agente necesita consultar un archivo de configuración en vivo o un registro de base de datos, el servidor MCP proporciona esos datos como un resource, cargándolos directamente en el contexto del modelo. Las Tools son funciones ejecutables. Si el agente decide que necesita reiniciar una máquina virtual o actualizar un ticket de ingeniería, llama a la tool de MCP correspondiente, y el servidor externo ejecuta la acción. Los Prompts son plantillas de instrucciones predefinidas proporcionadas por el servidor. Guían al agente exactamente sobre cómo formatear las queries o interpretar los datos específicos de ese sistema externo.
Aquí está la clave. La gente suele asumir que, cuando conectas un servidor MCP, Copilot Studio importa y guarda copias permanentes de esas tools en su propia interfaz de usuario. Pero no funciona así. Las tools y los resources se alojan de forma completamente externa. Copilot Studio lee dinámicamente lo que el servidor expone en runtime. Si tu equipo de ingeniería añade una tool de diagnóstico número cincuenta y uno, o modifica los parámetros de un script existente, simplemente actualizan el servidor MCP externo. Copilot Studio refleja automáticamente esos cambios. Nunca tienes que hacer login en la interfaz de Studio para republicar o actualizar la acción.
Como la lógica vive completamente en el servidor, mantienes una única fuente de verdad para los datos y acciones de tu organización. El agente sigue siendo ligero, funcionando simplemente como el motor de razonamiento que decide cuándo comunicarse con el servidor.
Al separar tus tools de la plataforma específica del agente, centralizas tus integraciones y garantizas que tu IA siempre tenga las últimas capacidades, independientemente de la interfaz de cliente en la que hagas deploy. Te animo encarecidamente a que leas la documentación oficial, pruebes a conectar un servidor MCP tú mismo, o visites devstories dot eu para sugerir temas que te gustaría ver en una futura serie. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue creando!