Si lleváis un tiempo siguiendo la evolución de los agentes de IA en el ecosistema Microsoft, sabréis que el panorama ha cambiado bastante en los últimos meses. Semantic Kernel y AutoGen han sido las dos apuestas principales del equipo de Microsoft Research y el equipo de producto de Azure, respectivamente. Pues bien, los mismos equipos acaban de anunciar el Release Candidate de Microsoft Agent Framework: el sucesor directo de ambos, unificado bajo un único SDK disponible en NuGet y PyPI.
Un RC no es una preview cualquiera. Significa que la superficie de la API se considera estable, que todas las características previstas para la v1.0 están completas, y que el framework ya está listo para ser evaluado en proyectos productivos. En este artículo vamos a ver qué trae, cómo se organiza y qué debéis tener en cuenta antes de migrar.
El problema que resuelve: un marco unificado
Tanto Semantic Kernel como AutoGen son proyectos maduros y con comunidades activas, pero cubrían necesidades distintas. Semantic Kernel apostó desde el principio por las características empresariales: gestión de estado basada en sesiones, type safety, filtros, telemetría y soporte extenso de modelos y embeddings. AutoGen, por su parte, simplificó enormemente las abstracciones para construir agentes individuales y patrones multi-agente sin demasiado boilerplate.
Agent Framework fusiona lo mejor de los dos mundos. Toma las abstracciones simples de AutoGen para agentes individuales y patrones multi-agente, y las combina con las capacidades enterprise de Semantic Kernel. Sobre esa base añade algo que ninguno de los dos ofrecía de forma nativa: workflows basados en grafos con control explícito del flujo de ejecución entre agentes.
Documentación oficial: learn.microsoft.com/en-us/agent-framework/overview/
Los dos pilares: Agents y Workflows
La documentación oficial divide las capacidades del framework en dos categorías principales. Entenderlas bien es clave para tomar las decisiones de diseño correctas en vuestros proyectos.
Agents: el agente individual
Un agente es la unidad básica: recibe una entrada, llama a un LLM, puede invocar herramientas (funciones con definiciones type-safe), conectarse a servidores MCP, y devuelve una respuesta. El framework soporta múltiples proveedores desde el primer día: Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, AWS Bedrock, GitHub Copilot y Ollama.
Para C#, crear un agente conectado a Azure AI Foundry es tan directo como esto:
dotnet add package Microsoft.Agents.AI.Foundry –prerelease
using System;
using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;
AIAgent agent = new AIProjectClient(
new Uri(«https://your-foundry-service.services.ai.azure.com/api/projects/your-project»),
new AzureCliCredential())
.AsAIAgent(
model: «gpt-5.4-mini»,
instructions: «You are a friendly assistant. Keep your answers brief.»);
Console.WriteLine(await agent.RunAsync(«What is the largest city in France?»));
Desde ese punto de partida podéis añadir herramientas tipadas, conversaciones multi-turno con gestión de sesión, y middleware para interceptar y modificar el comportamiento del agente.
Workflows: orquestación explícita con grafos
Los workflows son la novedad más significativa frente a Semantic Kernel y AutoGen. En lugar de depender del modelo para decidir qué agente ejecutar a continuación, vosotros definís el grafo de ejecución de forma explícita. Esto os da control total sobre el orden, las condiciones de bifurcación y los puntos de sincronización.
El framework soporta patrones secuenciales, concurrentes, de traspaso entre agentes (handoff) y de chat grupal. A eso se suma soporte nativo para streaming de resultados parciales, checkpointing para reanudar flujos largos, y human-in-the-loop para aprobar o redirigir pasos críticos del proceso.
La documentación oficial lo resume así: usad un agente cuando la tarea sea abierta o conversacional, y un workflow cuando el proceso tenga pasos bien definidos o cuando varios agentes y funciones necesiten coordinarse. Si podéis resolver el problema con una función normal, hacedlo así y no introduzcáis la complejidad de un agente.
DevUI del Microsoft Agent Framework — interfaz integrada para depurar y visualizar el estado de los agentes durante el desarrollo. Fuente: devblogs.microsoft.com/foundry
Observabilidad de primera clase con OpenTelemetry
Una de las críticas recurrentes a los frameworks de agentes es la dificultad para depurar qué está pasando realmente dentro de una cadena de llamadas. Agent Framework incluye telemetría basada en OpenTelemetry como parte central del diseño, no como un añadido posterior.
Esto significa que podéis conectar vuestro pipeline de observabilidad habitual Azure Monitor, Jaeger, Zipkin o cualquier backend compatible con OTLP y obtener trazas distribuidas que atraviesan los límites entre agentes, incluyendo las llamadas al modelo, las invocaciones de herramientas y los nodos del workflow. Para equipos que ya tienen infraestructura de observabilidad en producción, esto reduce drásticamente el esfuerzo de integración.
Integración nativa con Azure AI Foundry
Microsoft Foundry es el proveedor de referencia dentro del framework. El paquete Microsoft.Agents.AI.Foundry para .NET (o el módulo agent_framework.foundry para Python) conecta directamente con vuestro proyecto de Azure AI Foundry mediante el endpoint del proyecto y credenciales de Azure Identity, sin necesidad de gestionar tokens manualmente.
Esto es relevante para equipos que ya trabajan con Azure AI Foundry para gestionar deployments de modelos, evaluaciones y trazabilidad. El framework se integra en ese ecosistema sin fricción, y el modelo especificado en el agente hace referencia directamente al nombre del deployment en vuestro proyecto de Foundry.
Interoperabilidad: El framework soporta los estándares abiertos A2A (Agent-to-Agent), AG-UI y MCP (Model Context Protocol), lo que facilita la integración con herramientas de terceros y otros sistemas de agentes.
Migración desde Semantic Kernel y AutoGen
El equipo de Microsoft ha publicado guías de migración específicas para ambos frameworks, disponibles en la documentación oficial. La transición no es trivial cambia la forma en que se definen las herramientas, se gestiona el estado y se construyen los flujos multi-agente pero el RC es el momento indicado para empezar a evaluar el coste de esa migración.
Si estáis en un proyecto activo con Semantic Kernel, la recomendación sensata es no migrar todavía en producción. Esperad a la v1.0 estable, que debería llegar pronto dado que el RC ya está publicado. Lo que sí tiene sentido ahora es empezar proyectos nuevos directamente sobre Agent Framework y familiarizarse con los conceptos de workflows y la nueva API de agentes.
Para proyectos en AutoGen el razonamiento es similar. AutoGen seguirá recibiendo mantenimiento, pero el futuro del equipo está claramente en Agent Framework. La comunidad open source que ha contribuido a ambos proyectos se está orientando hacia el nuevo framework, lo que se traducirá en más ejemplos, conectores y extensiones a lo largo de 2026.
Instalación y primeros pasos
Para .NET, el paquete base en NuGet es:
dotnet add package Microsoft.Agents.AI.Foundry –prerelease
Para Python, desde PyPI:
pip install agent-framework
Notad que en Python el framework no carga automáticamente ficheros .env. Si usáis variables de entorno desde un .env, necesitáis llamar a load_dotenv() explícitamente al inicio de la aplicación, o establecer las variables directamente en el shell o en el IDE.
El código fuente y los ejemplos están en GitHub en microsoft/agent-framework. El proyecto tiene canal en Discord dentro del servidor de Azure AI para preguntas y seguimiento de novedades.
Cuándo tiene sentido empezar a usarlo
Con la API estabilizada en RC, los criterios para adoptar el framework dependen del contexto de cada equipo:
Proyectos nuevos en .NET o Python que van a construir agentes o flujos multi-agente: este es el momento de empezar directamente con Agent Framework. Evitáis acumular deuda técnica sobre frameworks que el propio equipo de Microsoft va a depriorizar.
Proyectos en producción sobre Semantic Kernel o AutoGen: no hay urgencia, pero sí conviene planificar la migración con tiempo. Las guías oficiales ya están disponibles y el RC os permite hacer pruebas de concepto con base técnica sólida.
Evaluaciones y demos para clientes: el RC es estable lo suficiente como para mostrarlo en contextos de venta técnica o workshops. La integración con Azure AI Foundry y el soporte multi-proveedor son argumentos que resuenan bien con arquitectos y responsables de plataforma.
Conclusión
Microsoft Agent Framework no es una reescritura por reescribir. Es la respuesta del equipo de Microsoft a las limitaciones reales que han visto en Semantic Kernel y AutoGen: falta de control explícito sobre la orquestación, observabilidad difícil de configurar, y APIs que han evolucionado de forma divergente en .NET y Python.
El RC consolida una superficie de API estable, trae los workflows en grafo como ciudadano de primera clase, integra OpenTelemetry de forma nativa y conecta limpiamente con Azure AI Foundry. Para los equipos que construyen soluciones agenticas sobre Azure, este es el punto de inflexión que convierte al framework en la opción recomendada.
Como siguiente paso práctico, os recomendamos revisar la documentación de overview en learn.microsoft.com/en-us/agent-framework/overview/, clonar el repositorio de GitHub y ejecutar uno de los ejemplos de quickstart. El salto desde un agente básico hasta un workflow multi-agente con checkpointing es más corto de lo que parece.
Referencias oficiales
- Anuncio RC: devblogs.microsoft.com/foundry/microsoft-agent-framework-reaches-release-candidate/
- Documentación overview: learn.microsoft.com/en-us/agent-framework/overview/
- Repositorio GitHub: github.com/microsoft/agent-framework
- NuGet: nuget.org/packages/Microsoft.Agents.AI/
- PyPI: pypi.org/project/agent-framework/
- Guía de migración desde Semantic Kernel: learn.microsoft.com/en-us/agent-framework/migration-guide/from-semantic-kernel/
- Guía de migración desde AutoGen: learn.microsoft.com/en-us/agent-framework/migration-guide/from-autogen/