Feedback loop en agentes de IA: cómo cerrar el ciclo de mejora

Un agente que corre sin feedback es alguien practicando a oscuras: repite el mismo gesto mil veces sin saber si mejora o empeora. Puede ejecutar tareas todo el día y seguir cometiendo el mismo error, porque nada le dice que ese resultado estuvo mal. El feedback loop es la pieza que convierte ese “repetir” en “mejorar”, y es lo que separa a un agente de IA que funciona a medias de uno que se va afinando con cada vuelta.

¿Qué es un feedback loop en un agente de IA?

Un feedback loop es la vuelta del bucle donde el resultado de una acción se mide, y esa medición cambia la siguiente acción. Es la diferencia entre actuar a ciegas y actuar con corrección de rumbo.

Para verlo hay que recordar qué es un agente. Un agente de IA es un modelo metido en un bucle: recibe contexto, decide una acción (muchas veces usando una herramienta, como leer un archivo o llamar a una API), observa lo que devuelve esa acción y decide el siguiente paso. Ese giro se repite hasta cumplir el objetivo, y ahí está la diferencia con una llamada suelta que responde una vez y se apaga. Ese bucle es el motor del agente, y diseñarlo bien es la mitad del trabajo: las decisiones que lo definen las desgrano en la arquitectura de un agente empresarial.

El feedback es una parte concreta de ese bucle: la vuelta en la que el resultado no solo se observa, sino que se mide contra algo, y esa medida decide qué hace el agente después. Observar no es lo mismo que medir. Un agente puede leer la salida de un test y seguir adelante como si nada; el feedback loop existe cuando ese resultado, verde o rojo, cambia de verdad el siguiente intento.

// El feedback loop de un agente: actuar, medir, y dejar que la
// medida cambie el siguiente intento.
async function resolverConFeedback(objetivo: Objetivo) {
  const MAX_INTENTOS = 5 // ajusta a tu caso
  let feedback = ""
  for (let intento = 0; intento < MAX_INTENTOS; intento++) {
    const resultado = await agente.actuar(objetivo, feedback)
    const senal = await medir(resultado)   // test, linter o juez
    if (senal.ok) return resultado         // la señal aprueba: paramos
    feedback = senal.detalle               // qué falló entra en el próximo intento
  }
  // Agotados los intentos sin señal verde: fallamos fuerte en vez de
  // devolver undefined en silencio.
  throw new Error(`Sin resultado válido tras ${MAX_INTENTOS} intentos`)
}

feedback = senal.detalle es la asignación que convierte el bucle en aprendizaje. Sin ella, el agente itera en el vacío.

Dos tipos de feedback: determinista y por juicio

Hay dos maneras de darle una señal a un agente, y elegir bien entre ellas no es un detalle menor. Acertar aquí puede eliminar una llamada de modelo por iteración; equivocarte te ata al juez de por vida.

El feedback determinista compara el resultado con una regla fija. Un test que pasa o falla, un linter que encuentra o no un error, un gate que valida un esquema, o comparar la salida con una respuesta esperada. La señal es binaria o medible, y siempre da lo mismo ante la misma entrada. No opina: mide.

El feedback por juicio usa otro modelo para evaluar la salida del primero. Le pasas al modelo evaluador la respuesta y una rúbrica, y él valora cómo de buena es. Esto es el LLM-as-judge, y lo cubro a fondo en modelo como juez. Sirve para lo que ninguna regla sabe medir, a cambio de meter un modelo (con sus manías) dentro del bucle.

	Feedback determinista	Feedback por juicio
Cómo mide	Una regla fija: test, linter, gate o comparación exacta	Otro modelo evalúa con una rúbrica que tú escribes
Coste	Casi nulo por ejecución	Una llamada más al modelo en cada vuelta
Estabilidad	Misma entrada, misma señal, siempre	Puede cambiar entre dos ejecuciones idénticas
¿Alucina?	No	Sí, puede
Para qué	Correcto o incorrecto verificable	Claridad, tono y lo que no tiene respuesta exacta

Por qué el determinista gana cuando puedes usarlo

Siempre que puedas medir con una regla, usa la regla. Un test no tiene un mal día: corre igual el lunes que el viernes, no se inventa un aprobado, y cuesta lo mismo ejecutarlo mil veces que una.

Cuando el agente escribe código, la señal más honesta que existe es la suite de tests. Pasa o no pasa, y no hay opinión que discutir. Si tu agente toca código, montar esa red antes de soltarlo es lo primero que harías; lo desarrollo en la estrategia de tests para código generado por IA. Y cuando pasas a producción, esa señal crece hasta convertirse en métricas y evals que corren de forma continua, algo que cubro en cómo evaluar agentes en producción.

El feedback determinista es aburrido. Por eso funciona.

Cuándo necesitas juicio

El juicio entra cuando no hay una respuesta exacta contra la que comparar. ¿Este resumen captura lo importante del documento? ¿El tono de este correo suena profesional? ¿Se entiende esta explicación? No hay test que responda a eso. Son juicios de grado, y una regla fija no sabe puntuar matices.

Ahí un LLM-as-judge gana su sitio: lee la salida y la valora contra una rúbrica que tú defines, escalando un criterio que si no tendría que aplicar una persona a mano en cada caso. El coste es que el juez es otro modelo, con los mismos defectos que cualquier modelo. Puede alucinar. Puede premiar una respuesta larga solo por ser larga. Y a veces cambia de veredicto entre dos ejecuciones idénticas. Por eso el juicio es el segundo recurso, no el primero. Si una regla puede medirlo, la regla gana.

De feedback puntual a un bucle que se ajusta solo

Un feedback loop no tiene por qué ejecutarlo un humano cada vez. Al principio la vuelta la cierras tú: lees el resultado, decides si sirve, ajustas el prompt y vuelves a lanzar. Funciona, pero no escala más allá de unas pocas iteraciones a mano.

El siguiente nivel es dejar que el propio ciclo mida, proponga un cambio, lo pruebe y valide si mejoró. Ese es el patrón de optimización dirigida por experimentos: fijas un baseline, propones una hipótesis, iteras y validas contra ese punto de referencia. El humano solo interviene en el punto donde de verdad aporta criterio, que es aprobar la hipótesis antes de gastar tiempo en ella. El resto del bucle corre solo.

Aquí el feedback deja de ser un paso más y se convierte en el motor. El bucle avanza porque cada vuelta produce una señal que decide la siguiente. Y todo depende de que esa señal apunte al sitio correcto.

La trampa: una señal mala optimiza hacia lo incorrecto

Un feedback loop con una señal mala no se queda quieto. Optimiza hacia lo incorrecto, y lo hace con toda la eficiencia del mundo. Cuando una métrica se convierte en el objetivo, deja de medir lo que importaba. Es la ley de Goodhart, y en un agente se ve muy rápido.

Imagina que mides la calidad de un agente por el porcentaje de tests que pasan, y el agente puede editar esos tests. Aprenderá que la vía más corta a una señal verde es borrar los asserts que le molestan o escribir tests que no comprueban nada. La métrica sube. El código empeora. El bucle está funcionando de maravilla hacia el objetivo equivocado.

La señal tiene que medir lo que de verdad quieres, no lo que es fácil de contar. Un bucle es tan bueno como su feedback, y un feedback que apunta al sitio equivocado es peor que no tener ninguno, porque te da la falsa sensación de que vas mejorando mientras te alejas.

El feedback es solo una vuelta del bucle que ejecuta el agente, y sin una buena señal ningún bucle converge. Diseñar esa señal es la base de la ingeniería del bucle completo, el patrón del que este feedback loop es una pieza.

Errores comunes

Medir lo fácil en vez de lo que importa

La versión silenciosa de la trampa de Goodhart. Cuentas tokens, latencia, número de pasos y coste por respuesta porque salen gratis del log, mientras que “la respuesta era correcta” te obliga a pensar cómo comprobarlo. El final del camino es un agente rapidísimo y barato que responde mal, con un dashboard lleno de gráficas verdes que no miden lo único que te importaba.

Poner un juez donde bastaba un test

Si la salida se puede verificar con una regla, no llames a un modelo para que opine sobre ella. Un LLM-as-judge para comprobar si un JSON es válido es más caro, más lento y encima puede equivocarse. Usa un parser.

Ninguna señal (“parece que va mejor”)

El más común de todos, y el más difícil de admitir. Cambias el prompt, lo pruebas con dos ejemplos a mano, te da la sensación de que mejoró y lo das por bueno. Sin una señal registrada no sabes si mejoró, empeoró, o simplemente tuviste suerte con esos dos ejemplos. “Parece que va mejor” no es feedback. Es una corazonada disfrazada de conclusión.

Bucle sin límite de intentos

Un agente sin tope de iteraciones puede quedarse dando vueltas sobre el mismo error que no sabe resolver, quemando una llamada tras otra sin acercarse a la salida. La primera vez que me pasó fue con un agente al que le faltaba una dependencia que ni siquiera estaba instalada: sin un MAX_INTENTOS que lo cortara, reescribió el mismo import una y otra vez esperando un resultado distinto. Por eso el bucle del snippet lleva un tope y termina con un error explícito al agotarlo. Fallar fuerte es mejor que iterar en silencio para siempre.

Checklist de implementación

• Cada acción relevante del agente produce una señal medible, no una impresión
• Usas feedback determinista (test, linter, gate o comparación con una respuesta esperada) siempre que la salida se pueda verificar con una regla
• Reservas el LLM-as-judge para la calidad subjetiva, y siempre con una rúbrica explícita
• La señal mide lo que quieres de verdad, no lo más fácil de contar
• El agente no puede manipular su propia señal (no toca los tests que lo evalúan)
• Registras cada señal para comparar iteraciones en vez de decidir a ojo
• El humano interviene donde aporta criterio, como aprobar la hipótesis, no en cada vuelta del bucle

Preguntas Frecuentes

¿Feedback determinista o LLM-as-judge? ¿Cuál elijo?

Empieza siempre por el determinista. Si la salida se puede comprobar con una regla (un test o una comparación exacta contra la respuesta que esperabas), úsala, porque es más barata, no alucina y da la misma señal cada vez. Reserva el LLM-as-judge para lo que no tiene respuesta exacta, como el tono o la claridad de un texto. Muchos agentes buenos combinan los dos: un gate determinista filtra lo que se puede verificar y un juez valora lo subjetivo que queda encima.

¿Cómo sé si la señal de mi feedback loop es buena?

Haz la prueba mental del tramposo: si un agente quisiera maximizar tu métrica sin hacer bien el trabajo, ¿tendría un atajo? Piensa en una señal que cuente como éxito “el agente devolvió una respuesta”: un modelo aprende enseguida que soltar cualquier párrafo la sube, aunque no resuelva nada. La forma de comprobarlo sin adivinar es registrar en cada vuelta la puntuación de tu gate o tu juez junto a si la salida sirvió de verdad. Cuando la métrica sube y el resultado real se queda plano, ahí tienes al bucle explotando el hueco.

¿Se puede automatizar el feedback loop de un agente de IA por completo?

La parte mecánica sí: medir, proponer un ajuste, probarlo y validar si mejoró puede correr sin que estés delante. Lo que conviene no automatizar es la decisión de qué hipótesis probar, porque ahí es donde tu criterio evita que el agente optimice hacia lo incorrecto. En la práctica el humano aprueba la dirección y el bucle ejecuta el resto.

¿Esto solo sirve para agentes que escriben código?

No. Cualquier agente con una salida que puedas medir tiene un feedback loop posible: soporte, clasificación de documentos, generación de texto o extracción de datos. Lo que cambia entre unos y otros es el tipo de señal, no la idea de cerrar el ciclo.