Un agente construido en AI Foundry no vale nada si vive aislado de donde trabajan realmente los empleados. Microsoft ofrece dos rutas distintas para llevarlo a Teams y Microsoft 365, y elegir la equivocada cuesta meses de rediseño.
Hay dos formas legítimas de exponer capacidades de IA dentro del ecosistema Microsoft, y se eligen según quién es el dueño de la experiencia. La primera es extender Microsoft 365 Copilot con agentes que aparecen dentro de esa experiencia ya existente (Word, Outlook, Teams). La segunda es construir un agente conversacional independiente que vive como una app de Teams propia, con su propia interfaz de chat, sin pasar por el Copilot nativo. La decisión de arquitectura correcta depende de si el objetivo es aumentar el Copilot que los usuarios ya usan o crear una experiencia de producto separada.
Dentro de la primera ruta, un agente declarativo se define con un manifiesto JSON e instrucciones en lenguaje natural, y reutiliza el modelo, la orquestación y el motor de razonamiento del Copilot de Microsoft 365 —no necesita infraestructura propia de LLM. Un custom engine agent, en cambio, trae su propio backend de razonamiento (típicamente un agente de AI Foundry Agent Service o Semantic Kernel) y se conecta a Teams o a M365 Copilot como un motor externo, dando control total sobre el modelo, el prompt y las herramientas a costa de más trabajo de integración.
Para que Microsoft 365 Copilot pueda responder con datos que no viven en SharePoint u Outlook —un CRM interno, un sistema de tickets, una base de conocimiento propietaria— se implementan Graph connectors, que indexan ese contenido externo en el Microsoft Graph respetando los permisos originales del sistema fuente. Esto es clave para que Copilot nunca muestre a un usuario información que no tendría acceso a ver en el sistema original: el connector propaga ACLs, no solo contenido.
Cuando el objetivo es un agente conversacional independiente en Teams, la Teams AI Library (construida sobre Bot Framework SDK) provee los componentes para manejar el ciclo de vida de mensajes, adjuntar un modelo de Azure OpenAI o un agente de AI Foundry como motor de respuesta, y gestionar estado de conversación por usuario y por canal.
Las respuestas de un agente en Teams no tienen que ser texto plano: Adaptive Cards permite renderizar tarjetas interactivas con botones de acción, formularios y datos estructurados directamente en el hilo de conversación, útil por ejemplo para que un agente de aprobación de gastos muestre el detalle y capture la decisión sin salir del chat.
Teams Toolkit (extensión de VS Code) provisiona automáticamente los recursos de Azure necesarios (App Service o Functions, registro de bot, manifiesto de Teams) y da comandos para depurar localmente contra un tenant de Microsoft 365 real, acortando el ciclo de prueba de un agente sin necesitar desplegar a producción en cada iteración.
Cualquier integración con Microsoft Graph opera bajo el modelo de permisos delegados o de aplicación, y requiere consentimiento explícito del administrador del tenant o del usuario según el alcance solicitado. Un agente mal configurado con permisos de aplicación demasiado amplios (por ejemplo, Mail.Read para todo el tenant en lugar de acceso delegado por usuario) es el error de seguridad más común en estas integraciones, y debe revisarse en cada despliegue.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel