# Guía avanzada: Agentes con Copilot Studio + Power Automate + Power Apps > De cero a agente productivo. Explicado como si no supieras nada, pero sin subestimarte. > Data actualizada a 2026 (orquestación generativa, Copilot Credits, deprecación del control clásico en Canvas Apps). --- ## Índice 0. [Antes de arrancar: el mapa mental](#0-antes-de-arrancar-el-mapa-mental) 1. [Qué es Copilot Studio (y qué NO es)](#1-qué-es-copilot-studio-y-qué-no-es) 2. [Anatomía de un agente](#2-anatomía-de-un-agente) 3. [El cambio de paradigma 2025–2026](#3-el-cambio-de-paradigma-20252026) 4. [Requisitos, entornos y licenciamiento (leelo antes de gastar plata)](#4-requisitos-entornos-y-licenciamiento) 5. [Caso 1 — Tu primer agente: FAQ / Helpdesk](#5-caso-1--tu-primer-agente-faq--helpdesk) 6. [Knowledge: darle cerebro al agente](#6-knowledge-darle-cerebro-al-agente) 7. [Actions y Tools: darle manos al agente](#7-actions-y-tools-darle-manos-al-agente) 8. [Power Automate a fondo: el músculo](#8-power-automate-a-fondo-el-músculo) 9. [Triggers y agentes autónomos](#9-triggers-y-agentes-autónomos) 10. [Multi-agente y MCP](#10-multi-agente-y-mcp) 11. [Conectar con Power Apps (la parte que cambió)](#11-conectar-con-power-apps-la-parte-que-cambió) 12. [Copilot Studio vs. el resto del mundo: AWS, OpenAI, Anthropic, Google](#12-copilot-studio-vs-el-resto-del-mundo-aws-openai-anthropic-google) 13. [Casos de uso end-to-end](#13-casos-de-uso-end-to-end) 14. [Testing, canales y publicación](#14-testing-canales-y-publicación) 15. [Governance, seguridad y ALM](#15-governance-seguridad-y-alm) 16. [Buenas prácticas y errores comunes](#16-buenas-prácticas-y-errores-comunes) 17. [Ruta de aprendizaje y recursos](#17-ruta-de-aprendizaje-y-recursos) --- ## 0. Antes de arrancar: el mapa mental Copilot Studio no vive solo. Es una pieza dentro de **Power Platform**, la suite low-code de Microsoft. Pensalo como cuatro herramientas que se combinan: | Herramienta | Qué hace | Analogía | |---|---|---| | **Power Apps** | Construir aplicaciones (formularios, pantallas, CRUD) | La cara / la UI | | **Power Automate** | Automatizar procesos y flujos entre sistemas | Los músculos y tendones | | **Copilot Studio** | Construir agentes conversacionales/autónomos con IA | El cerebro que conversa y decide | | **Dataverse** | Base de datos gestionada donde vive todo | La memoria persistente | La pega de todo esto es **Dataverse** (base de datos relacional en la nube) y los **connectors** (~1000 conectores a servicios: SQL, SharePoint, Outlook, HTTP, Azure, SAP, etc.). Todo lo que armes se apoya en esos dos cimientos. **El objetivo de esta guía**: que puedas armar un agente que conversa, que ejecuta acciones reales (vía flows y connectors), y que además lo puedas embeber dentro de una Power App para tus usuarios internos. --- ## 1. Qué es Copilot Studio (y qué NO es) **Qué es:** una plataforma low-code para construir *agentes de IA*. Un agente es un programa que: - entiende lenguaje natural (le hablás en criollo), - razona sobre qué hacer, - consulta fuentes de conocimiento (documentos, bases, web), - ejecuta acciones (mandar un mail, crear un ticket, prender una VM), - y puede operar tanto **reactivo** (te contesta cuando le hablás) como **autónomo** (actúa solo cuando pasa algo). **Un poco de historia (para ubicarte):** esto antes se llamaba **Power Virtual Agents (PVA)**. Era un armador de chatbots por "topics" (temas con frases de disparo). Microsoft lo renombró a Copilot Studio y le metió LLMs adentro. Si buscás tutoriales viejos que hablan de "PVA" o de armar todo con topics, es el mismo producto pero **la forma recomendada de trabajar cambió** (ver sección 3). **Qué NO es:** - No es ChatGPT/Claude a secas. Es un *framework para construir* tus propios asistentes anclados a los datos de tu empresa. - No es programación tradicional. Es low-code: mucho se hace con clicks, aunque los casos serios requieren entender flows, expresiones y a veces código. - No reemplaza a Power Automate ni a Power Apps: los **usa**. --- ## 2. Anatomía de un agente Un agente en Copilot Studio se compone de estos bloques. Metételos en la cabeza porque son el vocabulario de todo lo que sigue: ### 2.1 Instructions (instrucciones) Es el "system prompt" del agente: en lenguaje natural le decís quién es, qué hace, cómo se comporta, qué tono usa, qué NO debe hacer. En el modelo nuevo (orquestación generativa) las instrucciones son **el timón principal**. Bien escritas > mil topics. ### 2.2 Knowledge (conocimiento) Las fuentes de donde el agente saca información para responder: sitios de SharePoint, tablas de Dataverse, archivos, sitios web públicos, o conectores a sistemas externos. Es lo que lo ancla a *tu* realidad y evita que invente. ### 2.3 Topics (temas) Diálogos pre-armados con un flujo definido (nodos: mensaje, pregunta, condición, acción). En el mundo clásico eran el centro de todo. Hoy siguen existiendo pero para **flujos deterministas** donde querés control total (ej: un proceso de onboarding con pasos fijos). ### 2.4 Tools / Actions (herramientas / acciones) Lo que le da capacidad de *hacer* cosas fuera de la conversación: - **Connectors** (conectores prefabricados a servicios), - **Power Automate flows** (flujos custom), - **REST APIs** directas, - **Prompts / AI Builder** (acciones de IA como clasificar o extraer), - **MCP servers** (herramientas expuestas por el Model Context Protocol). ### 2.5 Triggers (disparadores) Qué hace arrancar al agente. Puede ser un mensaje del usuario, o —en agentes autónomos— un evento: llega un mail, se crea un registro, cambia algo en una tabla, corre un schedule. ### 2.6 Orchestrator (orquestador) El "director de orquesta". Cuando llega un pedido, decide qué combinación de topics, knowledge, tools y sub-agentes usar, en qué orden, y arma la respuesta. En el modelo generativo, esto lo maneja un LLM (ver sección 3). ### 2.7 Guardrails (barandas) Límites y controles: qué acciones requieren aprobación humana, qué temas evitar, moderación de contenido, límites de autonomía. Fundamental cuando el agente puede *actuar* sobre sistemas reales. ``` ┌─────────────────────────────────────────────┐ │ AGENTE │ │ │ │ Instructions ──► define comportamiento │ │ │ │ Usuario/Evento │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ ORCHESTRATOR │ ◄── decide qué usar │ │ └─────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ Topics Knowledge Tools/Actions │ │ │ │ │ ▼ │ │ (flows, APIs, MCP) │ │ │ │ │ ▼ │ │ Guardrails ──► respuesta/acción │ └─────────────────────────────────────────────┘ ``` --- ## 3. El cambio de paradigma 2025–2026 Esto es lo más importante de entender para no aprender algo que ya es viejo. ### 3.1 De "topic routing" a orquestación generativa **Antes (clásico):** vos armabas decenas de topics, cada uno con "trigger phrases" (frases que lo disparaban). Si el usuario escribía algo que no matcheaba ninguna frase, el bot se quedaba mudo o mandaba un fallback. Era rígido, artesanal, y se te iba de las manos con 40+ topics. **Ahora (orquestación generativa, GA):** un LLM interpreta la intención del usuario, descompone pedidos complejos, elige las tools/knowledge/topics/sub-agentes correctos, y ejecuta un plan multi-paso con guardrails. Ya no tenés que anticipar cada frase posible ni ramificar todo a mano. Lo prendés desde la página del agente (Settings → Generative AI) y a partir de ahí las **instrucciones** y las **descripciones** de cada tool pasan a ser lo que guía al orquestador. > **Regla de oro nueva:** el orquestador elige tools por su *descripción*. Una tool con descripción pobre no la usa nunca. Escribí descripciones como si se las explicaras a alguien que no la conoce: qué hace, cuándo usarla, qué inputs necesita. ### 3.2 Agentes autónomos y triggers Los agentes ya no sólo responden en un chat. Con **triggers autónomos** actúan solos cuando se cumple una condición: monitorean datos, reaccionan a eventos, corren workflows en background. Ejemplo: un agente de operaciones que detecta un problema de stock por señales predefinidas, actualiza el sistema de registro, y abre un ticket de remediación — sin que nadie le hable. ### 3.3 Multi-agente y A2A En vez de un mega-agente monolítico que hace todo, la tendencia es **agentes especializados** (uno de RRHH, uno de IT, uno de compras) coordinados por un orquestador padre que delega en el más apto. La comunicación agente-a-agente usa el protocolo **A2A** (en preview). Esto escala mucho mejor y es más mantenible. ### 3.4 MCP (Model Context Protocol) Copilot Studio soporta **MCP**: podés conectar servidores MCP que exponen tools y knowledge, y automáticamente traen sus acciones (nombres, inputs, outputs, descripciones) al agente. Si ya venís jugando con MCP en otros lados, esto te va a resultar familiar: es la forma estándar de enchufar herramientas y datos externos sin picar un connector custom por cada API. ### 3.5 Computer use Para sistemas legacy sin API, hay capacidades de **computer use**: el agente puede operar apps web/desktop "clickeando" y llenando campos como lo haría una persona. Útil cuando no hay connector ni API disponible. (Ojo: caro en créditos y más frágil que una integración por API — usalo como último recurso.) ### 3.6 Nuevo orquestador (2026) Microsoft actualizó el stack: el orquestador nuevo mejora precisión y reduce tokens (mejoras de ~20% en performance de evaluación y ~50% menos consumo neto de tokens según Microsoft). Traducción: agentes más confiables y más baratos de correr, si están bien armados. --- ## 4. Requisitos, entornos y licenciamiento ### 4.1 Qué necesitás para arrancar - Una cuenta de trabajo/escuela de Microsoft 365 (no sirve una personal @outlook). - Acceso a un **entorno** de Power Platform con Dataverse habilitado. - Permisos de maker en ese entorno. - Para probar sin costo: hay trial de Copilot Studio. ### 4.2 Entornos (environments) — concepto clave de ALM Un "environment" es un contenedor aislado con su propia Dataverse, seguridad y datos. La práctica sana es tener al menos: - **DEV** (desarrollás), - **TEST/UAT** (probás), - **PROD** (usuarios reales). Movés soluciones entre entornos con **Solutions** (paquetes exportables). Nunca desarrolles directo en PROD. ### 4.3 Licenciamiento: Copilot Credits (esto CAMBIÓ) Desde el 1/9/2025, la moneda de consumo dejó de llamarse "messages" y pasó a llamarse **Copilot Credits** (mismo mecanismo, otro nombre). Hay tres/cuatro formas de pagar: | Vía | Precio | Cuándo conviene | |---|---|---| | **Incluido con M365 Copilot** | Sin costo extra de créditos para agentes internos usados por usuarios ya licenciados con M365 Copilot | Agentes internos, usuarios ya licenciados | | **Capacity pack (prepago)** | ~USD 200/mes por 25.000 créditos (~USD 0,008/crédito con compromiso anual) | Volumen estable y predecible | | **Pay-as-you-go (PAYG)** | ~USD 0,01/crédito, facturado vía Azure, sin compromiso | Pilotos, demanda irregular | **Lo que te tiene que quedar clarísimo:** el crédito es el átomo de facturación, y **el consumo varía hasta 100x según cómo armes el agente**. Referencia aproximada de consumo por interacción: | Tipo de interacción | Créditos aprox. | |---|---| | Respuesta clásica (topic scripteado) | ~1 | | Respuesta generativa | ~2 | | Grounding sobre el grafo del tenant | ~10 | | Acción de agente autónomo | 25+ | | Respuesta con modelo de razonamiento | ~100 | > **Trap de compliance frecuente:** si prendés **Managed Environments** (y Copilot Studio te empuja a hacerlo para cualquier deployment no trivial), cada usuario activo de ese entorno debe estar cubierto por licencia standalone o meter PAYG. Los derechos limitados de Power Platform que vienen con D365 o M365 **no alcanzan**. Ojo con esto al presupuestar. **Consejo de arranque:** para un piloto, andá con **PAYG**, medí el consumo real por interacción, y recién cuando tengas volumen estable pasate a packs. Poné un dueño del presupuesto de créditos y revisá consumo semanalmente el primer trimestre — ahí es cuando aparecen los "shadow agents" y el feature creep. --- ## 5. Caso 1 — Tu primer agente: FAQ / Helpdesk Vamos a lo concreto. Objetivo: un agente que responde preguntas frecuentes de IT interno (políticas de VPN, cómo pedir un acceso, horarios de mantenimiento) leyendo de tus documentos de SharePoint. **Paso a paso:** 1. **Entrá a Copilot Studio** (`copilotstudio.microsoft.com`), seleccioná el entorno DEV arriba a la derecha. 2. **Create → New agent.** Le podés describir en lenguaje natural qué querés y te lo pre-configura, o ir a "Skip to configure" para armarlo a mano. 3. **Poné nombre e instrucciones.** Ejemplo de instrucciones: ``` Sos el asistente de IT interno de la empresa. Respondés dudas sobre políticas, accesos y servicios de IT usando únicamente la información de las fuentes de conocimiento conectadas. Si no encontrás la respuesta, decilo claramente y ofrecé abrir un ticket. Tono profesional y directo, en español rioplatense. Nunca inventes políticas. ``` 4. **Agregá Knowledge:** conectá el sitio de SharePoint donde viven tus documentos de IT. (Detalle en sección 6.) 5. **Prendé orquestación generativa** (Settings → Generative AI → Orchestration: Generative). 6. **Probá en el Test panel** (panel de la derecha). Hacele preguntas reales y mirá si responde bien y de dónde saca la data. 7. **Iterá las instrucciones** hasta que el tono y el comportamiento sean los que querés. 8. **Publicá** (Publish) para que quede disponible en los canales. Con esto ya tenés un agente conversacional anclado a tus docs. Lo que sigue es darle **manos** (acciones) y **proactividad** (triggers). --- ## 6. Knowledge: darle cerebro al agente Las fuentes de conocimiento posibles: | Fuente | Uso típico | |---|---| | **SharePoint** | Documentos, políticas, manuales (lo más común) | | **Dataverse** | Datos estructurados de la empresa (tickets, clientes, inventario) | | **Sitios web públicos** | Documentación pública, KB externas | | **Archivos subidos** | PDFs, Word, etc. cargados directo | | **Connectors / Enterprise data** | SQL, sistemas de línea de negocio | | **MCP knowledge servers** | Conocimiento expuesto por MCP | **Conceptos importantes:** - **Grounding:** el agente "ancla" sus respuestas en estas fuentes en vez de inventar. Es lo que baja las alucinaciones. - **RAG bajo el capó:** Copilot Studio hace retrieval sobre tus fuentes y le pasa los fragmentos relevantes al LLM. Vos no gestionás el vector store, lo hace la plataforma. - **Permisos:** el agente respeta (o no) los permisos de la fuente según cómo lo configures. Cuidado con exponer docs sensibles a usuarios que no deberían verlos. **Tip de calidad:** documentos bien estructurados (títulos claros, secciones, sin PDFs escaneados como imagen) dan respuestas mucho mejores. Basura entra, basura sale. --- ## 7. Actions y Tools: darle manos al agente Acá el agente deja de solo *hablar* y empieza a *hacer*. Formas de agregar acciones: ### 7.1 Connectors prefabricados Miles de conectores listos: mandar mail (Outlook), crear ítem (SharePoint), postear (Teams), consultar (SQL Server), etc. Los agregás como tool, mapeás inputs/outputs, y listo. ### 7.2 Power Automate flows (lo más potente para lógica custom) Cuando necesitás lógica que un connector solo no cubre —varios pasos, condiciones, transformaciones—, armás un **flow** y lo exponés como tool del agente. Es el caballito de batalla. Ver sección 8. ### 7.3 REST APIs directas / custom connectors Si tenés una API propia (por ejemplo, tu propio backend de inventario), la enchufás vía custom connector o llamada HTTP. ### 7.4 Prompts / AI Builder Acciones de IA reutilizables: clasificar un texto, extraer entidades, generar contenido, resumir. Se incorporan directo al workflow del agente. ### 7.5 MCP tools Si tenés un servidor MCP, sus tools aparecen automáticamente con sus descripciones, inputs y outputs. Ideal si ya estandarizaste herramientas por MCP. > **Recordá la regla del orquestador:** cada tool se elige por su **descripción**. Invertí tiempo en describir bien cada acción: qué hace, cuándo usarla, qué necesita. Es literalmente lo que hace que el LLM la invoque o la ignore. --- ## 8. Power Automate a fondo: el músculo Power Automate es donde armás los flujos que el agente va a ejecutar. Entenderlo bien es lo que separa un chatbot de juguete de un agente que trabaja. ### 8.1 Anatomía de un flow - **Trigger:** qué lo dispara. Para agentes, típicamente "cuando Copilot Studio llama a este flow" (manual/instant) o eventos. - **Inputs:** parámetros que el agente le pasa (ej: el ID de usuario, el texto del pedido). - **Actions/Steps:** los pasos (llamar una API, escribir en una tabla, condicionales, loops). - **Outputs:** lo que devuelve al agente (ej: "ticket creado con ID 12345"). ### 8.2 Tipos de flows relevantes | Tipo | Disparo | Uso con agentes | |---|---|---| | **Instant / manual** | Llamado on-demand | El agente lo invoca como tool ✅ | | **Automated** | Evento (mail, registro nuevo) | Para agentes autónomos | | **Scheduled** | Reloj (cada X tiempo) | Tareas periódicas | | **Agent flows** | Diseñados para ser orquestados por agentes | El sabor nuevo, con nodos de IA embebidos | ### 8.3 Agent flows (lo nuevo) Los **agent flows** combinan orquestación determinista (pasos fijos, donde querés control) con ejecución adaptativa (donde el LLM decide). Podés meter dentro del flow **acciones de IA** como clasificación, generación de contenido y soporte a decisiones. Esto te da lo mejor de los dos mundos: estructura donde la necesitás, flexibilidad donde suma valor. ### 8.4 Cómo se conecta un flow a un agente (paso a paso) 1. En Copilot Studio, dentro del agente, andá a **Tools → Add a tool → New → Power Automate flow** (o creá el flow aparte y después lo agregás). 2. Se abre el diseñador de Power Automate con un trigger tipo "Run a flow from Copilot". 3. Definí los **inputs** que el agente le va a pasar (ej: `usuarioEmail`, `descripcionProblema`). 4. Armá los pasos: por ejemplo, crear un registro en Dataverse + mandar un mail de confirmación. 5. Definí el **output** con "Respond to Copilot" (ej: `ticketId`, `mensaje`). 6. Guardá. Volvé al agente: la tool ya está disponible. 7. **Escribí una buena descripción de la tool** y de cada input (para que el orquestador sepa cuándo usarla y qué pedir). 8. Probá en el Test panel: pedile algo que dispare el flow y verificá que corra e informe bien. ### 8.5 Expresiones (el "código" del low-code) Power Automate usa un lenguaje de expresiones (WDL - Workflow Definition Language). Vas a usar seguido: - `triggerBody()` / `outputs()` para leer datos de pasos previos, - `concat()`, `if()`, `formatDateTime()`, `first()`, `length()`, - `parseJSON()` cuando una API te devuelve JSON crudo. No hace falta que las memorices todas, pero saber que existen y buscarlas te destraba el 90% de los casos. --- ## 9. Triggers y agentes autónomos Acá el agente pasa de reactivo a proactivo. ### 9.1 Tipos de triggers - **Conversacional:** el usuario le escribe (chat). - **Evento externo:** llega un mail, se crea/modifica un registro en Dataverse, un webhook. - **Schedule:** corre cada tanto (ej: todos los días a las 8am revisa algo). - **Topic triggers (orquestación generativa):** enganchan el ciclo de vida del agente para inyectar lógica custom en puntos críticos del proceso de orquestación. ### 9.2 Cómo pensar un agente autónomo Un agente autónomo necesita 3 cosas bien definidas: 1. **Trigger** (qué evento lo despierta), 2. **Instructions** (qué debe hacer cuando se despierta), 3. **Guardrails** (hasta dónde puede actuar solo, qué requiere aprobación humana). ### 9.3 Ejemplo mental (operaciones/infra) > **Trigger:** llega una alerta de monitoreo a una cola/tabla. > **El agente:** clasifica la severidad, busca en la KB si hay un runbook conocido, y —si es de bajo riesgo— ejecuta la remediación vía flow (ej: reiniciar un servicio). Si es de alto impacto, abre un ticket y notifica a un humano para aprobación. > **Guardrail:** acciones destructivas (reiniciar prod, borrar) siempre requieren aprobación humana explícita. Este patrón —bajo riesgo automático, alto impacto con aprobación— es el que te mantiene seguro. El **agent feed** en Power Apps (GA mayo 2026) te da un lugar dedicado para revisar y aprobar la actividad del agente: las acciones de bajo riesgo se completan solas en background, y las de alto impacto (como mandar un mail) aparecen como aprobaciones explícitas. --- ## 10. Multi-agente y MCP ### 10.1 Patrón multi-agente En vez de un agente que hace todo, armás varios especializados y uno orquestador que delega: ``` ┌────────────────────┐ │ Agente orquestador │ └─────────┬──────────┘ ┌───────────┼───────────┐ ▼ ▼ ▼ Agente IT Agente RRHH Agente Compras (accesos) (licencias) (pedidos) ``` El orquestador recibe el pedido, entiende de qué se trata, y lo deriva al sub-agente correcto. Cada sub-agente tiene sus propias tools, knowledge e instructions. Ventajas: más mantenible, testeable por partes, y cada equipo puede ser dueño de su agente. ### 10.2 A2A (Agent-to-Agent) El protocolo que permite que agentes se hablen y se pasen contexto (en preview). Es lo que hace posible la coordinación real entre agentes de distintos dominios o incluso de distintas plataformas. ### 10.3 MCP en la práctica Si exponés tus herramientas internas como un **servidor MCP**, Copilot Studio las importa con sus descripciones, inputs y outputs automáticamente. Ventaja para vos: una sola definición de tool que podés reusar en Copilot Studio, en Claude, o en cualquier cliente MCP, sin re-picar el connector cada vez. Es la forma más limpia y a prueba de futuro de enchufar herramientas propias. --- ## 11. Conectar con Power Apps (la parte que cambió) ⚠️ **Atención: esto se movió fuerte en 2026.** No sigas tutoriales viejos que te dicen "arrastrá el control Copilot al canvas", porque ese control quedó deprecado. ### 11.1 Qué pasó El **control Copilot embebido nativo para Canvas Apps quedó deprecado el 2 de febrero de 2026**: ya **no se puede agregar a apps nuevas**. Las apps existentes que ya lo usan siguen funcionando por un tiempo limitado, pero eventualmente dejan de estar soportadas. Microsoft recomienda migrar. ### 11.2 Las opciones vigentes hoy | Opción | Qué es | Cuándo usarla | |---|---|---| | **Microsoft 365 Copilot in canvas apps** | El reemplazo oficial recomendado por Microsoft. GA en model-driven apps, preview en canvas (según tu entorno) | Si querés lo soportado nativo y ya está disponible en tu tenant | | **PCF ChatControl** | Componente PCF (Power Apps Component Framework) del repo oficial *Copilot Studio Samples*. Usa Bot Framework WebChat con tema Fluent UI | Si necesitás embeber TU agente hoy y pasarle contexto de la app | | **iframe / HTML** | Embeber el web chat del agente vía código de embed (Channels → Web) en un control HTML | Workaround simple, menos integrado | ### 11.3 Vía recomendada para embeber tu agente hoy: PCF ChatControl Como el control nativo murió y M365 Copilot in canvas todavía no está en todos lados, el camino práctico para meter *tu* agente de Copilot Studio en una Canvas App **y pasarle contexto** es el componente **ChatControl** del repo de samples. Pasos generales: 1. **App registration en Azure:** registrás una app y anotás `client ID` y `tenant ID`. 2. **Importás el PCF** como solución de Power Platform en tu entorno (hay que subir el límite de tamaño de import de soluciones, viene en la guía del repo). 3. **Agregás el control** a tu Canvas App como cualquier otro componente. 4. **Configurás las propiedades:** `client ID`, `tenant ID`, `environment ID`, y el `agent identifier` (el GUID/schema name de tu agente publicado — lo sacás de Settings/Channels del agente). 5. **Corrés y probás (F5).** ### 11.4 Pasar variables/contexto de la app al agente Un caso clásico: querés que la app le diga al agente "el usuario está mirando el cliente X" o "el industry seleccionado es Y". - En el agente, definís una **variable global** con "External sources can set values" en **ON**. - Con el PCF/WebChat podés mandar eventos de startup o runtime al agente (por eso el PCF es más apto que el iframe para pasar contexto). - Limitación a tener en cuenta: pasar la variable como query string tiene sus bordes, y actualizar la variable a mitad de sesión a veces requiere reiniciar la conversación. Planificá el flujo de contexto de entrada, no asumas que podés cambiarlo libremente mid-session. ### 11.5 El camino inverso: la app dentro del agente Ojo que también existe la dirección contraria y cada vez más integrada: **app skills** (data entry, exploración, visualización, summarization) que infunden capacidades de la app dentro del agente, y el **agent feed con Power Apps MCP Server** (GA 4 de mayo de 2026) para supervisar la actividad del agente desde adentro de la app de negocio. O sea: no solo metés el agente en la app; también metés la app (y su contexto real) en el agente. --- ## 12. Copilot Studio vs. el resto del mundo: AWS, OpenAI, Anthropic, Google La buena noticia: **toda la industria convergió en el mismo modelo mental de agente.** Un agente, en cualquier plataforma, es más o menos lo mismo: > **instrucciones (system prompt) + modelo + knowledge/RAG + tools/acciones + memoria + guardrails + un orquestador que planifica.** Lo que cambia entre Microsoft, AWS, OpenAI, Anthropic y Google es el **empaque** y el **usuario al que apuntan**: unos priorizan low-code para gente de negocio, otros priorizan código/API para developers. Una vez que entendés Copilot Studio, entendés a todos: solo cambian los nombres. ### 12.1 Mapa de equivalencias | Concepto en Copilot Studio | AWS | OpenAI | Anthropic | Google | |---|---|---|---|---| | **Plataforma estrella** | Amazon Bedrock **AgentCore** (+ Amazon Q para negocio) | **Responses API** + **Agents SDK** | **Claude Agent SDK** + **MCP** (+ Managed Agents) | **Gemini Enterprise Agent Platform** (ex Vertex AI) | | **Constructor low-code / visual** | Amazon Q Business | Agent Builder de AgentKit *(en retiro nov-2026)* | — (no hay studio low-code) | **Agent Studio** | | **Framework code-first** | Strands Agents SDK / LangGraph / CrewAI | **Agents SDK** (Python/TS) | **Claude Agent SDK** (Python/TS) | **ADK** (Agent Development Kit) | | **Agente = instrucciones** | System prompt + instrucciones | `Agent(instructions=…)` | System prompt del agente | Instrucciones del agente | | **Knowledge / RAG** | **Bedrock Knowledge Bases** | Built-in tools (file/vector search) | Vía MCP / retrieval propio | **Vertex AI Search** | | **Tools / acciones** | Action groups / Gateway | Function tools / built-in tools | Tools + **MCP** | Tools / function calling | | **Estándar de tools** | **MCP** (soportado) | **MCP** (en Responses API) | **MCP** (¡lo inventó Anthropic!) | **MCP** (managed MCP servers) | | **Orquestación de procesos** | Step Functions / Gateway | Workflows del SDK | Agent loop + hooks | Agent Studio / ADK | | **Multi-agente** | Multi-agent collaboration (supervisor + colaboradores) | **Handoffs** | **Subagents** | Multi-agente en ADK | | **Protocolo agente-a-agente** | **A2A** (nativo) | (handoffs internos) | (subagents / MCP) | **A2A** (¡lo creó Google!) | | **Runtime / hosting** | **AgentCore Runtime** (microVM) | Hosted / tu infra | Managed Agents / tu infra | **Agent Engine** | | **Memoria** | AgentCore Memory (corto/largo/episódica) | Sessions | Sessions / context mgmt | Memoria persistente | | **Guardrails** | Bedrock Guardrails + Policy (Cedar) | Guardrails del SDK | Permissions + hooks | Governance del platform | | **Apps legacy sin API** | Browser tool (AgentCore) | **Computer Use API** (Operator) | **Computer use** | **Project Mariner** | | **Asistente para empleados** | Amazon Q Business | Workspace Agents / Custom GPTs | Claude / Cowork | **Gemini Enterprise** (ex Agentspace) | | **Unidad de facturación** | Tokens + runtime + servicios | Tokens | Tokens (+ crédito Agent SDK) | Tokens + runtime + queries | | **Usuario objetivo** | Dev + infra (negocio con Q) | Developer / producto | Developer / producto | **Negocio + dev** (como MS) | ### 12.2 Perfil de cada uno (y a qué se parece) **AWS — Amazon Bedrock AgentCore + Amazon Q** 🟠 Es el equivalente "infra-first". AWS **separa lo que Microsoft junta**: para el usuario de negocio que quiere un helpdesk sobre sus documentos está **Amazon Q Business** (lo más parecido a tu agente FAQ de Copilot Studio); para el developer que arma agentes productivos está **Bedrock AgentCore**, que trae Runtime (microVMs), Memory (corto/largo plazo y episódica), Gateway, Identity, Knowledge Bases, Guardrails, Policy con Cedar, code interpreter, browser y observabilidad. Dato importante: los **Bedrock Agents originales pasaron a llamarse "Classic" y cierran a clientes nuevos el 30/7/2026** — AgentCore es el camino. Es model-agnostic (corre Claude, entre otros), tiene multi-agente (supervisor + colaboradores) y **A2A nativo**. Si tu data y tu infra ya viven en AWS, este es tu terreno natural. > **Analogía:** Copilot Studio ≈ Amazon Q Business (lado low-code) **+** Bedrock AgentCore (lado código/infra), juntos en un solo producto. **OpenAI — Responses API + Agents SDK** 🟢 Es el más "developer/API-first". El centro de gravedad es la **Responses API**, y arriba va el **Agents SDK** (Python/TS) con primitivas simples: Agents, **Handoffs** (multi-agente), Guardrails y Sessions. Sacaron **AgentKit** con un **Agent Builder** visual y **ChatKit** (UI embebible) — pero ojo: **el Agent Builder visual y Evals se están retirando (30/11/2026)**, así que el camino durable es el SDK por código. Para negocio están los **Custom GPTs / Workspace Agents** en ChatGPT. Tiene **Computer Use API** y soporta **MCP**. No trae de fábrica un motor de RAG sobre datos empresariales tan integrado como el grounding de Copilot Studio sobre SharePoint/Dataverse: eso lo cableás vos. > **Analogía:** es como tener solo el "motor" de Copilot Studio sin la suite ofimática ni el Dataverse alrededor. Máxima flexibilidad, más plomería a tu cargo. **Anthropic — MCP + Claude Agent SDK + Skills** 🟣 Es el jugador de **"bloques y estándares"**. Anthropic **inventó MCP**, el estándar de conexión de herramientas que hoy usan los otros cuatro. El **Claude Agent SDK** (renombrado desde "Claude Code SDK" en sept-2025) trae el agent loop, tools (built-in + MCP), **subagents**, hooks, sessions y permisos — el mismo harness que mueve Claude Code. Y los **Agent Skills** (archivos `SKILL.md`) empaquetan *conocimiento procedimental* (el "cómo se hace bien" una tarea), complementarios a MCP (que da *capacidades*). También hay **Managed Agents** (hosteados por Anthropic) vs. SDK (lo hosteás vos), y **computer use**. No tiene un studio low-code al estilo Microsoft: las superficies para usuario final son Claude.ai / Desktop / Cowork. > **Analogía:** las **instrucciones + tools** de Copilot Studio son, en el mundo Anthropic, el **system prompt + MCP tools + Skills**. Mismo concepto, empaquetado como framework para devs. **Google — Gemini Enterprise Agent Platform** 🔵 Es **el competidor más cara-a-cara del stack de Microsoft**. En Cloud Next 2026 (22/4/2026) Google renombró Vertex AI a **Gemini Enterprise Agent Platform** y absorbió Agentspace dentro de **Gemini Enterprise** (el asistente para empleados, ≈ Microsoft 365 Copilot). Trae dos constructores como Microsoft: **Agent Studio** (low-code visual, ≈ Copilot Studio) y **ADK** (code-first, model-agnostic). Suma **Agent Engine** (runtime gestionado), **Model Garden** con 200+ modelos (incluido Claude), **Vertex AI Search** para RAG, **A2A** (que Google creó, ya en producción), managed MCP servers con Apigee de puente API-a-agente, y **Project Mariner** para navegar la web (computer use). > **Analogía:** es el espejo casi exacto de Microsoft: bundle low-code + código + governance + asistente de empleados. Si Microsoft = M365/SharePoint/Dataverse, Google = Workspace/Drive/BigQuery. ### 12.3 La lectura estratégica (lo que te tenés que llevar) - **Todos convergieron en el mismo modelo de agente.** Aprender uno te da el 80% de los otros. Lo que cambia es empaque y usuario objetivo. - **MCP ganó como estándar de tools.** Lo creó Anthropic y hoy lo soportan Microsoft, AWS, OpenAI y Google. Traducción práctica: **una tool que exponés por MCP la enchufás en Copilot Studio, Bedrock, Gemini y Claude sin reescribirla.** "Escribí una vez, usá en todos lados." - **A2A ganó como estándar agente-a-agente.** Lo empujó Google, ya es nativo en AgentCore y está en preview en Copilot Studio. Agentes de distintas plataformas van a poder hablarse entre sí. - **El lock-in se corrió del runtime a los datos y la ofimática.** El agente es casi commodity; lo que te ata es dónde viven tus datos y tus usuarios. Copilot Studio brilla si estás en M365/Teams/SharePoint; Google si estás en Workspace; AWS si tu data ya está en S3/Aurora. **Elegí por dónde vive tu data, no por el agente.** - **Los builders visuales son descartables.** OpenAI ya baja su Agent Builder; el control de Copilot en Power Apps murió. Lo que sobrevive es la capa de estándares (MCP, A2A) y el código. Si te importa la portabilidad: apoyate en MCP y mantené la lógica en flows/código exportables, no atada a un canvas propietario que mañana deprecan. **Fuentes de la competencia (para profundizar):** - AWS Bedrock AgentCore: `aws.amazon.com/bedrock/agentcore` - OpenAI Agents SDK: `openai.github.io/openai-agents-python` - Anthropic Claude Agent SDK / MCP: `docs.anthropic.com` y `modelcontextprotocol.io` - Google Gemini Enterprise Agent Platform: `cloud.google.com/products/gemini-enterprise-agent-platform` --- ## 13. Casos de uso end-to-end Tres casos completos que integran todo lo anterior. Elegí el que más se parezca a lo tuyo y armalo. ### Caso A — Portal de autoservicio de IT (reactivo + acciones) **Objetivo:** que los empleados resuelvan pedidos comunes solos. - **Canal:** Teams + embebido en una Power App interna. - **Knowledge:** SharePoint de políticas de IT. - **Tools (flows):** - "Solicitar acceso a sistema X" → flow que crea aprobación + registra en Dataverse. - "Resetear password" → flow que dispara el proceso correspondiente. - "Abrir ticket" → flow que crea el ticket y devuelve el ID. - **Guardrail:** accesos a sistemas sensibles requieren aprobación del owner (paso de approval en el flow). - **Power Apps:** una app de "Portal de servicios" con el PCF ChatControl embebido, pasándole el email del usuario logueado como contexto. ### Caso B — Agente de operaciones autónomo (proactivo) **Objetivo:** triage automático de alertas. - **Trigger:** nueva fila en una tabla de alertas (Dataverse) o mail entrante. - **Instructions:** clasificar severidad, buscar runbook conocido, actuar o escalar. - **Tools:** flow de remediación (bajo riesgo, automático) + flow de escalamiento (alto riesgo, con aprobación humana). - **Guardrail:** cualquier acción sobre producción → aprobación humana vía agent feed. - **Monitoreo:** revisás la actividad y las aprobaciones desde el agent feed en la app de operaciones. ### Caso C — Asistente de datos multi-agente (avanzado) **Objetivo:** ventanilla única que responde sobre RRHH, IT y compras. - **Orquestador padre** que delega en 3 sub-agentes especializados. - Cada sub-agente con su knowledge y tools propias. - **MCP** para exponer herramientas comunes (ej: consulta de directorio) reutilizadas por todos. - **Power Apps:** una app "Centro de servicios" con el agente orquestador embebido. **Plantilla de diseño para cualquier caso (usala siempre):** 1. ¿Reactivo o autónomo? (¿le hablan o actúa solo?) 2. ¿Qué knowledge necesita? 3. ¿Qué acciones tiene que ejecutar? (listá los flows) 4. ¿Qué guardrails? (qué requiere aprobación humana) 5. ¿Dónde lo consumen? (Teams, web, Power App) 6. ¿Cuánto va a consumir en créditos por interacción? (estimá antes de ir a prod) --- ## 14. Testing, canales y publicación ### 13.1 Testing - **Test panel** (durante desarrollo): probá cada intención, verificá qué tool/knowledge usa y por qué. - **Probá los caminos infelices:** preguntas fuera de scope, datos faltantes, errores de los flows. - **Multi-turn:** el agente usa el historial de conversación, así que la misma pregunta puede dar distinta respuesta en una charla larga que en una nueva. Probá ambos. ### 13.2 Canales (dónde vive el agente) - **Microsoft Teams** (el más común para internos), - **Web / sitio propio** (embed code), - **Power Apps** (sección 11), - **Dynamics 365 / Omnichannel**, - **Voz** (experiencias de voz en tiempo real), - **SharePoint, WhatsApp, etc.** según necesidad. ### 13.3 Publicación - **Publish** genera la versión disponible en los canales. - Todo cambio requiere re-publicar para que impacte. - En ALM serio: publicás en DEV, exportás la solución, importás a TEST, validás, y recién ahí a PROD. --- ## 15. Governance, seguridad y ALM Esto es lo que separa un experimento de algo que ponés en producción sin que te explote. ### 14.1 DLP (Data Loss Prevention) Políticas a nivel tenant/environment que definen qué connectors pueden convivir. Ejemplo: prohibir que un connector de datos internos se combine con uno de redes sociales en el mismo flow. **Configuralo antes de dejar makers sueltos.** ### 14.2 Seguridad de datos - El agente respeta (o no) los permisos de las fuentes: verificá que no expongas docs sensibles a quien no debe. - Cuidado con las variables que pasás desde/hacia la app: no metas secretos en query strings. - Autenticación: definí si el agente requiere login (para atarlo a la identidad del usuario) o es anónimo. ### 14.3 ALM (Application Lifecycle Management) - Trabajá con **Solutions** para empaquetar y mover entre entornos. - **Nunca** desarrolles en PROD. - Versioná: sabé qué versión está en cada entorno. - Usá **Managed Environments** para deployments serios (recordá el tema de licenciamiento de la sección 4). ### 14.4 Monitoreo y costos - Analytics del agente: qué preguntan, qué resuelve, dónde falla, tasa de escalamiento. - **Consumo de créditos:** dueño asignado, revisión semanal el primer trimestre. Los créditos se van en features caras (grounding, autonomía, razonamiento), no en el volumen de mensajes. Vigilá eso. - Trackeá capacity de Dataverse (Database/File/Log) en el Power Platform Admin Center — hay enforcement real cuando te pasás. --- ## 16. Buenas prácticas y errores comunes **Buenas prácticas:** - **Instrucciones claras y descripciones de tools excelentes** > mil topics. El orquestador vive de eso. - Empezá chico: un caso de uso bien resuelto antes que un mega-agente que hace todo mal. - Guardrails desde el día uno: definí qué NO puede hacer solo. - Estimá créditos por interacción **antes** de ir a producción. - Documentá cada flow y cada tool (tu yo del futuro te lo agradece). - Probá los caminos de error, no solo el happy path. **Errores comunes:** - ❌ Seguir tutoriales viejos de PVA/topics como si fuera lo actual. - ❌ Usar el control Copilot deprecado en Power Apps (usá PCF ChatControl o M365 Copilot in canvas). - ❌ Descripciones de tools vagas → el orquestador nunca las usa. - ❌ Desarrollar en PROD. - ❌ No configurar DLP y dejar makers combinando connectors peligrosos. - ❌ Subestimar el consumo de créditos y llevarte una factura sorpresa (especialmente con agentes autónomos y razonamiento). - ❌ Prender Managed Environments sin cubrir el licenciamiento de todos los usuarios activos. - ❌ Exponer docs sensibles por no revisar permisos de las fuentes. - ❌ Abusar de computer use cuando había una API disponible (caro y frágil). --- ## 17. Ruta de aprendizaje y recursos **Ruta sugerida (en orden):** 1. Armá el agente FAQ del Caso 1 (sección 5). Sin acciones, solo knowledge. 2. Agregale UN flow simple (ej: abrir ticket). Aprendé inputs/outputs. 3. Prendé orquestación generativa y jugá con las instrucciones. 4. Embebelo en una Power App con PCF ChatControl, pasándole el email del usuario. 5. Armá un agente autónomo con un trigger de evento y guardrails. 6. Escalá a multi-agente o MCP cuando te quede chico el mono-agente. 7. Meté ALM en serio: entornos DEV/TEST/PROD y soluciones. **Recursos oficiales (buscá siempre la versión más nueva, esto cambia rápido):** - Microsoft Learn — Copilot Studio: `learn.microsoft.com/microsoft-copilot-studio` - Orquestación generativa: `learn.microsoft.com/microsoft-copilot-studio/advanced-generative-actions` - Agentes autónomos: `learn.microsoft.com/microsoft-copilot-studio/guidance/autonomous-agents` - Copilot Studio Samples (PCF ChatControl): repo `microsoft/CopilotStudioSamples` en GitHub - Power Automate docs: `learn.microsoft.com/power-automate` - Power Apps docs: `learn.microsoft.com/power-apps` - Blog oficial de Copilot Studio (novedades mensuales): `microsoft.com/microsoft-copilot/blog/copilot-studio` - Licenciamiento Copilot Studio: `learn.microsoft.com/microsoft-copilot-studio/requirements-licensing` **Un consejo final:** este ecosistema se mueve casi mes a mes. Cuando algo no te cierra o un tutorial parece viejo, chequeá el blog oficial y la fecha del artículo antes de tragarte data vieja. Lo que hoy es "el reemplazo recomendado" en tres meses puede ser otra cosa. --- *Documento generado en 2026. Precios, fechas de deprecación y GA sujetos a cambios de Microsoft — verificá contra la doc oficial antes de decisiones de compra o arquitectura.*