Microsoft Agent Framework: Orquestación de Agentes IA

📋 En resumen

Para quién: arquitectos de IA que diseñan sistemas multi-agente sobre Azure AI Foundry y necesitan decidir cuándo pasar de un agente único a orquestación
Tiempo de lectura: ~8 minutos
Qué vas a sacar: qué es Microsoft Agent Framework, en qué se diferencia de Foundry Agent Service y qué patrones de orquestación usar en Azure AI Foundry

Microsoft Agent Framework es el SDK con el que Microsoft quiere que construyas y coordines varios agentes de IA a la vez, en vez de pedirle a uno solo que lo resuelva todo. Nace de fusionar Semantic Kernel y AutoGen, y en Azure AI Foundry es la pieza que conecta el agente que ya funciona con el sistema de varios agentes que necesitas cuando ese agente se queda corto.

Si tu referencia todavía es "un agente con quince herramientas que hace de todo", este artículo es la razón por la que eso se rompe en producción — y qué construir en su lugar.

¿Qué es exactamente Microsoft Agent Framework?

Un SDK multilenguaje (Python y .NET) para crear, ejecutar y coordinar agentes de IA, publicado como sucesor directo de Semantic Kernel y AutoGen — con el mismo equipo detrás de ambos proyectos. Toma la simplicidad de AutoGen para definir agentes y le añade lo que Semantic Kernel ya resolvía en el lado empresarial: gestión de estado por sesión, tipado, middleware y telemetría.

La parte que de verdad cambia las reglas es la librería de workflows: grafos de ejecución explícitos, con puntos de control, rutas condicionales y soporte para intervención humana. Antes tenías que montar ese enrutamiento a mano; ahora es una pieza declarada del framework, con documentación propia sobre flujos de trabajo.

¿En qué se diferencia del servicio de agentes de Azure AI Foundry?

Uno es el kit para diseñar cómo colaboran tus agentes; el otro es dónde los ejecutas con garantías de empresa. Microsoft Agent Framework es la capa de desarrollo — abierta, la instalas donde quieras, ideal para prototipar un patrón de colaboración antes de comprometerte a nada. El Foundry Agent Service es la plataforma gestionada: identidad propia por agente, endpoints estables, seguridad de contenido aplicada y observabilidad integrada.

La secuencia recomendada por Microsoft es la que yo también sigo con clientes: primero un agente único, fiable y medido en Agent Service; solo cuando ese agente ya es aburrido y predecible, se orquesta con Agent Framework y — cuando el patrón demuestra que gana su complejidad — se lleva a producción sobre Foundry. Saltarse el primer paso es la causa más común de que un sistema de varios agentes cueste más de lo que resuelve.

¿Qué patrones de orquestación trae de serie?

Tres, y cada uno responde a una pregunta distinta sobre quién manda:

• Chat en grupo: los agentes se reúnen en torno a un orquestador central, como un comité técnico. Sirve cuando necesitas varias perspectivas sobre el mismo problema antes de decidir.
• Transferencia: el control pasa de un agente a otro de forma explícita, y quien recibe se queda con la conversación entera. Es el patrón natural para un proceso por etapas — recepción, triaje, resolución — donde nadie vuelve atrás.
• Orquestación concurrente: varios agentes trabajan la misma tarea en paralelo e independientemente. Útil cuando el coste de una segunda opinión automática es menor que el de un error que llega tarde.

No hay un patrón "correcto": la pregunta que de verdad importa es si el agente que recibe el trabajo necesita el contexto completo de la conversación (transferencia) o solo el resultado resumido (chat en grupo). Elegir mal aquí es la causa número uno de que un sistema de varios agentes pierda contexto a mitad de proceso.

¿Qué pasa con los agentes conectados que ya tenía funcionando?

Si tu proyecto usa Connected Agents — el patrón agent.as_tool de la generación anterior — tienes fecha límite: se retiran el 31 de marzo de 2027, y ese patrón clásico ya no existe en el nuevo Foundry Agent Service. Sigue funcionando hoy, pero cualquier diseño nuevo debería partir de workflows o de Agent Framework directamente, y las migraciones existentes deberían seguir la guía oficial de migración antes de que la fecha deje de ser un aviso y se convierta en una incidencia.

Es el mismo error que veo repetirse con cualquier servicio en transición: seguir el tutorial que ya está desactualizado porque es el que aparece primero al buscar. Comprobar la fecha de la documentación antes de copiar un patrón de arquitectura debería ser un hábito, no una excepción.

¿Cómo se despliega con garantías para una empresa en España o la UE?

Con Standard Setup y red privada, si el sistema toca datos sensibles. La configuración del entorno tiene dos niveles: Basic te deja empezar rápido pero guarda historial de conversación y datos vectoriales en recursos gestionados por Microsoft; Standard exige traer tu propio Storage, AI Search y Cosmos DB, así que todo se queda en tu tenant — que es lo que de verdad pide cualquier auditoría de cumplimiento seria.

Con red privada además eliminas la salida pública: subred delegada de al menos /27, acceso público desactivado por defecto y acceso solo vía endpoint privado, VPN o ExpressRoute. Con varios agentes esto importa más que con uno solo: cada agente añade sus propias llamadas a herramientas y conectores, y cada una es una ruta de salida distinta. Confinar el sistema entero a tu red convierte "confío en que cada agente se porte bien" en "la red no deja salir nada", que es una garantía bastante más sólida.

¿Cómo se monitoriza un sistema con varios agentes en producción?

Con trazado desde el primer día — porque "la respuesta final estaba mal" no te dice nada cuando hay tres o cuatro agentes en la cadena. El stack de observabilidad de Foundry combina evaluación (calidad, seguridad, precisión de las llamadas a herramientas), monitorización (tokens, latencia, errores) y trazado basado en OpenTelemetry — y funciona igual si construyes con Agent Framework, LangGraph o el SDK de agentes de OpenAI, así que no te encierra en una sola pila.

La guía de Microsoft para construir agentes a escala en una organización añade la pieza que casi nadie hace por decisión propia: evaluaciones adversariales programadas, no solo cuando algo ya ha fallado. Un sistema de varios agentes tiene más superficie para inyección de prompts y uso indebido de herramientas que un agente solo. Programar ese ataque simulado es la diferencia entre encontrar la grieta tú o que la encuentre otro primero — la misma disciplina que exige gobernar el conjunto de agentes de una organización, no solo el sistema que acabas de construir.

Mi postura

Orquestar varios agentes no es un signo de sofisticación técnica — es la respuesta a un problema de fiabilidad muy concreto, y solo debería llegar cuando ese problema ya existe. He visto el patrón contrario más veces de las que me gustaría: un diagrama de cinco agentes en una presentación, construido antes de que uno solo funcionara bien de forma aislada. El resultado casi siempre es un sistema más lento, más caro y más difícil de depurar que el agente único que sustituyó, sin ninguna mejora real de calidad que lo justifique.

Lo que funciona, en los despliegues que veo repetirse: un agente bien acotado, instrumentado desde el primer día, corriendo en producción semanas antes de tocar Agent Framework. Solo cuando su punto débil es evidente — falla en un paso concreto de clasificación, por ejemplo — se separa ese paso en un segundo agente especializado. Esa secuencia, agente único primero, es el seguro más barato contra construir un sistema que nadie sabe depurar.

Preguntas frecuentes

¿Necesito Microsoft Agent Framework si ya uso Copilot Studio?

No para lo mismo. Copilot Studio resuelve agentes de bajo código dentro del ecosistema Microsoft 365; Agent Framework es la capa de desarrollo para construir y orquestar agentes con código, pensada para escenarios donde necesitas control fino sobre el flujo entre varios agentes. Si esa decisión te resulta ambigua, esta comparativa entre Copilot Studio y Microsoft Foundry desarrolla el criterio completo.

¿Agent Framework sustituye a Semantic Kernel o a AutoGen?

Sí — es el sucesor directo de ambos, construido por el mismo equipo. Los proyectos ya existentes en Semantic Kernel o AutoGen siguen funcionando, pero cualquier proyecto nuevo debería empezar directamente en Agent Framework: reúne las capacidades de los dos sin tener que elegir entre la simplicidad de uno y las funciones empresariales del otro.

¿Cuántos agentes necesito para que merezca la pena orquestar?

Ninguno, hasta que un agente único demuestre un límite concreto que no puede resolver por sí solo. La pregunta que de verdad hay que responder antes de añadir un segundo agente es qué métrica mejora con la separación — precisión de una tarea, cobertura de un caso, tiempo de resolución. Si no puedes nombrar esa métrica, el agente adicional es coste sin beneficio medible.

¿Qué identidad usa cada agente cuando hay varios en el mismo sistema?

Cada agente publicado en Foundry Agent Service recibe su propia identidad y su propio endpoint, con permisos de recursos configurados agente por agente — los permisos de desarrollo compartido no se heredan al publicar. Esto es deliberado: te permite razonar exactamente qué puede tocar cada agente del sistema en vez de tener una única identidad sobreprivilegiada detrás de todos, el mismo principio que sostiene Entra Agent ID para el resto de agentes de la organización.