¿Qué ha unificado Microsoft realmente en un solo stack?
A menudo he visto la pregunta: ¿es este el cuarto o el quinto framework de agentes de Microsoft? En realidad, no. No estamos hablando de otra nueva colección de herramientas, sino de una consolidación adecuada de dos líneas que antes existían en paralelo: AutoGen para la orquestación y Semantic Kernel para la estructura empresarial.
El 4 de abril, me puse a investigar qué era marketing y qué era un cambio real, y el panorama es bastante práctico. Microsoft Agent Framework 1.0 se lanzó como un SDK listo para producción para .NET y Python, con una apuesta clara a largo plazo. El anuncio se hizo en otoño de 2025, las versiones RC salieron en febrero de 2026, así que esto ya no es una simple demo.
Lo que me llamó la atención no fue la palabra 'Framework', sino que finalmente dejaron de obligar a la gente a ensamblar manualmente la mitad del sistema. Ofrece un único runtime, un modelo unificado para la orquestación de múltiples agentes, grafos, streaming, checkpointing y supervisión humana (human-in-the-loop). No es una revolución. Pero por fin parece una herramienta que se puede llevar a producción, y no solo a presentaciones.
La trampa de Azure: ¿Existe el 'vendor lock-in'?
Comparto el escepticismo sobre el 'vendor lock-in'. Microsoft tiene, digamos, una reputación bien ganada en este tema. Pero en este caso, no lo reduciría todo a "por favor, usen solo Azure AI Foundry".
El Agent Framework es de código abierto bajo licencia MIT y no solo es compatible con Azure, sino con cualquier endpoint compatible con OpenAI. Además, puedes ejecutar modelos locales a través de Ollama y alojar todo en ASP.NET Core sin una vinculación obligatoria a la nube de Microsoft. Para quienes diseñan arquitecturas de soluciones de IA y piensan en cómo evitar tener que extirpar dependencias de plataforma más adelante, esta es una buena señal.
El cambio de agosto de 2025 con las APIs v1 de Azure OpenAI también es especialmente importante. En ese momento, Microsoft comenzó a eliminar la sobrecarga innecesaria específica de Azure y a mejorar la compatibilidad con los clientes de OpenAI. Interpreto esto como que entendieron que para la adopción de la IA, no gana el stack más cerrado, sino el que menos estorba al desarrollador.
¿Y qué pasa con RAG? Ya no es una misión de medio día
Aquí es donde Microsoft tuvo serias dificultades con la experiencia de desarrollador (DX) durante mucho tiempo. Cualquiera que intentara implementar RAG a través de Azure AI Search en 2023-2024 recuerda ese circo de índices, pipelines, chunking manual y otras alegrías. No era imposible, pero definitivamente no era amigable.
Ahora la situación es mejor. En el Foundry Agent Service y en torno al nuevo stack de agentes, ya existe un enfoque de Búsqueda de Archivos (File Search) más coherente: subes archivos, configuras un vector store, lo conectas a un agente, y el servicio se encarga del chunking, los embeddings, la búsqueda semántica y por palabras clave, y el reranking. Para el RAG empresarial, esto al menos reduce la barrera de entrada.
Dicho esto, no pretendería que la solución mágica ya está aquí. Si tienes un dominio complejo, permisos de acceso no estándar, documentos pesados, búsqueda multilingüe o requisitos de explicabilidad, la abstracción de "simplemente lanzo los archivos" se agota rápidamente. Pero como capa base para la integración de IA, es algo que ya no da vergüenza mostrarle al equipo.
¿Quién se beneficia realmente de esto?
Ganan los equipos que necesitan un sistema de agentes funcional para procesos de negocio, no un sandbox de investigación. Especialmente donde se necesita construir rápidamente un asistente interno, un RAG sobre documentos, un copiloto para operadores o una automatización con IA sobre un CRM, helpdesk y base de conocimientos.
Los que pierden, curiosamente, no son los competidores de Microsoft, sino las viejas soluciones caseras. Esas donde la orquestación vivía por un lado, la recuperación de información por otro, y el código de unión ('glue code') ocupaba más espacio que la lógica útil. He visto estas construcciones varias veces, y mantenerlas es un dolor de cabeza.
En Nahornyi AI Lab, es justo en este punto donde solemos intervenir: cuando no solo se trata de probar un agente, sino de crear una automatización con IA con una arquitectura sólida, sin dependencias innecesarias de la nube y sin sorpresas en producción. A veces, el stack de Microsoft encaja perfectamente. Otras veces no, y entonces, honestamente, busco otras opciones.
Este análisis fue escrito por mí, Vadym Nahornyi, de Nahornyi AI Lab. No me limito a repetir comunicados de prensa, sino que construyo y pruebo estas cosas con mis propias manos en casos de uso reales: RAG, pipelines de agentes, arquitectura de IA e integración de inteligencia artificial en procesos de negocio.
Si quieres discutir tu caso, encargar una automatización con IA, crear un agente de IA a medida o construir una automatización en n8n con un LLM sobre tus datos, contáctame. Veremos si el stack de Microsoft es necesario o si hay un camino más corto y económico.