Microsoft Foundry lanza Agent Optimizer: por fin hay un loop de evals a cambios reales para agentes

El anuncio de Agent Optimizer en Microsoft Foundry Agent Service el 3 de junio de 2026 ataca uno de los huecos más molestos del trabajo con agentes: casi todos hablan de evals, pero muy pocos convierten esa evaluación en un loop operativo corto para mejorar el agente sin rehacer media arquitectura.

La promesa oficial de Microsoft es concreta. Agent Optimizer toma un agente alojado en Foundry, lo evalua contra criterios definidos, genera configuraciones candidatas y las ordena según calidad y costo antes de promover una ganadora. Eso lo pone más cerca de un pipeline de optimizacion reproducible que de la tipica sesion de “retoque el system prompt y espero que ahora si”.

La novedad real no es evaluar, es cerrar el ciclo

Microsoft describe un flujo de cinco pasos:

1. evaluar la linea base;
2. generar candidatos;
3. volver a evaluarlos;
4. rankear resultados;
5. desplegar la opción ganadora.

Eso parece obvio escrito así. En la práctica, casi ningun equipo lo tiene armado. Lo normal hoy es:

• detectar que el agente falla;
• tocar prompt o tool descriptions;
• volver a probar a mano;
• y perder trazabilidad de por que una version salió mejor que otra.

Aqui el angulo interesante es que la mejora ya no queda separada del runtime. El post oficial incluso la baja a CLI con azd ai agent optimize, y eso importa porque mete la optimizacion en el mismo flujo donde ya viven deploy, evaluación y observabilidad.

Que si optimiza y que no

Microsoft no lo vende como magia general. El anuncio delimita tres blancos utiles:

• instructions, para reescribir el system prompt;
• model, para comparar despliegues contra los mismos evaluadores;
• tool descriptions, para aclarar cuando y como usar herramientas locales.

Ese último punto es especialmente bueno para builders. Muchas fallas de agentes no vienen del modelo sino de descripciones vagas: herramientas parecidas, parametros confusos, condiciones de fallback no declaradas. Si el optimizador mejora eso con base en fallos observados, ya tienes una mejora más defendible que “le agregue dos lineas al prompt”.

Donde si encaja

Yo lo veo útil en tres escenarios:

1. Soporte o operaciones con criterios claros

Si ya sabes que el agente debe pedir cierto dato, evitar cierto tipo de consejo o escalar ciertos casos, el score tiene dientes. Microsoft muestra justamente ese tipo de ejemplo.

2. Equipos con varios agentes

Cuando tienes cinco o diez agentes, el problema deja de ser construir el primero. El problema es sostener un proceso de mejora sin que todo dependa del operador que mejor “siente” el prompting.

3. Comparacion de modelos con costo real

El anuncio dice que cada candidato se muestra con desglose por tarea y costo de tokens. Esa parte vale mucho más que el benchmark aislado, porque te ayuda a decidir si una mejora de calidad justifica el salto de precio.

El error común va a ser confiarle la estrategia al optimizador

Esto no resuelve el problema de fondo si tus evaluadores son malos. Si mides criterios blandos o ambiguos, solo vas a automatizar ruido.

La lectura correcta es otra: Agent Optimizer sirve cuando ya sabes que comportamiento quieres, como fallan hoy tus agentes y que metricas importan. Sin esa base, el loop puede ser rapido pero no necesariamente útil.

Tambien hay un limite importante en el propio anuncio: hoy la mejora de herramientas se queda en el toolset local del agente, no en herramientas externas como servidores MCP. Eso no lo invalida, pero si acota bastante el alcance del primer release.