Microsoft Agent Framework en .NET: lo que nadie te dice sobre agentes en producción
Microsoft ha lanzado la primera versión estable de su Agent Framework. Y, más allá del sello de estable, como programadores .NET debemos empezar a mirar esto de cerca. Porque cuando un agente entra en una empresa deja de ser una demo simpática. Pasa a ser un sistema que necesita control, memoria, observabilidad y gobernanza.
Yo ya había jugado con este framework cuando todavía estaba en preview, así que esta opinión no nace solo del anuncio de salida.
No empecé a mirarlo ahora. La versión estable, más que descubrírmelo, me confirmó que Microsoft quiere empujar esto en serio y que merece la pena pararse a evaluar hacia dónde apunta.
El problema real: demo vs producción
No me interesa tanto el titular de “nuevo framework”. Me interesa otra cosa: qué problemas está intentando reconocer como reales.
Porque la mayoría del contenido que veo sobre agentes sigue girando alrededor de demos personales, asistentes simpáticos y flujos que funcionan muy bien… hasta que intentas meterlos en una empresa de verdad.
Y ahí cambia todo.
Hay una diferencia enorme entre:
- Un agente demo
- Un agente en producción
La demo impresiona rápido, pero en producción te obliga a responder preguntas que el hype prefiere evitar.
Por eso Microsoft Agent Framework me parece relevante. No porque venga a resolver mágicamente el problema, sino porque, por fin, empieza a tratar los agentes como lo que realmente son cuando salen del laboratorio: sistemas de software con memoria, herramientas, estado, control, auditoría y coste.
Y aquí quiero dejar una cosa clara. No estoy menospreciando el trabajo de proyectos como OpenClaw.
De hecho, buena parte de estas opiniones empezaron cuando instalé OpenClaw en una Raspberry Pi 5 y lo probé pensando que, en el fondo, tampoco era una aplicación tan compleja: un LLM con muchas skills y poco más.
Llegué a pensar que podía replicarlo sin demasiada dificultad. Y ahí fue donde me llevé el golpe.
Justo intentando algo así empecé a encontrarme con muchos de los problemas que comento en este artículo.
No porque la tecnología estuviera mal, sino porque desarrollar algo así es bastante menos trivial de lo que parece desde fuera.
En mi caso, ese choque fue lo que me sirvió de base para entender mejor los problemas que luego aparecen cuando te enfrentas a agentes en entornos empresariales.
Qué aporta Microsoft Agent Framework
Durante bastante tiempo, en .NET hemos tenido capacidad para jugar con IA. Eso no faltaba. Podíamos usar modelos, integrar herramientas, probar Semantic Kernel, mirar AutoGen y montar cosas interesantes.
El problema aparecía cuando queríamos pasar del experimento a algo más serio. Ahí todo se volvía más difuso: muchas piezas, demasiadas decisiones dispersas y bastante trabajo manual para llegar a una arquitectura medio coherente.
Por eso creo que este framework sí importa. Según la documentación oficial, Microsoft separa de forma bastante clara:
- Agentes para interacción con LLMs, herramientas y contexto.
- Workflows para procesos con pasos explícitos, rutas tipadas, checkpointing y escenarios de human in the loop.
Eso suena a texto de documentación. Pero traducido a lenguaje de ingeniería significa algo bastante útil: ya no todo debe resolverse con “más prompt” y más autonomía del modelo. Podemos distinguir mejor entre razonamiento abierto y control de ejecución.
Y eso, para mí, es el aporte más importante del framework: no solo mezcla bastante bien ideas de Semantic Kernel y AutoGen, sino que además introduce workflows explícitos y una conversación más seria sobre estado, ejecución y persistencia.
Y eso es exactamente lo que necesitábamos.
No veo este lanzamiento como “otro SDK más”. Lo veo como la síntesis pendiente entre lo que Semantic Kernel aportaba en ecosistema y lo que AutoGen aportaba en orquestación. No digo que la síntesis ya sea perfecta. Pero la dirección sí me parece correcta.
Los 4 problemas reales de los agentes en producción
La mayoría del contenido sobre agentes está pensado para demos. Y eso tiene sentido: una demo es lo que mejor entra por los ojos.
Pero una demo no te obliga a responder preguntas incómodas.
Y aquí está también parte de mi crítica.
No va contra proyectos como OpenClaw, ni contra el trabajo que hay detrás, que me parece bastante más serio de lo que mucha gente cree.
Mi crítica va más al uso que se hace de ellos y a cómo, a veces, se presentan casi como si fueran la prueba de que construir agentes fuera poco más que ensamblar piezas ya existentes.
No funciona así.
Por ejemplo:
- ¿Qué herramientas puede ejecutar ese agente y cuáles no?
- ¿Quién autorizó esa acción?
- ¿Qué hizo exactamente el modelo antes de tomar esa decisión?
- ¿Cuánto costó esa interacción?
- ¿Qué parte del contexto se guardó y por qué?
- ¿Cómo recuperas un flujo cuando el modelo falla a mitad de proceso?
Ahí empieza el mundo real. Y ahí también empieza la distancia entre alguien que conecta un LLM y alguien que diseña un sistema serio alrededor de él.
Y lo que más me sorprende no es que una persona no técnica simplifique todo esto. Eso es normal.
Lo que me sigue sorprendiendo es ver a gente técnica hablando de agentes como si todos estos problemas fueran detalles menores o una fase posterior que ya se resolverá sola.
1. Gobernanza
En entornos enterprise no todos los agentes pueden ejecutar todo. Y no todos los usuarios deberían poder disparar las mismas capacidades.
Eso parece obvio cuando hablamos de APIs tradicionales. Pero curiosamente, en agentes, mucha gente actúa como si el modelo fuera una especie de operador neutral al que basta con darle herramientas y ya.
Y no. En una empresa, un agente no puede vivir como un asistente simpático con acceso libre a herramientas. Necesita límites, permisos, aprobaciones y trazabilidad. Si no hay control, no hay sistema. Hay riesgo operativo.
Si un agente puede consultar datos, lanzar procesos, escribir en sistemas o invocar herramientas sensibles, necesitas como mínimo:
- Control de acceso por rol.
- Restricción de herramientas.
- Aprobaciones en acciones delicadas.
- Auditoría de qué pasó, quién lo activó y qué ejecutó realmente el sistema.
Y aquí es donde me parece interesante que Microsoft hable de workflows, de human in the loop, de approvals, de estado persistente y de trazabilidad con OpenTelemetry.
No porque eso cierre el problema por sí solo, sino porque por fin reconoce que el problema existe.
Ese es el tipo de detalle que separa un juguete de una plataforma útil.
2. Observabilidad
Aquí soy bastante radical: un agente sin trazas es una caja negra.
Y si no puedes observar lo que hace el agente, no deberías ponerlo en producción.
No basta con ver la respuesta final bonita. Necesitas poder responder preguntas mucho menos agradables:
- ¿Qué herramientas ejecutó?
- ¿En qué orden?
- ¿Qué decisión tomó el modelo antes de llamar a esa herramienta?
- ¿Cuántos tokens consumió?
- ¿Cuánto tardó cada paso?
- ¿Dónde falló?
Eso implica logging estructurado, trazabilidad, métricas y correlación entre pasos.
Implica saber si el problema fue el modelo, el contexto, la herramienta, una política de aprobación o simplemente una mala decisión de diseño.
Y vuelvo al punto anterior: me parece buena señal que Microsoft esté metiendo observabilidad y estado como parte del discurso del framework.
Porque en producción un agente no es solo una interfaz conversacional. Es una cadena de decisiones que tienes que poder inspeccionar.
3. Memoria
Cuando se habla de memoria, mucha gente se queda en la versión más superficial del concepto: “el agente recuerda cosas”.
Sí. Claro. Pero eso no dice nada útil.
La memoria no es una feature. Es una decisión de arquitectura.
Guardar contexto no es diseñar memoria. Diseñar memoria es decidir qué se guarda, cuánto tiempo vive, cuándo vuelve al contexto y cuánto cuesta mantenerlo.
“El problema no es que un agente tenga memoria. El problema es decidir qué merece quedarse, qué debe resumirse y qué no debería volver nunca al contexto.”
Yo suelo pensarlo así:
- Memoria corta → útil para conversación y contexto inmediato.
- Memoria persistente → útil cuando hay historial, personalización o trazabilidad.
- Memoria resumida → útil cuando el contexto crece pero no quieres pagar tokens sin control.
- Memoria por rol o tarea → útil cuando no todo el contexto debe reinyectarse siempre.
Y si eliges mal, el impacto es inmediato:
- Más tokens.
- Más latencia.
- Peor calidad de respuesta.
- Más dificultad para depurar por qué el agente decidió algo raro.
Lo que me gusta es que el framework ya habla de sesiones, memory & persistence y proveedores de contexto.
Y aquí conviene no confundirse: que el framework hable de memoria, estado o workflows no significa que el problema esté resuelto. Significa solo que Microsoft, esta vez sí, está mirando el problema correcto.
4. Control de ejecución
Aquí es donde desaparece el hype y empieza el trabajo de ingeniería.
Cuando construyes agentes de verdad aparecen problemas menos vistosos, pero mucho más importantes:
- Optimización de tokens.
- Compresión de contexto.
- Manejo de errores del modelo.
- Reintentos y recuperación de estado.
- Decidir cuándo usar
tools, cuándofunction callingy cuándo unworkflowdeterminista. - Limitar el perímetro de ejecución para que el agente no haga más de la cuenta.
Y aquí también conviene decir algo incómodo: no todo necesita multiagentes.
De hecho, muchas veces meter más agentes solo compra más latencia, más coordinación y más coste.
Modelo mental de un agente en producción
Si tuviera que resumirlo mucho, para mí un agente en producción es esto:
- Un
LLMpara razonar. Toolspara actuar.- Memoria para mantener contexto útil.
- Gobernanza para poner límites.
- Observabilidad para entender qué está haciendo realmente.
Si falta una de esas piezas, normalmente no tienes un agente enterprise. Tienes una demo con más o menos ambición.
Decisiones arquitectónicas clave
Aquí es donde, para mí, se separa un enfoque serio de uno improvisado.
Si ya tienes lógica de negocio clara, integraciones definidas y reglas conocidas, muchas veces prefiero:
toolsbien delimitadasworkflowspara pasos deterministas- memoria mínima necesaria
- aprobaciones donde el riesgo lo exija
A partir de ahí ya decides si te compensa dejar más autonomía al modelo, introducir function calling en escenarios concretos o separar responsabilidades en subagentes.
Y solo entonces, si aporta de verdad, dar más autonomía al modelo.
Sé que hay quien dirá que eso suena menos futurista. Puede ser.
Pero en una empresa seria normalmente no te pagan por hacer la demo más vistosa. Te pagan por diseñar algo que no explote a la primera semana.
Ahí cambia el rol del desarrollador
Hoy cualquiera puede conectar un LLM. Eso ya no es diferencial.
Lo difícil ahora es otra cosa:
- Diseñar sistemas robustos.
- Controlar el comportamiento del agente.
- Optimizar costes sin destruir calidad.
- Gobernar herramientas, permisos y memoria.
- Hacer que todo eso sea observable, recuperable y mantenible.
Ahí está, para mí, el valor profesional real.
Por eso creo que este tipo de artículo importa más que otro tutorial de “cómo crear tu primer agente”.
El futuro no va a pertenecer a quien sepa pegar cuatro llamadas a un modelo. Va a pertenecer a quien entienda cómo convertir eso en un sistema con criterio de ingeniería.
El punto que me interesa
Microsoft Agent Framework no me parece perfecto. Todavía habrá que ver cuánto madura y cuánto de su promesa aguanta cuando salgamos del ejemplo bonito.
Pero sí me parece que está bien enfocado. Y eso es importante.
Porque construir agentes no es difícil en concepto. Lo difícil es la verdad incómoda que casi nadie cuenta: gobernanza, observabilidad, memoria, control de ejecución, recuperación de estado y coste.
El futuro no pasa simplemente por usar agentes. Pasa por saber diseñarlos bien cuando aparecen los problemas de verdad: permisos, memoria, coste, observabilidad, errores y control de ejecución.
Por eso creo que Microsoft va en la dirección correcta. No porque ya haya resuelto el problema, sino porque al menos está apuntando al problema correcto.
Y ojalá eso nos empuje también a diseñar agentes con más criterio de arquitectura: menos asistentes genéricos y más sistemas capaces de convivir con gobernanza, observabilidad, memoria y control real en entornos enterprise.
El futuro no es construir agentes.
Es saber gobernarlos.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
Referencias
- Microsoft Agent Framework documentation
- Microsoft Agent Framework Overview
- Introducing Microsoft Agent Framework: The Open-Source Engine for Agentic AI Apps
