Un agente puede intentarlo otra vez. Esa es una de sus ventajas y una de las formas más rápidas de gastar tiempo sin avanzar. Cada nuevo intento tiene que incorporar un cambio comprobable.
El loop engineering diseña el ciclo que rodea al modelo: qué objetivo persigue, qué acción puede ejecutar, cómo se mide el progreso, qué cambia en el siguiente intento y cuándo debe detenerse. Ese ciclo se implementa y se observa como cualquier otra pieza de software; pedir al modelo que «revise su respuesta» apenas define el comportamiento.
El bucle básico y lo que suele faltar
Los runtimes de agentes ya ejecutan un ciclo elemental: el modelo responde, solicita herramientas, recibe resultados y vuelve a decidir. El Runner del SDK de OpenAI continúa hasta obtener una salida final, producir un handoff o superar el máximo de turnos (OpenAI Agents SDK).
Eso permite actuar, pero no garantiza progreso. Para mejorar de forma deliberada añadimos cinco elementos:
La salida del evaluador debería ser estructurada: pasa o no pasa, criterios incumplidos, evidencia y corrección propuesta. “Puede mejorarse” no indica una acción.
Primero, evidencia externa
El mejor feedback procede del entorno. Una prueba que falla, un esquema inválido, una cita que no respalda la afirmación o una API que rechaza la operación son señales más fiables que pedir al modelo que puntúe su propio trabajo.
Anthropic recomienda que los agentes obtengan ground truth mediante resultados de herramientas o ejecución de código y contempla un evaluador-optimizador cuando existen criterios claros (Anthropic). Primero utilizamos verificadores deterministas; después un modelo evaluador para dimensiones abiertas como cobertura, claridad o consistencia.
El evaluador puede ser otro modelo o configuración, pero la independencia no aparece solo por cambiar el nombre del agente. Conviene ocultarle el borrador de razonamiento, darle una rúbrica y exigir referencias al artefacto. Para decisiones sensibles, la revisión final sigue siendo humana.
El feedback debe modificar la siguiente acción
Un bucle se estanca cuando el feedback se acumula como texto, pero el agente conserva la misma estrategia. Si una búsqueda no encuentra evidencia, “busca mejor” suele repetir términos. Un feedback útil puede proponer otra fuente, reformular una entidad o declarar que el dato no está disponible.
Podemos clasificar la corrección:
| Tipo de fallo | Siguiente movimiento |
|---|---|
| Ejecución temporal | Reintentar con espera y límite |
| Entrada inválida | Corregir parámetros según el error |
| Evidencia insuficiente | Cambiar consulta, fuente o reducir la afirmación |
| Plan incorrecto | Replanificar desde el último estado válido |
| Criterio imposible | Escalar o renegociar el alcance |
Reintentar una operación externa exige idempotencia. Si el agente no sabe si una orden se creó antes de perder la conexión, consulta el estado o usa una clave estable. El bucle no debe convertir un fallo de red en dos efectos.
Condiciones de salida basadas en el resultado
Un límite de veinte turnos evita una ejecución infinita, pero no demuestra que el resultado sea correcto. La salida positiva debe depender de condiciones observables: todas las pruebas pasan, cada requisito tiene evidencia, el total cuadra o la persona autorizada aprobó.
También hay salidas negativas legítimas: presupuesto agotado, ausencia de progreso, dependencia caída, riesgo fuera de alcance o información insuficiente. En esos casos el agente entrega el estado, las acciones realizadas y el bloqueo de forma explícita.
- Éxito: se cumplen criterios verificables y no quedan bloqueos obligatorios.
- Sin progreso: varias iteraciones no añaden evidencia ni reducen defectos.
- Presupuesto: se alcanza el límite de coste, tiempo, turnos o llamadas.
- Riesgo: la siguiente acción requiere una autoridad que el agente no tiene.
- Dependencia: falta un dato o servicio que no puede recuperar de otra forma.
- Escalado: una persona recibe contexto suficiente para continuar.
Desactivar el máximo de turnos, una opción que algunos runtimes permiten, solo es razonable si existe otro controlador durable con presupuestos y condiciones de parada. Una ejecución sin límite ni controlador queda fuera de gobierno.
Ejemplo ilustrativo: un informe que se corrige con evidencia
Un agente prepara un análisis de proveedores. El verificador detecta dos afirmaciones sin fuente y una cifra cuya fecha no coincide. En lugar de reescribir todo, el bucle crea tres tareas: localizar la fuente primaria, actualizar la cifra y retirar la afirmación si no aparece evidencia.
Tras la segunda iteración, una fuente sigue ausente. El agente no inventa ni abre una búsqueda ilimitada: reduce la conclusión, marca el vacío y supera la rúbrica porque esta permite abstención explícita. El progreso consistió tanto en añadir evidencia como en eliminar una afirmación que no podía sostenerse.
Evaluar el bucle, no una vuelta
Medimos tasa de finalización, calidad final, número de iteraciones, coste, tiempo y frecuencia de escalado. También observamos el progreso por vuelta: defectos resueltos, evidencia añadida y cambios de estrategia.
Anthropic advierte que las evaluaciones de agentes deben cubrir el entorno y la trayectoria multi-turno, no únicamente una respuesta (Anthropic, 2026). Ejecutamos varias repeticiones porque una sola trayectoria puede ocultar variabilidad.
Las trazas necesitan guardar estado y evaluación de cada ciclo. En observabilidad para agentes explicamos cómo separar métricas agregadas de la reconstrucción de una ejecución concreta.
Preguntas frecuentes
¿Loop engineering es lo mismo que prompting iterativo?
El prompting iterativo puede pedir una revisión. El loop engineering controla desde la aplicación el estado, las herramientas, los evaluadores, los presupuestos, el progreso y las salidas.
¿El evaluador debe ser más potente que el generador?
No siempre. Depende del criterio. Un modelo pequeño puede clasificar un requisito claro; una revisión compleja quizá necesite un modelo más capaz o una persona.
¿Cuántos intentos son razonables?
Los que demuestren mejora frente a su coste y riesgo. Se calibran con evaluaciones; los errores temporales y los defectos de contenido pueden tener límites distintos.
¿Cómo detectamos que no hay progreso?
Comparando estados: mismos errores, mismas fuentes, mismo plan o artefacto sin cambios materiales durante varias vueltas. La detección debe ser estructurada.
¿Puede un agente cambiar su propio objetivo?
Puede proponer una reformulación, pero un cambio material de alcance o criterio debe validarse por el propietario del trabajo. De otro modo puede “triunfar” simplificando el encargo.
La mejora necesita una diferencia comprobable
Antes de abrir otra iteración, el sistema debería poder indicar qué cambiará. Si la única respuesta es «el modelo volverá a pensarlo», falta definir la corrección. Un ciclo útil incorpora evidencia, cambia de estrategia o se detiene.
Fuentes y lecturas recomendadas
- Running agents — OpenAI Agents SDK
- Agent orchestration — OpenAI Agents SDK
- Building effective agents — Anthropic
- Demystifying evals for AI agents — Anthropic
Fuentes y vigencia técnica revisadas el 7 de septiembre de 2026.