Microsoft Agent Framework en .NET: cuándo usar agentes

El pedido llega así: "queremos un agente de IA que atienda las consultas de los clientes". Dos semanas después hay una demo que responde bien las cinco preguntas de la presentación. Llevarla a producción es otra historia: a veces inventa un estado de pedido, a veces llama tres veces a la misma API, una consulta sencilla tarda doce segundos y nadie puede explicar por qué ayer respondió distinto.

La parte fácil de construir un agente ya está resuelta. Microsoft Agent Framework llegó a la versión 1.0 en abril de 2026 y con pocas líneas de C# se obtiene algo que conversa y ejecuta funciones. La parte difícil sigue siendo la misma de cualquier sistema: decidir qué puede hacer, con qué permisos, cómo se prueba y cómo se observa.

Qué es el framework y de dónde viene

Agent Framework es el SDK de código abierto de Microsoft para construir agentes y flujos de varios agentes, en .NET y Python. Unifica dos proyectos anteriores: toma la base empresarial de Semantic Kernel y los patrones de orquestación de AutoGen, y existen guías de migración desde ambos.

En .NET se apoya en Microsoft.Extensions.AI, la abstracción común para hablar con modelos (IChatClient). Eso importa porque el agente no queda atado a un proveedor: hay conectores para Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini y Ollama, entre otros.

Lo que la versión 1.0 marca como estable incluye los agentes individuales, el middleware, la memoria, los flujos de trabajo y la orquestación multiagente. Varias piezas alrededor (la interfaz de desarrollo, algunas integraciones alojadas, los adaptadores de interfaz) siguen en versión preliminar, así que conviene revisar el estado de cada una antes de depender de ella.

Un agente es un modelo dentro de un bucle

Quitando el nombre, un agente es esto: un modelo de lenguaje con instrucciones, una lista de herramientas que puede pedir que se ejecuten, y un bucle que repite "el modelo decide → se ejecuta la herramienta → el modelo ve el resultado" hasta que hay una respuesta.

using System.ComponentModel;
using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

[Description("Consulta el estado actual de un pedido.")]
static async Task<string> GetOrderStatus(
    [Description("Número del pedido")] int orderId)
{
    // Aquí va la consulta real, con los permisos del usuario actual
    return await Task.FromResult($"El pedido {orderId} está en preparación.");
}

AIAgent agent = new AIProjectClient(new Uri(endpoint), new DefaultAzureCredential())
    .AsAIAgent(
        model: "gpt-4o-mini",
        instructions: "Respondes consultas sobre pedidos. Si no tienes el dato, dilo.",
        tools: [AIFunctionFactory.Create(GetOrderStatus)]);

Console.WriteLine(await agent.RunAsync("¿Cómo va el pedido 1042?"));

AIFunctionFactory.Create convierte un método de C# en una herramienta: el nombre, los parámetros y los atributos Description se envían al modelo como esquema. El modelo no ejecuta nada; devuelve la intención de llamar a GetOrderStatus(1042) y es tu proceso el que la ejecuta.

Para una conversación de varios turnos se usa una sesión, que conserva el historial:

AgentSession session = await agent.CreateSessionAsync();

await agent.RunAsync("¿Cómo va el pedido 1042?", session);
await agent.RunAsync("¿Y cuándo llega?", session); // recuerda de qué pedido se habla

Flujos de trabajo: cuando el camino ya se conoce

El framework distingue dos cosas que suelen mezclarse:

• Agente: el modelo decide qué pasos dar. Sirve cuando el camino no se conoce de antemano.
• Flujo de trabajo (workflow): un grafo definido por ti, con pasos, bifurcaciones, ejecución en paralelo y puntos de control. Algunos pasos pueden ser agentes; otros, funciones normales.

Sobre esos flujos se montan los patrones multiagente: secuencial, concurrente, traspaso entre agentes (handoff) y conversación en grupo, con aprobación humana y reanudación.

La regla práctica: si puedes dibujar el proceso como un diagrama, es un flujo de trabajo, y el modelo solo debería intervenir en los pasos donde hace falta interpretar lenguaje. Dejar que un agente "descubra" un proceso que ya conoces lo hace más lento, más caro y menos predecible.

Lo que el ejemplo no muestra

Las herramientas son la superficie de ataque. El texto que entra al modelo (un mensaje del cliente, un correo, el contenido de una página) puede traer instrucciones. Un agente con una herramienta CancelOrder y sin controles puede ser convencido de cancelar el pedido de otra persona. La autorización se hace dentro de la herramienta, con la identidad del usuario real, nunca confiando en lo que el modelo "decidió". Para acciones que no se pueden deshacer, el framework permite exigir aprobación humana antes de ejecutar.

No es determinista. La misma pregunta puede producir respuestas y secuencias de llamadas distintas. Las pruebas unitarias tradicionales cubren las herramientas; el comportamiento del agente se evalúa con conjuntos de casos y criterios, y esa evaluación hay que construirla y mantenerla.

La latencia y el costo se multiplican. Cada vuelta del bucle es una llamada al modelo. Una consulta que usa tres herramientas son al menos cuatro llamadas, cada una con el historial completo. Conviene limitar las iteraciones, mantener pocas herramientas bien descritas y aplicar los mismos límites de consumo que a cualquier API, como en rate limiting en ASP.NET Core.

Sin trazas no se puede depurar. "¿Por qué respondió eso?" solo se contesta viendo qué herramientas llamó, con qué argumentos y qué recibió. El framework emite telemetría con OpenTelemetry; activarla desde el primer día es más útil que cualquier ajuste de instrucciones. Con cuidado: esos registros contienen lo que escribió el usuario, y aplican las mismas precauciones de qué registrar y qué no.

El framework es joven. La 1.0 estabiliza el núcleo, pero el ecosistema se mueve rápido. Aislar el agente detrás de una clase propia, con una interfaz pequeña, hace más barato absorber esos cambios.

Cuándo tiene sentido un agente

• La entrada es lenguaje natural abierto y no se puede reducir a un formulario.
• Los pasos dependen de lo que se va encontrando: consultar algo, y según el resultado, decidir qué consultar después.
• Un error ocasional es tolerable o lo revisa una persona antes de que tenga efecto.
• Hay presupuesto para evaluación, observabilidad y ajuste continuo, no solo para la demo.

Cuándo no

• El proceso es fijo. Aprobar una factura según tres reglas es un if, no un agente. Es más rápido, gratis y siempre responde igual.
• Basta una sola llamada al modelo. Clasificar un mensaje, resumir un texto o extraer campos de un documento no necesita bucle ni herramientas; IChatClient con salida estructurada es suficiente y mucho más predecible.
• Varios agentes "por diseño". Un sistema multiagente multiplica el costo, la latencia y los puntos de falla. Empezar con un solo agente y pocas herramientas, y dividir solo cuando haya una razón medible, es el mismo criterio de no abstraer antes de tiempo.
• Acciones irreversibles sin supervisión: pagos, eliminaciones, comunicaciones a clientes.
• Se necesita una respuesta exacta y auditable (saldos, impuestos, inventario). El modelo puede redactar la respuesta; el dato tiene que salir de una consulta, no de su memoria.

Conclusión

Agent Framework resuelve bien la plomería: el bucle, las herramientas, las sesiones, los flujos y la telemetría. Lo que no puede resolver es la pregunta previa de si el problema necesita un agente. En muchos casos la mejor solución es un flujo definido en código con una o dos llamadas al modelo en los pasos donde hay que entender lenguaje. Cuando sí hace falta un agente, tratarlo como cualquier componente que ejecuta acciones con datos reales —permisos mínimos, límites, trazas y evaluación— es lo que separa la demo de algo que se puede dejar en producción.