Cuando usar Agent Builder, Copilot Studio o Foundry para crear agentes
¿Qué plataforma deberíamos utilizar para crear cada tipo de agente? ¿Agent Builder? ¿Copilot Studio? ¿Foundry?
Crear agentes de inteligencia artificial se está convirtiendo en una capacidad cada vez más accesible dentro de las organizaciones. Sin embargo, a medida que Microsoft amplía las herramientas disponibles para desarrollarlos, aparece una pregunta que muchas empresas empiezan a hacerse: ¿qué plataforma deberíamos utilizar para crear cada tipo de agente?
¿Es suficiente con Microsoft 365 Copilot Agent Builder? ¿Necesitamos Microsoft Copilot Studio? ¿O deberíamos apostar directamente por Microsoft Foundry para tener mayor control sobre la solución?
Microsoft intenta responder a estas preguntas compartiendo cómo está facilitando la creación de agentes entre sus empleados, qué criterios utiliza para elegir cada plataforma y cómo consigue equilibrar innovación, seguridad y gobernanza.
Lo interesante es que no se limita a comparar funcionalidades. Explica cómo una organización del tamaño de Microsoft está abordando uno de los grandes retos de la IA empresarial: permitir que los empleados creen sus propias soluciones sin convertir cada iniciativa en un proyecto complejo de desarrollo de software.
No todos los agentes necesitan la misma plataforma
Uno de los principales aprendizajes que comparte Microsoft es que los empleados suelen sentirse atraídos por las herramientas más potentes y flexibles, incluso cuando sus necesidades son relativamente sencillas. Al fin y al cabo, si una plataforma permite construir prácticamente cualquier solución, ¿por qué no utilizarla desde el principio?
El problema es que este planteamiento puede introducir una complejidad innecesaria. Una herramienta avanzada puede exigir conocimientos técnicos, revisiones de seguridad, decisiones arquitectónicas y procesos de gobernanza que no aportan ningún valor adicional a un agente cuyo único objetivo es consultar documentación.
Microsoft propone cambiar el enfoque y empezar por el problema de negocio, no por la tecnología. Antes de seleccionar una plataforma, debemos entender qué queremos conseguir, qué información necesitamos, qué acciones realizará el agente y quién va a utilizarlo.
A partir de su experiencia, Microsoft distingue tres grandes caminos para crear agentes de IA.
Microsoft 365 Copilot Agent Builder: agentes para trabajar con el conocimiento
La primera opción es Agent Builder en Microsoft 365 Copilot, una experiencia diseñada para que los empleados puedan crear agentes utilizando lenguaje natural y sin necesidad de conocimientos de programación.
Su principal objetivo es facilitar el acceso al conocimiento empresarial. Estos agentes permiten buscar información, responder preguntas, resumir documentación, interpretar contenidos y ayudar a los empleados a trabajar con fuentes de información existentes.
Podemos imaginar, por ejemplo, un departamento de Recursos Humanos que necesita responder preguntas frecuentes sobre vacaciones, permisos o políticas internas. En lugar de desarrollar una aplicación específica, podría crear un agente conectado a la documentación correspondiente de SharePoint para que los empleados consulten esa información de forma conversacional.
También resulta interesante para equipos de proyectos, departamentos comerciales o responsables de formación que necesitan poner a disposición de otras personas información que ya existe dentro de Microsoft 365. La experiencia puede utilizar fuentes autorizadas como SharePoint, sitios web y, en los escenarios admitidos, conectores de Microsoft Graph.
La principal ventaja de Agent Builder es su sencillez. Permite experimentar rápidamente, validar casos de uso y obtener resultados sin introducir una carga técnica excesiva.
¿Dónde está su límite? Fundamentalmente, en los escenarios que requieren ejecutar acciones sobre sistemas empresariales, automatizar procesos o coordinar operaciones más complejas. Cuando el agente necesita pasar de consultar información a modificarla o ejecutar procesos, normalmente debemos valorar Copilot Studio.
Microsoft Copilot Studio: cuando los agentes necesitan actuar
El segundo camino es Microsoft Copilot Studio, la plataforma low-code de Microsoft para crear agentes capaces de conectarse con aplicaciones empresariales, automatizar procesos y ejecutar acciones.
Aquí encontramos una diferencia importante respecto a Agent Builder. Ya no hablamos únicamente de agentes que ayudan a encontrar respuestas, sino de soluciones que pueden participar directamente en los procesos de negocio.
Pensemos, por ejemplo, en un agente que consulta información comercial en Dynamics 365, recupera datos de diferentes sistemas y ayuda a preparar una propuesta para un cliente. Si además necesita actualizar registros, desencadenar flujos de trabajo o interactuar con otras aplicaciones, Copilot Studio proporciona capacidades para construir ese tipo de solución.
La plataforma ofrece conectores, acciones, automatización, integración con sistemas empresariales y herramientas de evaluación y telemetría. También permite desarrollar escenarios con comportamientos autónomos, siempre dentro de los límites y permisos que establezca la organización.
Microsoft destaca que Copilot Studio ocupa un espacio especialmente interesante entre la creación sencilla de agentes y el desarrollo profesional. Permite que usuarios de negocio, especialistas de Power Platform y equipos técnicos desarrollen soluciones relativamente sofisticadas sin tener que construir toda la infraestructura desde cero.
Esto no significa que cualquier empleado deba tener acceso sin restricciones a todas las capacidades. De hecho, Microsoft explica que internamente limita los conectores disponibles, establece políticas de prevención de pérdida de datos (DLP) y diferencia los entornos de autoservicio de aquellos que requieren una supervisión más estricta.
La clave está en facilitar la creación de agentes que aportan valor al negocio, manteniendo el control sobre los datos y las acciones que pueden realizar.
Microsoft Foundry: agentes empresariales con control arquitectónico
El tercer camino está orientado principalmente a desarrolladores profesionales, arquitectos de soluciones y equipos de ingeniería que necesitan construir aplicaciones de IA más personalizadas.
Microsoft Foundry ofrece capacidades para seleccionar y evaluar modelos, desarrollar arquitecturas específicas, implementar sistemas multiagente, integrar servicios propios y establecer mecanismos avanzados de observabilidad y evaluación.
En este escenario, la organización necesita un mayor control sobre cómo funcionan sus soluciones de inteligencia artificial. Ya no se trata solamente de conectar un agente con una aplicación, sino de diseñar componentes, coordinar diferentes agentes, gestionar modelos y adaptar la arquitectura a requisitos técnicos y operativos específicos.
Un ejemplo podría ser una plataforma que coordina diferentes agentes especializados en analizar documentación, consultar sistemas corporativos, validar información y ejecutar tareas dentro de un proceso empresarial. Si necesitamos definir una orquestación personalizada, utilizar modelos específicos o integrar servicios propios, Foundry puede resultar más adecuado.
Microsoft también menciona Microsoft 365 Agents Toolkit como otro camino de desarrollo pro-code, especialmente interesante para desarrolladores que necesitan crear agentes y experiencias personalizadas dentro del ecosistema Microsoft 365.
Eso sí, esta flexibilidad también implica mayores responsabilidades. Los equipos deben ocuparse de aspectos como la arquitectura, la seguridad, el cumplimiento normativo, la supervisión operativa y el mantenimiento durante todo el ciclo de vida de la solución.
Hay un matiz importante que conviene destacar: Foundry no es automáticamente la mejor opción para cualquier agente empresarial. Copilot Studio también puede cubrir escenarios complejos y de alcance corporativo. La necesidad real de personalización y control técnico es lo que debería determinar cuándo dar el salto al desarrollo pro-code.
Comparativa: Agent Builder, Copilot Studio y Microsoft Foundry
Aunque las fronteras entre las plataformas no son completamente rígidas, podemos resumir sus principales diferencias de la siguiente manera:
| Característica | Agent Builder | Copilot Studio | Microsoft Foundry |
|---|---|---|---|
| Enfoque | No-code | Low-code | Pro-code |
| Usuario principal | Empleados y usuarios de negocio | Makers y equipos de negocio o TI | Desarrolladores y arquitectos |
| Caso de uso | Consulta de conocimiento | Procesos y acciones empresariales | Soluciones de IA personalizadas |
| Integraciones | Fuentes de conocimiento admitidas | Conectores y sistemas empresariales | API y servicios personalizados |
| Autonomía | Centrada en recuperación de información | Acciones y comportamientos autónomos | Orquestación avanzada y autonomía personalizada |
| Gobernanza | Integrada en Microsoft 365 | Configurable por administradores | Diseñada y gestionada por la organización |
Esta comparación debe entenderse como una orientación, no como una clasificación absoluta de capacidades. La recomendación consiste en utilizar la solución más sencilla que permita resolver adecuadamente el problema, incorporando complejidad solo cuando el escenario lo justifique.
Los criterios que Microsoft utiliza para elegir una plataforma
Más allá de las funcionalidades, la guía de Customer Zero resulta especialmente útil porque identifica las preguntas que Microsoft plantea a sus empleados antes de comenzar a desarrollar un agente.
La primera tiene que ver con el resultado de negocio que queremos conseguir. No es lo mismo reducir el tiempo que un empleado dedica a encontrar documentación que automatizar la gestión completa de una solicitud de cliente.
También debemos identificar los usuarios a los que va dirigido el agente y su alcance. Una solución de productividad personal tiene implicaciones muy diferentes de otra que utilizarán cientos o miles de empleados en distintos departamentos.
El segundo criterio es el acceso a los datos. Debemos entender dónde reside la información, quién puede consultarla, qué nivel de sensibilidad tiene y si necesitamos combinar datos internos con fuentes externas.
Este punto es especialmente importante porque la calidad del agente dependerá directamente de la calidad de la información disponible. No sirve de mucho desarrollar una arquitectura sofisticada si los documentos están desactualizados, los permisos son incorrectos o los datos empresariales carecen de una gobernanza adecuada.
El tercer criterio es la autonomía y capacidad de actuación. Un agente que responde preguntas sobre documentación no plantea los mismos riesgos que otro capaz de modificar información en Dynamics 365, iniciar aprobaciones o ejecutar procesos sin intervención humana.
Por último, Microsoft considera los requisitos de gobernanza, seguridad, operación y mantenimiento. Cuanto mayor sea el impacto potencial del agente, más importante resulta establecer controles, mecanismos de supervisión y responsabilidades claras.
La gobernanza también depende del tipo de agente
Uno de los aspectos que más me interesan del documento es cómo Microsoft plantea la gobernanza de los agentes de IA. En lugar de aplicar exactamente las mismas reglas a todas las soluciones, propone ajustar los controles al riesgo real de cada escenario.
Microsoft diferencia tres modelos de responsabilidad:
- En Agent Builder, gran parte de la gobernanza se apoya en los mecanismos ya existentes de Microsoft 365, como permisos, etiquetas de confidencialidad y políticas de protección de la información.
- En Copilot Studio, la gobernanza es más configurable y los administradores adquieren un papel fundamental. Es necesario definir qué conectores pueden utilizarse, cómo se comparte la información y qué acciones están permitidas.
- En Foundry, la organización asume una responsabilidad todavía mayor sobre el diseño y funcionamiento de la solución. Esto incluye decisiones relacionadas con modelos, arquitectura, integraciones, seguridad y observabilidad.
Es un enfoque especialmente acertado porque evita dos extremos que pueden perjudicar la adopción. El primero es permitir que cualquiera construya cualquier agente sin controles; el segundo consiste en exigir procesos de aprobación tan complejos que los empleados terminen abandonando sus iniciativas o recurriendo a herramientas fuera del control corporativo.
La gobernanza debería ayudar a innovar con seguridad, no convertirse en una barrera para cualquier experimento.
¿Qué resultados está consiguiendo Microsoft con este enfoque?
El número de creadores activos de agentes en MIcrosoft se ha multiplicado aproximadamente por diez, pasando de unos 2.000 a 20.000 al mes. Además, Microsoft indica que gestiona alrededor de 150.000 entornos personales de desarrollo bajo gobernanza.
Otro dato interesante es la reducción de lo que Microsoft denomina maker friction, una medida de las dificultades que experimentan los creadores durante el proceso. La compañía afirma haber reducido este indicador aproximadamente del 50 % al 5 % mediante sus iniciativas de capacitación, autoservicio y gobernanza.
Estos datos corresponden a la experiencia interna comunicada por Microsoft y no deben interpretarse como resultados que cualquier organización vaya a reproducir automáticamente. Sin embargo, sirven para ilustrar que facilitar la creación de agentes no depende únicamente de proporcionar herramientas.
Microsoft también utiliza recursos internos como Builders Central, un portal de SharePoint para orientar a los creadores, y AskMica, un agente que ayuda a resolver dudas sobre plataformas, entornos y requisitos de cumplimiento. Es una forma interesante de aplicar la propia IA para acelerar la adopción de la IA.
¿Qué podemos aprender para nuestras propias organizaciones?
Creo que la principal enseñanza de esta guía es que necesitamos una estrategia de creación de agentes, no simplemente un catálogo de herramientas de inteligencia artificial.
En muchas empresas todavía estamos centrando gran parte de la conversación en qué plataforma debemos comprar o qué tecnología tiene las funcionalidades más avanzadas. Sin embargo, los resultados dependerán de nuestra capacidad para identificar problemas reales, seleccionar las herramientas adecuadas y ayudar a los empleados a utilizarlas de forma responsable.
Una estrategia razonable podría comenzar por facilitar que los usuarios de negocio experimenten con agentes de conocimiento utilizando Agent Builder. A medida que aparezcan necesidades de integración y automatización, podemos introducir Copilot Studio y establecer mecanismos de gobernanza adecuados al impacto de cada solución.
Para los proyectos que realmente necesiten un mayor grado de personalización, orquestación o control arquitectónico, podemos contar con Microsoft Foundry y nuestros equipos de desarrollo. No se trata de recorrer obligatoriamente las tres plataformas, sino de utilizar cada una cuando tenga sentido.
También me parece fundamental incorporar métricas de negocio desde el principio. Además del número de agentes creados, deberíamos medir cuántos se utilizan realmente, qué procesos mejoran, cuánto tiempo permiten ahorrar, qué calidad ofrecen y qué costes operativos generan.
Y hay otra cuestión que Microsoft recuerda en su guía y que no deberíamos olvidar: no todos los problemas necesitan un agente de IA. En ocasiones, un flujo de Power Automate, una aplicación existente o una automatización convencional pueden resolver el problema de forma más sencilla, predecible y económica.
Conclusión: la mejor plataforma no siempre es la más potente
Nos debemos quedar con la siguiente idea: la creación de agentes de IA no debería estar limitada a los desarrolladores, pero tampoco podemos abordar todos los escenarios con las mismas herramientas, capacidades y controles.
Microsoft 365 Copilot Agent Builder facilita la creación de agentes centrados en el conocimiento. Copilot Studio permite avanzar hacia la integración con aplicaciones y la automatización de procesos empresariales, mientras que Microsoft Foundry proporciona mayor flexibilidad para desarrollar soluciones personalizadas con requisitos arquitectónicos avanzados.
La elección debería depender del problema que queremos resolver, de los datos que necesita el agente, de las acciones que podrá ejecutar y del nivel de control que requiere la organización. Todo ello acompañado de una estrategia de adopción y gobernanza que facilite experimentar sin comprometer la seguridad.
Personalmente, me quedo con una reflexión: el éxito de una estrategia de agentes de IA no se mide por cuántos agentes somos capaces de construir, sino por cuántos problemas reales conseguimos resolver con ellos.
Y para conseguirlo, elegir la herramienta adecuada es importante, pero saber cuándo no necesitamos una herramienta más compleja puede serlo todavía más.
Información basada en la publicación Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry
