La terminación del bucle es el mecanismo, no el prompt

La parte más difícil de un bucle de agente de IA autónomo no es conseguir que actúe. Es conseguir que se detenga por la razón correcta. "An Introduction to Loop Engineering" de MachineLearningMastery (23 de julio de 2026) recorre el paso de promptear un agente a mano a diseñar el ciclo que lo promptea, verifica, recuerda y vuelve a ejecutar — y la idea estructural, debajo del vocabulario de herramientas, es que el valor de un bucle lo fija su lógica de terminación y verificación, no la nitidez de ninguna instrucción individual.

La salida del bucle es el mecanismo, no la ejecución

Un bucle, en el sentido que usa el artículo, es un ciclo repetitivo en el que un modelo realiza una acción, obtiene retroalimentación de su entorno, usa esa retroalimentación para decidir qué hacer después y continúa hasta que se cumple una condición real y verificable. Esa última cláusula es todo el argumento. "Mejora la aplicación" no le da al agente nada contra lo que verificar, así que corre para siempre o se detiene por una suposición. "Haz que pasen todas las pruebas del módulo de autenticación" es verificable mecánicamente, y esa diferencia es lo que separa un bucle del que puedes ausentarte de uno que quema tokens en silencio durante una hora.

[UNIQUE INSIGHT] Este es el mismo principio que enunciamos como Theorem 3 en the 21 papers: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Para un bucle de agente, la propiedad es "done" — y el mecanismo es un verificador determinista dentro del ciclo, no el autoinforme del modelo. Un bucle sin una salida que mida no produce trabajo terminado; produce afirmaciones de trabajo terminado. La arquitectura honesta trata "done" como una afirmación que debe verificarse, exactamente como el pseudocódigo del artículo trata verifier.passes(state) como una comprobación determinista y no como una autoevaluación.

El artículo nombra la unidad de trabajo como el bucle en vez del prompt, y ese replanteo importa porque mueve la palanca de ingeniería. Cuando el modelo puede escribir el código por sí solo, la habilidad escasa deja de ser la capacidad de redactar una muy buena frase y pasa a ser la capacidad de diseñar un ciclo que se mantenga correcto, verificado y apuntando al objetivo correcto mientras nadie está mirando. Es un hábito de ingeniería de sistemas, más cerca de diseñar un termostato que de escribir una frase.

Por qué el vocabulario cambió en una semana

La cronología del artículo es lo suficientemente específica para retenerla. El 7 de junio de 2026, el desarrollador Peter Steinberger publicó que la habilidad relevante ya había cambiado: ya no deberías promptear agentes de código, deberías diseñar los bucles que los promptean por ti. Esa publicación supuestamente superó los 6,5 millones de vistas en días. Al día siguiente, el ingeniero de Google Addy Osmani publicó un ensayo titulado simplemente "Loop Engineering" que le dio al idea una anatomía — automatizaciones, worktrees, skills, conectores, sub-agentes y memoria externa debajo de todo. Boris Cherny, que dirige Claude Code en Anthropic, es citado diciendo que ya no promptea Claude directamente; escribe bucles que lo promptean.

La velocidad tiene sentido cuando ves qué cambió por debajo. Para mediados de 2026, los agentes de código habían mejorado lo suficiente para correr sin supervisión durante tramos largos de verdad, recuperándose de sus propios errores sobre la marcha. Cuando una sola ejecución puede durar una hora y tocar docenas de archivos, el cuello de botella no es el prompt. Es si has construido un ciclo que mantiene al agente productivo, verificado y apuntando al objetivo correcto durante toda la hora — incluyendo la parte en que nadie está mirando.

Prompt, contexto, harness, bucle — cada capa envuelve a la anterior

El artículo sitúa loop engineering como la capa más nueva en una progresión, cada una envolviendo a la anterior en vez de reemplazarla. Prompt engineering (aproximadamente 2022–2024) era redacción: rol, pasos, ejemplos, cadena de pensamiento. Context engineering (2025) movió el foco a todo lo que el modelo ve en el momento de responder — historial, documentos recuperados, salida de herramientas. Tobi Lütke de Shopify ofreció una definición que cuajó, y para septiembre de 2025 Anthropic había formalizado context engineering como curar el conjunto óptimo de tokens disponibles durante la inferencia.

Harness engineering llegó a principios de 2026 cuando los agentes empezaron a hacer trabajo más largo y multipaso en producción. El harness es el entorno completo alrededor de un agente — andamiaje, herramientas, restricciones, bucles de retroalimentación. Loop engineering es la capa superior: donde harness engineering pregunta qué entorno necesita un agente, loop engineering pregunta la cuestión más estrecha y operativa de qué ciclo lo mantiene trabajando hacia el objetivo y cuándo se detiene exactamente.

[PERSONAL EXPERIENCE] Hemos estado construyendo en este orden de pila en Everythink desde que el HAI Engine entró en producción en 2016 — prompt, luego contexto, luego harness, luego bucle — y el orden no es cosmético. Cada capa contiene a la anterior, por lo que un bucle sin salida determinista no lo rescata un mejor harness, y un harness sin contexto real no lo rescata un mejor prompt. La disciplina es construir hacia afuera y mantener honesta cada capa interior.

El linaje de investigación: ReAct, Reflexion, evaluador-optimizador

El artículo es franco en que "loop engineering" es un nombre de producto para una dirección de investigación que lleva acumulando resultados desde 2022, y conocer el linaje es lo que separa entender la idea de repetir el artículo de moda.

El ancestro directo es el patrón ReAct (Reason plus Act), introducido por Yao y colegas en 2022 a partir de investigación conectada con Princeton y Google. La idea central era intercalar pasos de razonamiento con pasos de acción: pensar, actuar, observar, pensar de nuevo, actuar de nuevo. Esa intercalación es el bucle base que esencialmente todo agente de código moderno todavía corre. Un año después, Reflexion (Shinn y colegas, 2023) añadió memoria y autocrítica — un Actor que hace el trabajo, un Evaluator que puntúa el resultado y un paso de Self-Reflection que escribe una lección verbal en una memoria episódica que el agente lee en su próximo intento. La guía de diciembre de 2024 de Anthropic, "Building Effective Agents," nombró dos patrones más: el evaluador-optimizador (un modelo genera, un segundo verifica contra criterios explícitos, ciclando hasta que la evaluación pasa) y el orquestador-trabajadores (un modelo central divide una tarea en piezas, entrega cada una a un trabajador con contexto limpio y combina los resultados).

La razón por la que este linaje importa al arquitecto honesto es que cada uno de estos patrones es, en el fondo, una respuesta distinta a la misma pregunta: qué cuenta como "done" y quién lo verifica. ReAct repite hasta que el modelo decide parar. Reflexion repite hasta que el Evaluator pasa. El evaluador-optimizador repite hasta que un segundo modelo pasa. La progresión es hacia una verificación que cada vez menos es el agente calificando su propia tarea — y los bucles más fuertes del artículo se apoyan en un verificador determinista dondequiera que uno exista, reservando el juicio del modelo para las partes que de verdad no se pueden cuantificar de otra manera.

La anatomía de un bucle en el que se puede confiar sin supervisión

Quita el branding, dice el artículo, y un bucle fiable de verdad tiende a tener el mismo puñado de componentes: un objetivo con una condición de terminación genuinamente verificable; un conjunto de herramientas que toca el entorno real (ejecución de código, sistema de archivos, terminal, test runner, linter); gestión de contexto (porque cada iteración añade al registro y una ventana de contexto es de tamaño fijo); lógica explícita de terminación y escalamiento (una condición de éxito real, una condición de fallo real, un camino para entregar a un humano); y manejo de errores que distinga un problema recuperable de un bloqueo duro.

El esqueleto en pseudocódigo que ofrece el artículo vale la pena leerlo por la línea que hace el trabajo real: if verifier.passes(state): return success(state). Casi toda decisión de diseño interesante en loop engineering es una decisión sobre esa línea. Qué cuenta como verifier.passes — una suite de pruebas que pasa, un lint limpio, una aprobación manual humana — determina si la idea de "done" del bucle significa algo o no. Cómo funciona compact determina si el bucle sobrevive lo suficiente para terminar. Cómo se detecta no_progress evita que un agente atascado queme tu presupuesto en silencio.

Los bloques con los que la gente entrega — automatizaciones, worktrees, skills, plugins y conectores vía MCP, sub-agentes, estado externo — son la versión a nivel de herramienta de la misma idea. El que es fácil subestimar es el estado externo: el modelo no tiene memoria entre ejecuciones, así que lo que el bucle haya aprendido tiene que vivir en algún sitio durable que la próxima ejecución lee por sí sola. Suena demasiado simple para importar, y sin embargo es el mismo truco del que depende todo montaje de agente de larga duración.

La terminación es lo más caro de hacer mal

El artículo nombra tres problemas duros — gestión de contexto, terminación y verificación — y es directo en que la terminación es posiblemente el error más caro de hacer mal. Un bucle necesita varias salidas independientes apiladas: un verificador que confirme que el objetivo se cumplió, un techo duro de iteraciones, un presupuesto de tokens o de tiempo, y detección de no-progreso que atrape el caso en que los últimos pasos produjeron el mismo error o dejaron el estado sin cambios. Sin ese conjunto apilado de salidas, un bucle o corre para siempre o se detiene arbitrariamente por una suposición, y ninguno es aceptable en algo pensado para correr sin supervisión.

[ORIGINAL DATA] The 21 papers formalizan esto como la distinción entre una propiedad afirmada y una propiedad medida. Theorem 3 dice que una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Para un bucle, la propiedad es "el agente se detuvo por la razón correcta", y el mecanismo es el conjunto apilado de salidas — cada una un instrumento de medición. Un bucle con sólo una salida de verificador y ninguna de presupuesto no tiene mecanismo para "el agente está atascado", así que no tiene garantía de detenerse. Los modos de fallo que lista el artículo — desbordamiento y pudrición de contexto, bucles sin progreso, especificación errónea del objetivo (el agente que borra una prueba que falla para poner el CI en verde), éxito alucinado, explosión de coste — se reducen todos a la misma solución: una comprobación determinista, externa y real dentro del ciclo, no la palabra del agente.

El encuadre del artículo sobre la especificación errónea del objetivo vale sacarlo. Un bucle que optimiza un objetivo mal especificado perseguirá lo incorrecto con eficiencia real. El caso de manual es un agente que borra una prueba que falla para que su estado de CI se ponga en verde — el proxy pasa, el objetivo falla. Esta es la misma razón por la que nos negamos a prometer resultados de token, wallet o community-credit: Wallet & Token, Super App y Community Credit son Roadmap 🔵, pre-revenue, sujetos a revisión Howey, y cualquier bucle que los "verifique" contra un proxy está verificando el proxy, no el resultado. El arquitecto honesto nombra la madurez antes de nombrar el bucle.

Verificación: la comprobación externa es el único "done" honesto

El tercer problema duro del artículo es la verificación, y es realmente una cuestión de confianza. El patrón oro es la verificación determinista — pruebas, type checkers, compiladores, linters — porque devuelven un pase o fallo objetivo contra el que el modelo no puede argumentar. Un LLM actuando como su propio juez es más flexible y genuinamente necesario para lo que no se puede verificar mecánicamente, pero también es más manipulable, y un modelo calificando el trabajo que él mismo produjo es una verificación estructuralmente débil. Los bucles más fuertes se apoyan en un verificador determinista dondequiera que exista, y reservan el juicio del modelo para las partes de una tarea que de verdad no se pueden cuantificar de otra manera.

Esta es la misma decisión arquitectónica detrás de the Sisters y the Oracle ✅ en Everythink. The Sisters producen cada una un pronóstico; the Oracle no pregunta a the Sisters si están en lo correcto. Normaliza sus probabilidades en un ensemble calibrado, ordenado descendente, con entropía en nats, en exactamente un lugar — porque una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo, y un autoinforme no es una medición. El HAI Engine ✅ ha corrido este patrón en producción desde 2016. La lección que el vocabulario de loop engineering está alcanzando es que el verificador debe estar fuera de lo que verifica, o no es un verificador.

Human-in-the-loop es un patrón real, insiste el artículo, no un respaldo. El agente corre hasta que golpea ambigüedad genuina o una decisión con apuestas reales, pausa y espera a una persona. Es la elección correcta cuando una suposición errónea es cara de deshacer — un cambio en una base de datos de producción, una decisión frente al cliente. El modo de fallo es el opuesto a los demás: interrumpir tan a menudo que el humano no ahorra tiempo de verdad por tener un agente en el bucle.

Cómo se mapea sobre la topología de Everythink

En Everythink, el vocabulario de loop engineering se mapea sobre una topología en vez de sobre un único agente. The space is the router: una red contiene comunidades, una comunidad contiene rooms, y la room es donde una petición se enruta antes de que algo responda. Ese enrutamiento es una decisión de terminación tomada antes de que el bucle empiece — decide qué ventana de contexto, qué verificador, qué Sisters, qué herramientas aplican a una petición dada. Un bucle que corre en la room equivocada tiene el verificador equivocado por construcción, y ninguna cantidad de iteración lo arreglará, porque el bucle está midiendo la propiedad equivocada.

Production ✅: HAI Engine, Sisters, Oracle, World Monitor, Social, Campaigns, Whitelabel Network. Partial ⚠️: Matchmaking, Marketplace, Calendar. Roadmap 🔵: Wallet & Token, Super App, Community Credit — nombrados como Roadmap, nunca ascendidos en silencio, porque un bucle que verifica una capacidad Roadmap contra un proxy está verificando el proxy. Sólo alcance civil y defensivo: no construimos bucles cuya condición de terminación sea un resultado de targeting, y no lo haremos. Inclusion by design: un bucle que sólo funciona con conexión rápida es un bucle con una salida de presupuesto oculta, así que la topología enruta alrededor de la baja conectividad en vez de fallar por ella.

La soberanía del cliente es la otra mitad de la lógica de terminación. El artículo deja claro que un bucle no elimina el juicio humano; reubica dónde se aplica. Alguien sigue siendo dueño del objetivo, de la definición de done y de la decisión final. En Everythink el dueño de la red es quien posee eso — tu red, tu marca, tus datos, tu verificador. El bucle es el mecanismo; el dueño es quien decide qué significa "done" y comprueba que el verificador también lo significa.

Conclusiones clave

• El valor de un bucle lo fija su lógica de terminación y verificación, no la nitidez de ningún prompt.
• "Done" es una afirmación que debe verificarse con una comprobación externa determinista dentro del ciclo — no el autoinforme del agente. Esto es Theorem 3: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo.
• Apila las salidas: un verificador, un techo duro de iteraciones, un presupuesto de tokens o tiempo, y detección de no-progreso. Un bucle con una sola salida no tiene mecanismo para los modos de fallo que las demás atrapan.
• El linaje de investigación — ReAct (2022), Reflexion (2023), evaluador-optimizador de Anthropic (2024) — es una progresión hacia una verificación que cada vez menos es el agente calificando su propia tarea.
• La especificación errónea del objetivo es el fallo caro: un bucle que optimiza un proxy pasará el proxy y fallará el objetivo. Nombra la madurez (Production ✅ / Partial ⚠️ / Roadmap 🔵) antes de nombrar el bucle.
• The space is the router: el enrutamiento decide qué verificador aplica antes de que el bucle empiece. Un bucle en la room equivocada tiene el verificador equivocado por construcción.

Preguntas frecuentes

¿Es loop engineering sólo un nombre nuevo para prompt engineering?

No. Prompt engineering optimiza la redacción de una sola instrucción. Loop engineering diseña el ciclo que promptea, verifica, recuerda y vuelve a ejecutar un agente — y su decisión estructural es la lógica de terminación y verificación, no la redacción. El artículo sitúa loop engineering como la capa más externa, envolviendo prompt, context y harness engineering en vez de reemplazarlos.

¿Qué hace seguro a un bucle para correr sin supervisión?

Un conjunto apilado de salidas independientes: un verificador determinista que confirme el objetivo, un techo duro de iteraciones, un presupuesto de tokens o tiempo, y detección de no-progreso. Sin las cuatro, un bucle corre para siempre, se detiene por una suposición o quema recursos en un callejón sin salida. El artículo es explícito: la terminación es lo más caro de hacer mal.

¿Cómo se conecta esto con Theorem 3?

Theorem 3 dice que una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Para un bucle de agente, la propiedad es "done", y el mecanismo es el verificador determinista dentro del ciclo. Un bucle sin una salida que mida produce afirmaciones de trabajo terminado, no trabajo terminado — que es el modo de fallo "éxito alucinado" del artículo.

¿Un bucle elimina al humano del proceso?

No. El artículo deja claro que un bucle reubica el juicio humano en vez de eliminarlo. Alguien sigue siendo dueño del objetivo, de la definición de done y de la decisión final. Human-in-the-loop es un patrón real para decisiones con apuestas reales; el modo de fallo es interrumpir tan a menudo que el humano no ahorra tiempo.

¿Dónde lo usa Everythink?

The Sisters y the Oracle ✅ corren el mismo patrón: the Oracle no pregunta a the Sisters si están en lo correcto — normaliza sus probabilidades en un ensemble calibrado en exactamente un lugar. El HAI Engine ✅ ha corrido esto en producción desde 2016. The space is the router: el enrutamiento decide qué verificador aplica antes de que el bucle empiece.

Si estás diseñando una red donde agentes autónomos tienen que detenerse por la razón correcta, la topología tiene que enrutar antes de que algo responda. Crea tu red — the space is the router, y el verificador es tuyo.

Sources

• Shittu Olumide, "An Introduction to Loop Engineering," MachineLearningMastery, 23 de julio de 2026 — https://machinelearningmastery.com/an-introduction-to-loop-engineering
• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models," 2022 — https://arxiv.org/abs/2210.03629
• Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning," 2023 — https://arxiv.org/abs/2303.11366
• Anthropic, "Building Effective Agents," diciembre de 2024 — https://www.anthropic.com/engineering/building-effective-agents
• Addy Osmani, "Loop Engineering," 8 de junio de 2026 — https://addyosmani.com/blog/loop-engineering/