¿Uso un producto ya hecho o me lo construyo? ¿Me basta con un agente o necesito varios trabajando juntos? Microsoft ha creado un árbol de decisión que te ayuda a responder estas preguntas paso a paso.
Una de las preguntas que más me hacen en formaciones y consultorías es: «Magda, quiero implementar agentes IA en mi organización, pero no sé por dónde empezar». Y es normal. El ecosistema de Microsoft ofrece tantas opciones —Copilot Studio, Azure AI Foundry, agentes SaaS preconfigurados, infraestructura para construir desde cero— que resulta abrumador saber cuál es la correcta para cada caso.
Por eso me ha parecido tan útil el AI Agent Decision Tree que Microsoft ha incluido en su Cloud Adoption Framework. Es un árbol de decisión que, mediante una serie de preguntas ordenadas, te guía hacia la arquitectura más adecuada para tu escenario específico.
El funcionamiento es sencillo: respondes las preguntas en secuencia. Si contestas «Sí» a cualquiera de ellas, esa condición determina tu arquitectura inmediatamente. Solo avanzas a la siguiente pregunta si tu respuesta es «No».
He creado (con IA por supuesto) este formulario interactivo que te guía, te recomiendo que lo hagas conjuntamente con el post.
Vamos a desgranarlo paso a paso. 👇
Fase 1: ¿Deberías usar agentes IA en primer lugar?
Plan de negocio: Saber cuándo NO deberías usar agentes IA
Antes de emocionarnos con los agentes, Microsoft nos pide que hagamos una pausa. No todo problema necesita un agente IA.
Pregunta 1: ¿Se trata de tareas estructuradas o predecibles?
Piensa en procesos que siguen reglas claras, sin ambigüedad ni necesidad de «razonamiento».
- ✅ Sí → Usa código tradicional o ML no generativo | ❌ No → Continúa a la siguiente pregunta
Si tu respuesta es Sí, la recomendación es clara:
Usa código o modelos de IA no generativa
A veces la mejor IA es no usar IA generativa
Este primer filtro es más importante de lo que parece. Podemos caer en la tentación de usar LLMs para tareas que se resolverían mejor con una simple consulta SQL o un modelo de clasificación tradicional. No todo clavo necesita un martillo de IA generativa.
Pregunta 2: ¿Solo necesitas recuperación de conocimiento estático?
Búsquedas en documentos, FAQs, bases de conocimiento… sin necesidad de «actuar» sobre sistemas externos.
- ✅ Sí → Construye una aplicación RAG |❌ No → Continúa a la siguiente pregunta
Construye una aplicación RAG
Ideal para consultas sobre documentación y conocimiento corporativo
Fase 2: SaaS vs. Construir
Plan tecnológico: Saber cuándo usar agentes SaaS o construir agentes IA
Una vez que has confirmado que sí necesitas un agente IA, la siguiente pregunta es crucial: ¿compro o construyo?
Pregunta 3: ¿Los agentes SaaS existentes cubren tus necesidades?
Microsoft ofrece agentes pre-construidos en muchos de sus productos. ¿Alguno hace lo que necesitas?
- ✅ Sí → Usa agentes SaaS | ❌ No → Construye agentes personalizados
Usa Agentes SaaS
Dentro de M365 Copilot, tienes opciones específicas:
Fase 3: Construyendo tu Agente Personalizado
Si llegaste aquí, significa que necesitas construir algo a medida. Ahora viene la parte interesante: ¿un agente o varios?
¿Un agente o múltiples agentes? Entiende los criterios comunes para cada enfoque. Un «Sí» a cualquier pregunta determina la arquitectura. Solo avanza si todas las respuestas son «No».
⚠️ Ojo con esto: Muchas organizaciones eligen arquitecturas multi-agente sin validar si realmente las necesitan. El resultado: más costes, más latencia y más puntos de fallo de los necesarios.
Criterios para Multi-Agente
Pregunta 4: ¿Cruza límites de seguridad y cumplimiento?
- ✅ Sí → Multi-agente | ❌ No → Continúa
No es solo «hay varios equipos», es que legalmente necesitas que los datos estén aislados. Por ejemplo, en banca un agente prepara la transacción y otro la valida — separación de funciones por arquitectura, no por preferencia. Este diseño de «mínimo privilegio» limita el daño si hay una brecha de seguridad.
Pregunta 5: ¿Involucra múltiples equipos?
- ✅ Sí → Multi-agente | ❌ No → Continúa
La clave aquí es que cada equipo puede desplegar actualizaciones de su agente sin esperar a los demás. Desarrollo en paralelo real. Las interfaces explícitas entre dominios simplifican la gobernanza y reducen el riesgo de integración.
Pregunta 6: ¿Hay planes de crecimiento futuro?
- ✅ Sí → Multi-agente | ❌ No → Continúa
Si sabes que el sistema va a crecer a más de 3-5 funciones distintas, mejor separar desde el principio. Los agentes monolíticos se vuelven inmantenibles cuando las responsabilidades crecen más allá de su alcance original. Refactorizar después es doloroso y arriesgado.
Si respondiste «Sí» a cualquiera de las anteriores:
Construye un sistema multi-agente
Usa workflows para implementar patrones de orquestación
Trade-offs del multi-agente
Antes de lanzarte, ten en cuenta lo que implica:
- Más complejidad de coordinación: Cada interacción entre agentes necesita diseño de protocolo, manejo de errores y sincronización de estado.
- Mayor superficie de seguridad: Más credenciales que gestionar, más puntos de tránsito de datos.
- Coste multiplicado: Cada agente procesa contexto redundante y la comunicación entre agentes suma tokens.
- Latencia acumulada: Cada «handoff» entre agentes añade tiempo de respuesta.
Criterios para Agente Único
Si todas las respuestas anteriores fueron «No», evaluamos si un agente único es suficiente:
Pregunta 7: ¿Baja complejidad?
- ✅ Sí → Agente único | ❌ No → Continúa
Pregunta 8: ¿Roles claramente definidos?
- ✅ Sí → Agente único | ❌ No → Continúa
Prueba primero con un agente único usando cambio de «persona» o prompts de sistema distintos. Solo necesitas agentes separados cuando hay límites de seguridad estrictos o propiedad organizativa diferente.
Pregunta 9: ¿Necesitas time-to-market rápido?
- ✅ Sí → Agente único | ❌ No → Continúa
Los prototipos de agente único validan el valor de negocio y recogen feedback de usuarios mucho más rápido. La complejidad de coordinación del multi-agente retrasa el despliegue inicial y ralentiza las actualizaciones.
Pregunta 10: ¿Es prioritario el bajo coste?
- ✅ Sí → Agente único | ❌ No → Continúa
Un agente único reduce el uso de tokens y las llamadas a API al mantener el contexto en una sola entidad. Valida el ahorro con un prototipo antes de añadir la sobrecarga de orquestación.
Pregunta 11: ¿Procesas grandes volúmenes de datos?
- ✅ Sí → Multi-agente | ❌ No → Continúa
Primero prueba si un agente único con RAG o ventanas de contexto extendidas puede manejar el volumen. Solo pasa a multi-agente si hay degradación del contexto o alucinaciones durante las pruebas de carga.
Pregunta 12: ¿Proceso de alta demanda o diferentes modalidades involucradas?
- ✅ Sí → Multi-agente | ❌ No → Agente único
Mide el rendimiento y latencia con un agente único bajo cargas de producción. La arquitectura multi-agente solo aporta valor cuando la paralelización ofrece mejoras medibles. Empieza con modelos multimodales que manejen texto, imágenes y otros formatos en un solo agente.
🤖 Construye un sistema de agente único
Usa workflows para integración y gobernanza
Trade-offs del agente único
- Límites de contexto: Hay un tope en la cantidad de información que puede procesar a la vez.
- Seguridad menos granular: El agente necesita permisos para todo lo que hace, lo que complica el principio de mínimo privilegio.
- Precisión bajo presión: Dominios muy amplios pueden saturar al agente, reduciendo precisión o aumentando tiempos de respuesta.
El Paso del Test
Antes de comprometerte con multi-agente, Microsoft sugiere un paso intermedio muy inteligente:
Si el test del agente único falla en cumplir todos los requisitos, entonces sí: pasa a multi-agente.
Por qué necesitas workflows (en ambos casos)
Tanto si eliges un agente como varios, los workflows son esenciales para que todo funcione en entornos empresariales:
| Capacidad | Para qué sirve |
|---|---|
| Coordinación | Controla cómo interactúan los agentes: en paralelo, en secuencia o condicional |
| Gestión de estado | Mantiene el contexto entre agentes para preservar el flujo de conversación |
| Lógica de ramificación | Enruta peticiones al agente correcto según condiciones (escalado a humanos, agentes especializados…) |
| Integración | Conecta los outputs con SharePoint, Teams, bases de datos empresariales… |
| Governance y compliance | Logging, puertas de aprobación y pistas de auditoría para cumplimiento normativo |
| Revisión humana | Checkpoints donde una persona valida antes de que continúe la automatización |
Las Herramientas para Construir
Independientemente de si eliges agente único o multi-agente, tienes tres caminos principales para construir:
Microsoft Foundry
PaaS – Pro-code o no/low-code
Copilot Studio
SaaS – No/low-code
GPUs y Contenedores
PaaS o IaaS
📋 Framework de Decisión Rápida
| Enfoque | Úsalo cuando… | ¿Saltar el prototipo? |
|---|---|---|
| Agente único | Dominio acotado, contexto unificado, prisa por entregar, presupuesto ajustado | Sí, si el alcance es simple |
| Prototipo comparativo | No tienes claro qué arquitectura elegir, necesitas evidencia sobre manejo de contexto o rendimiento | No — el prototipo te da evidencia |
| Multi-agente | Límites duros de seguridad/compliance, separación organizativa, escalado multi-dominio garantizado | Sí, si los requisitos lo exigen claramente |
La Tabla de Decisión por Escenario
| Si tu situación es… | Tu camino es… |
|---|---|
| Tareas predecibles y estructuradas | Código tradicional / ML clásico |
| Solo búsqueda de información | Aplicación RAG con Foundry |
| Hay un producto SaaS que lo hace | Usa el agente SaaS existente |
| Cruza límites de seguridad/equipos | Sistema multi-agente |
| Necesitas rapidez y bajo coste | Agente único con Copilot Studio |
| Alta demanda o múltiples modalidades | Sistema multi-agente |
✅ Idea final: Empieza siempre por lo más simple que pueda funcionar. El árbol de decisión de Microsoft está diseñado precisamente para evitar el over-engineering. Si un agente SaaS resuelve tu problema, úsalo. Si un agente único es suficiente, no construyas tres. La complejidad tiene un coste real en mantenimiento, debugging y gobernanza.
Fuente: Microsoft Cloud Adoption Framework – Single agent or multiple agents
¿Te ha resultado útil esta guía? Compártela con tu equipo y ayúdales a tomar mejores decisiones arquitectónicas.