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 mas molestos del trabajo con agentes: casi todos hablan de evals, pero muy pocos convierten esa evaluacion 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 segun calidad y costo antes de promover una ganadora. Eso lo pone mas 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 opcion ganadora.

Eso parece obvio escrito asi. En la practica, 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 salio 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, evaluacion 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 ultimo 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 mas defendible que “le agregue dos lineas al prompt”.

Donde si encaja

Yo lo veo util 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 mas que el benchmark aislado, porque te ayuda a decidir si una mejora de calidad justifica el salto de precio.

El error comun 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 util.

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.

Intencion de busqueda y por que esta nota vale la pena

Las consultas con mejor pinta aqui no son masivas, pero si muy cualificadas:

• microsoft foundry agent optimizer
• agent optimizer foundry
• agent eval optimize loop
• improve agent prompt with evals

En espanol todavia hay poco material que explique la diferencia entre “tener evals” y “tener un sistema que convierta esas evals en una mejor configuracion del agente”. Ese hueco es justo donde Agente IA puede competir.

Si tu stack hoy sigue muy atado a pruebas manuales y retoques de prompt, esta noticia conecta bien con nuestra cobertura sobre evals para agentes. La conclusion es simple: el mercado se esta moviendo de medir agentes a operar mejoras de agentes. Y Microsoft quiere que ese loop viva dentro de la plataforma, no en hojas sueltas y memoria humana.