Google convierte evals de agentes en una skill: el flywheel que evita arreglar un bug y romper diez
Google publicó el 30 de junio de 2026 Agent Quality Flywheel, una skill para que un coding agent prepare datasets, corra inferencia, califique trazas con AutoRaters y proponga fixes medibles. La señal práctica: las mejoras de agentes necesitan deltas, no vibe checks.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google publicó el 30 de junio de 2026 una pieza que debería incomodar a cualquiera que mejora agentes solo con intuición: Agent Quality Flywheel, una skill para que un coding agent orqueste el ciclo de evaluación de otro agente. La promesa no es "más benchmarks". Es bajar el proceso a una rutina repetible: preparar datos, correr inferencia, calificar trazas, analizar fallos y volver a intentar con una corrección acotada.
La pregunta que ataca es muy concreta. Arreglaste un prompt porque un usuario se quejó. En tres ejemplos se ve mejor. ¿Cómo sabes que no rompiste diez casos que antes sí funcionaban?
El flywheel en cinco pasos
Google describe cinco etapas:
- Prepare Data: construir un dataset desde trazas OTel, casos manuales o escenarios sintéticos.
- Run Inference: ejecutar el agente sobre ese dataset y producir trazas.
- Grade: puntuar las trazas con AutoRaters adaptativos o métricas propias.
- Analyze Failures: leer veredictos, entender por qué fallaron y agrupar patrones si hay suficientes casos.
- Optimize & Iterate: aplicar un fix específico, volver a correr y comparar contra la línea base.
El matiz importante: el optimizador no se califica a sí mismo. Google separa quién propone el cambio de quién evalúa el resultado. Para agentes, esa frontera es más importante de lo que parece. Si el mismo sistema que inventa el fix también define el aprobado, termina optimizando la métrica equivocada.
Lo útil no es automatizar todo
La skill no se presenta como un agente autónomo que toca producción sin permiso. Propone, tú apruebas. También deja claro que los AutoRaters son jueces basados en modelo: útiles para señales direccionales y deltas entre corridas, no para convertir un número aislado en verdad absoluta.
Ese equilibrio es sano. Muchos equipos se van a dos extremos: o no evalúan nada porque parece pesado, o intentan automatizar todo el ciclo y terminan creyendo métricas frágiles. El patrón de Google está en medio: deja que el coding agent haga el trabajo tedioso, pero conserva la aprobación humana y compara contra baseline.
El ejemplo del post aterriza bien el problema. Un agente de viajes podía actualizar estado interno después de una corrección del usuario, pero su respuesta final seguía mostrando información vieja. Nada explotaba. La traza parecía razonable. El usuario recibía una respuesta incorrecta. Ese tipo de fallo es justo el que una demo manual suele dejar pasar.
Qué deberían copiar los equipos pequeños
No necesitas montar toda la plataforma desde el día uno. Sí puedes copiar la disciplina:
- escribe cinco casos que representen cambios reales de usuario;
- guarda trazas completas de cada corrida;
- define una métrica estable para el comportamiento que estás cambiando;
- separa salud general de la métrica específica;
- exige que todo fix declare antes qué métrica debería mover.
Si el agente falló por no respetar una revisión del usuario, no basta con subir "calidad general". Necesitas contar cuántas veces respetó la revisión antes y después. Esa diferencia es la que vuelve defendible el cambio.
Producción entra al loop
La parte más interesante a mediano plazo es que el mismo ciclo puede usar trazas reales. En desarrollo puedes usar escenarios sintéticos; en producción, cada sesión fallida puede convertirse en caso de prueba para el siguiente ajuste. Google habla de OpenTelemetry y monitoreo continuo como puente entre ambos ritmos.
Para builders, esa es la señal: las trazas no son solo debugging. Son materia prima para mejorar prompts, tools, instrucciones, memoria y criterios de salida.
Demanda e intención
No reporto volumen de búsqueda porque no hay SEO tooling conectado. La demanda se infiere por señales actuales: post oficial de Google Cloud, docs de evaluación de agentes, AutoRaters, auge de coding agents y queries probables como agent quality flywheel, AutoRaters agents, evaluar agentes IA, coding agent evals, OpenTelemetry traces agents y Google agent eval skill.
Agente IA puede competir porque esta discusión en español suele quedarse en "haz evals" sin explicar cómo cerrar el loop. La lectura práctica es esta: un agente no mejora porque un prompt suena mejor; mejora cuando una métrica ligada a trazas se mueve sin degradar la base.
Si todavía estás construyendo los fundamentos, empieza por el curso gratis. Si ya tienes usuarios o corridas recurrentes, tu siguiente tarea no es agregar más tools: es convertir fallos reales en un dataset que tu agente no pueda olvidar.