El alcance: este no es un punto de referencia que compara los marcos de los agentes entre sí, ni afirma que este controlador sea "más inteligente". Afirma algo más limitado y mucho más defendible: que el aislamiento del fracaso es una propiedad arquitectónica real y mensurable.
Es un patrón, no un producto: la ingeniería de bucles es un patrón de flujo de control, no un marco específico. Es el concepto de reemplazar un único mensaje gigante con un sistema iterativo que observa el estado y actúa hacia una meta.
Creado para la verificación: para probar este mecanismo en lugar de tomarlo por fe, construí una implementación pequeña y determinista de un controlador dirigido a objetivos. No requiere llamadas LLM y no tiene dependencias externas.
Aislamiento de fallas medibles: mientras una tubería lineal de un solo paso se detiene por completo en su primer obstáculo no resuelto, este controlador aísla las fallas en la rama específica que las contiene. En 300 semillas aleatorias, el controlador completó una media de 3,3 de 10,3 ramas independientes, en comparación con sólo 0,4 para la línea de base lineal.
Transparencia radical: de hecho encontré y solucioné un error real en mi propia lógica de referencia antes de confiar en estos números, y estoy analizando ese error en detalle en lugar de ocultarlo.
El oleoducto que se detuvo sin motivo alguno
Hace unos meses, vi colapsar un proceso de procesamiento de tareas en el paso tres de cuarenta.
El paso tres necesitaba un valor de configuración que aún no había establecido. Debido a ese único valor faltante, todo lo que se encuentra aguas abajo quedó ahí muerto. Eso incluía treinta y tantos pasos que no tenían absolutamente nada que ver con la configuración que faltaba.
El trabajo en sí no era imposible. El sistema colapsó simplemente porque el oleoducto no tenía la capacidad conceptual de saltarse un ramal roto y seguir avanzando por los demás.
Este no es un problema rápido. Ninguna cantidad de instrucciones reescritas para el modelo lo habría solucionado, porque el modelo nunca fue la pieza que se rompió. La falla ocurrió en el código de control. La lógica responsable de decidir qué hacer a continuación cuando las cosas iban mal no decidió nada. Simplemente dejó de funcionar.
Estoy escribiendo esto para abordar la capa completamente por encima del mensaje. Esta es la parte de un sistema agente que gestiona el estado y determina el siguiente movimiento después de que un paso tiene éxito, falla o se atasca. En los círculos de ingeniería de IA, la gente llama a esto ingeniería de bucle.
Antes de seguir leyendo, quiero ser completamente preciso sobre lo que hice y lo que no hice aquí. La precisión es el objetivo de esta pieza.
No construí un nuevo marco de agente. No comparé un LLM.
En lugar de ello, construí un software pequeño, determinista y minuciosamente probado para demostrar una única afirmación arquitectónica. Voy a mostrarles el código, exponer los errores que tuve que detectar en mi propia lógica de referencia antes de confiar en los datos y exponer los números exactos.
No espero que tomes este mecanismo por fe. Quiero que revises mi trabajo.
Código completo: https://github.com/Emmimal/loop-engine/
Qué significa "ingeniería de bucles" y de dónde proviene el término
Si pasa tiempo en Twitter, Substack o LinkedIn sobre ingeniería de inteligencia artificial, probablemente haya visto la frase ingeniería de bucle. Quiero ser preciso acerca de su origen en lugar de tratarlo como conocimiento ambiental. Atribuir erróneamente un término que cambia rápidamente es exactamente cómo se erosiona la confianza en un artículo técnico.
El ingeniero de Google, Addy Osmani, nombró y estructuró el término en un ensayo publicado en junio de 2026. Se basó en una línea del desarrollador Peter Steinberger, quien argumentó que los profesionales deberían dejar de solicitar a los agentes de codificación directamente y, en su lugar, diseñar los bucles que los solicitan. Casi al mismo tiempo, el líder de Claude Code de Anthropic, Boris Cherny, hizo un comentario similar acerca de que su propio flujo de trabajo pasó de escribir indicaciones a escribir los bucles que escriben indicaciones. El ensayo de Osmani enmarca la ingeniería de bucles como si estuviera un nivel por encima de lo que él llama por separado ingeniería de arnés, la capa relacionada con el entorno en el que se ejecuta un solo agente. Otros artículos de profesionales extienden esto a una pila más completa, impulsando la ingeniería a la ingeniería de contexto para aprovechar la ingeniería y la ingeniería de bucles, con cada capa envolviendo la anterior.
También debemos darle crédito a un predecesor técnico directo. El ingeniero Geoffrey Huntley describió la ejecución de un agente de codificación dentro de un bucle while simple en julio de 2025, un enfoque que se conoció como la técnica Ralph. La idea central, alimentar a un agente con el mismo objetivo repetidamente hasta que satisfaga una especificación escrita, es un ancestro más simple del mismo patrón exacto.
El ensayo de Osmani describe cinco bloques de construcción para un bucle de ejecución automática, automatizaciones, árboles de trabajo, habilidades, complementos y conectores, y subagentes, además del estado externo como sexto, y múltiples explicaciones cubren esa arquitectura con más profundidad que yo aquí.
Lo que estoy haciendo en este artículo es mucho más limitado. La ingeniería de bucles es el patrón general. Lo que sigue es una implementación pequeña y determinista de una sola pieza de ese patrón, construida para que puedas inspeccionar el mecanismo directamente en lugar de confiar en él.
Por qué construí esto sin llamar a un solo LLM
Cada explicación que leo sobre ingeniería de bucles supone que un LLM se encuentra dentro del bucle y toma decisiones en cada giro. Ésta es una suposición razonable para productos como Claude Code, que realmente colocan un modelo en el centro del circuito de decisión.
Pero esto crea un problema si se quiere evaluar la arquitectura en sus propios términos. Si el comportamiento del bucle depende completamente de lo que el modelo decide hacer, nunca se podrá separar completamente un buen diseño de bucle de un modelo que simplemente tuvo suerte en una ejecución específica. El no determinismo es la herramienta adecuada cuando se necesita juicio. Es la herramienta equivocada cuando se quiere verificar una afirmación sobre el flujo de control.
Entonces construí exactamente lo contrario. Escribí un bucle de control dirigido a objetivos donde una simple regla de Python maneja cada decisión en lugar de una llamada al modelo. No requiere claves API, no cuesta tokens e introduce variación cero entre ejecuciones que utilizan la misma semilla.
Si esta arquitectura ofrece una ventaja real sobre una canalización lineal de un solo paso, esa ventaja debería aparecer incluso cuando una declaración if representa la inteligencia en cada paso. Si no aparece aquí, incluir el mismo flujo de control en un LLM no haría que la afirmación subyacente fuera más cierta. Simplemente haría que el reclamo fuera más difícil de verificar.
Mantenga esta distinción específica para el resto de este artículo:
La ingeniería de bucles es la filosofía de diseño general. Se reemplaza un único mensaje grande con un sistema que observa el estado, actúa e itera hacia un objetivo. El controlador dirigido a objetivos que describo a continuación es una implementación concreta y determinista de esa filosofía. Lo construí para probar una afirmación específica sobre el aislamiento de fallas.
La combinación de estos dos conceptos convierte los artículos sobre este tema en piezas de pensamiento infalsables. Preferiría entregarte un código que realmente puedas ejecutar.
Lo que no estoy comparando y por qué ese es el alcance honesto
Antes de analizar la arquitectura, quiero hacer una comparación que este artículo no realiza. Cualquiera que haya utilizado LangGraph, CrewAI o AutoGen se preguntará razonablemente cómo se compara mi código con esos marcos.
Déjame ser claro. No estoy comparando el marco de un agente con otro. No estoy comparando GPT-5 con Claude, y no estoy evaluando la calidad del razonamiento en absoluto, ya que nada en mi código realmente razona. En cambio, estoy aislando una única propiedad arquitectónica. Quiero ver qué sucede con el resto de un flujo de trabajo cuando una parte encuentra un obstáculo que no puede resolver de inmediato.
Un ejecutor lineal representa la forma predeterminada de la mayoría de los pipelines de un solo uso y simplemente se detiene cuando encuentra un error. Un controlador dirigido a objetivos se comporta de manera diferente. Incluso un controlador completamente determinista sin modelo en su interior redirige las partes del gráfico que actualmente no puede avanzar y sigue trabajando en las partes que puede.
Ésta es una afirmación limitada y comprobable, y es la única afirmación que hago en este artículo.
La arquitectura: una máquina de estados, no una secuencia
El sistema que construí consta de dos partes. Primero, tiene un entorno, que es simplemente un gráfico de tareas con dependencias. En segundo lugar, tiene un controlador, que es la lógica que decide qué hacer con cada tarea durante cada iteración. Hice el entorno intencionalmente poco interesante. Es un gráfico acíclico dirigido simple y nada más. El controlador es el tema real de este artículo.
Diseñé una máquina de estados específica para esta configuración. Cada tarea avanza a través de este ciclo en cada iteración hasta que todo el gráfico alcanza un estado final estable:
Cada tarea aterriza en cualquier rama que requiera su estado actual, de forma independiente, en cada iteración. Este proceso continúa hasta que todo el gráfico alcanza un estado terminal en el que cada tarea se realiza, falla permanentemente o se puede demostrar que está estancada.
Nada en esta configuración requiere una secuencia fija de pasos. Esta es la diferencia mecánica real entre mi implementación y una tubería lineal. Vale la pena detenerse en este concepto por un momento porque es la fuente completa de los resultados de las pruebas comparativas que muestro más adelante en este artículo.
Un detalle de diseño específico importa mucho más de lo que parece inicialmente. Cuando una tarea necesita un recurso que aún no tiene, el controlador debe distinguir entre dos escenarios. Necesita saber si un recurso todavía se está resolviendo y necesita volver a verificarse en la próxima iteración, o si ese recurso nunca se resolverá, sin importar cuántas veces lo pregunte.
Volveré sobre este punto más adelante. Hacer esta distinción incorrecta fue el error exacto que casi me costó un punto de referencia válido.
Donde se conecta un motor de razonamiento real
Para ejecutar una tarea, el controlador llama a task.action(tarea, contexto). En esta implementación, escribí esa llamada como una función de Python simple y determinista.
Esa llamada específica es la costura. Si cambia esa función por una invocación LLM con exactamente la misma firma, puede pasar la tarea y su contexto, devolver un estado de éxito o fracaso y dejar cada dos líneas de código en el controlador sin cambios.
El bucle de flujo de control de observar, recuperar, preguntar, ejecutar, revisar o bloquear no sabe ni le importa si una regla codificada o un modelo de frontera toma la decisión final. Esta clara separación entre el flujo de control y el motor de razonamiento es el argumento arquitectónico exacto que estoy tratando de presentar. La arquitectura en sí es completamente independiente del modelo.
Construyendo un entorno que valga la pena probar
Un bucle de control sólo es interesante si le pones obstáculos reales para navegar. Para lograr esto, generé gráficos de tareas sintéticos y los sembré para lograr una reproducibilidad estricta. Estructuré estos gráficos como ramas independientes que alimentan una pequeña cantidad de tareas de integración al final. Esta configuración imita un proceso de producción del mundo real donde eventualmente se deben combinar varias piezas de trabajo no relacionadas.
Asigné aleatoriamente a cada tarea uno de seis comportamientos distintos. Utilicé probabilidades aproximadamente iguales para estas asignaciones, aunque ponderé mucho la distribución hacia el caso limpio.
Por diseño, aproximadamente una cuarta parte de las tareas son callejones sin salida permanentes. Lo hice deliberadamente. No quería apilar la plataforma hacia problemas fáciles sólo para que mi controlador se viera bien.
En todo caso, esta tasa de fracaso es increíblemente agresiva. Un verdadero proceso de producción probablemente no tenga bloqueada permanentemente una cuarta parte de sus pasos. Volveré sobre este punto más adelante, porque es vital para interpretar correctamente los resultados finales.
La línea de base con la que lo comparo
Mi punto de comparación es un ejecutor lineal estándar. Recorre las tareas en un orden de dependencia válido, intenta cada una exactamente una vez y se detiene por completo la primera vez que encuentra un obstáculo que no puede resolver de inmediato. No permite reintentos, ni desvíos alrededor de sucursales bloqueadas, ni crédito parcial por trabajo independiente que aún podría continuar.
Quiero ser explícito sobre un detalle aquí. El ejecutor lineal ejecuta tareas en un orden topológico válido en lugar de un orden de inserción sin formato. Esta elección no significa que el punto de partida sea ser inteligente. Representa el requisito mínimo absoluto para que esta comparación signifique algo.
Sin clasificación topológica, el ejecutor lineal fallaría en la tarea uno de casi cualquier gráfico simplemente porque su dependencia aparece más adelante en el archivo. Eso pondría a prueba la suerte en el ordenamiento de listas en lugar de la ejecución lineal. Más allá de ese nivel básico, el ejecutor no obtiene nada adicional. Este es el comportamiento predeterminado honesto e indefenso del código que carece por completo de un bucle de control.
El error que casi invalidó todo el punto de referencia
Quiero analizar este error en detalle. Detectar este error específico es la diferencia exacta entre un punto de referencia en el que puede confiar y uno que le miente silenciosamente.
Mi primera implementación de la búsqueda de recursos arrojó un valor booleano simple. Devolvió Verdadero si un recurso estaba disponible y Falso si no lo estaba. El problema era que False hacía dos trabajos completamente diferentes. Significa que aún no está disponible, pero verifique nuevamente en la próxima iteración un recurso que se resolverá después de algunas encuestas. También significaba que nunca iba a existir, no se moleste en buscar nuevamente un recurso que faltaba permanentemente. El controlador no tenía forma de distinguir esos dos escenarios aparte del valor de retorno únicamente.
Este defecto tuvo una consecuencia importante. Una tarea que espera un recurso lento pero eventualmente disponible se ubicaría en un estado de necesidad de recursos durante una o dos pasadas sin ningún cambio de estado visible. Mi lógica de terminación original se activaría prematuramente. Esa lógica declaraba que todo el gráfico estaba estancado si nada cambiaba el estado en una pasada completa. Como resultado, calificó erróneamente una tarea que todavía estaba avanzando legítimamente como permanentemente estancada.
Me di cuenta de esto porque mi conjunto de pruebas incluía un caso exactamente para este escenario y la prueba falló. Para solucionarlo, cambié las búsquedas de recursos y decisiones para devolver una señal de tres estados en lugar de un booleano binario: RESUELTO, PENDIENTE o FALTANTE.
Sólo un estado MISSING demuestra un bloqueo permanente. Un estado PENDIENTE significa seguir esperando. Con este cambio, el presupuesto de iteración del bucle, en lugar de una suposición heurística, decide finalmente cuándo darse por vencido.
Luego escribí una prueba de regresión y una verificación de cordura dedicada específicamente para confirmar que esta clase de error no puede volver a ocurrir. Ejecuté cada configuración de referencia con un presupuesto de iteración normal, la ejecuté nuevamente con un presupuesto cuarenta veces mayor y confirmé que el conjunto de tareas marcadas permanentemente estancadas permanecieron idénticas en ambas ocasiones. Si un presupuesto mayor alguna vez cambia el resultado, todavía estarás adivinando algo en lugar de demostrarlo. En nueve configuraciones diferentes, el resultado nunca cambió.
Incluyo esto porque es lo más honesto que puedo mostrarles sobre cómo este punto de referencia se ganó el derecho a ser confiable. Enviar un valor booleano donde realmente se necesitan tres estados es un error fácil y silencioso de cometer. Produce números que parecen completamente razonables hasta que los comparas con la verdad sobre el terreno.
Verificación de la cordura antes de confiar en un solo número
La mayoría de los artículos de referencia que leo, incluidos algunos de mis artículos anteriores, se detienen en la frase aquí está el número. Quería que este punto de referencia específico sobreviviera a una lectura escéptica. Antes de fijar un solo número, realicé cinco comprobaciones específicas con respecto a los propios supuestos del índice de referencia.
1. ¿Los modos de falla inyectados coinciden con la tasa de diseño prevista? Agregué los datos de 200 semillas y 4800 asignaciones en modo tarea. Cada uno de los seis comportamientos inyectados aterrizó dentro de medio punto porcentual de su frecuencia prevista. Los dos modos de bloqueo permanente se combinaron para exactamente el 25,2% de las asignaciones, lo que valida perfectamente mi objetivo previsto del 25,0%.
2. Cuando una tarea se bloquea, ¿puedo rastrear cada falla posterior hasta un bloqueador real inyectado? Observé una ejecución representativa en la que inyecté directamente 11 tareas como bloqueadores permanentes. Vi 9 tareas adicionales estancadas después de ellas. Rastreé con éxito cada uno de esos 9 a través del gráfico de dependencia hasta uno de los 11 originales. No encontré ningún punto muerto inexplicable.
3. ¿Los eventos de recuperación, pregunta y revisión ocurren en las proporciones esperadas? De hecho, encontré aquí un segundo problema más pequeño que vale la pena revelar. Mi primera versión de esta verificación esperaba una igualdad exacta entre la cantidad de tareas inyectadas de recursos lentos y la cantidad de recuperaciones exitosas que observé. La prueba falló. La explicación resultó ser completamente correcta y corriente. Un puñado de tareas que requieren recursos lentos, decisiones responsables y poco fiables se ubicaron detrás de una tarea diferente que se estancó primero. El controlador simplemente nunca los alcanzó. Verifiqué que el bloqueo en cascada explicaba completamente cada deficiencia, en lugar de que el controlador omitiera una tarea que debería haber completado. Después de eso, el control pasó limpiamente.
4. ¿Darle al controlador un presupuesto de iteración mayor cambia las tareas que marca como estancadas? No es así. Probé nueve configuraciones diferentes en 50 iteraciones frente a 2000 iteraciones. Esto sirvió como mi prueba de regresión directa para el error booleano versus de tres estados que describí anteriormente.
5. ¿Los resultados son estables o simplemente obtuve una muestra afortunada? Le animo a que sopese más esta verificación, porque la mayoría de los puntos de referencia la omiten por completo. Probé con 300 semillas al azar.
% de finalización del controlador dirigido a objetivos: media = 47,7 stdev = 11,8 min = 11,6 max = 74,4 % de finalización de la línea base lineal: media = 2,1 stdev = 2,7 min = 0,0 max = 14,0
La variación es real y deberías sentarte con ella por un momento. La peor semilla absoluta del controlador completó el 11,6% de sus tareas. Ese número no supera la mejor semilla absoluta de la línea de base lineal del 14,0%.
Los resultados, liderados por la métrica que realmente importa
Quiero corregir algo sobre cómo casi planteé este punto de referencia. Mi primer instinto fue liderar con tasas de finalización de tareas brutas. En una muestra de nueve configuraciones, el controlador alcanzó un 46,7 % de finalización frente al 8,3 % de la línea base lineal. A lo largo del ciclo completo de 300 semillas, esas cifras cambiaron al 47,7% frente al 2,1%.
Ésos son números reales, pero liderar con ellos invita exactamente al tipo de interpretación inflada que estoy tratando de evitar. Te tienta decir algo así como que el controlador es 20 veces mejor, lo cual no es lo que realmente demuestra este mecanismo.
La métrica que realmente aísla el reclamo arquitectónico es el número de sucursales independientes completamente completadas:
Ramas completamente completadas (promedio en 9 configuraciones predefinidas) Controlador dirigido a objetivos ################# 3,3 / 10,3 Línea de base lineal ## 0,4 / 10,3
El controlador no era mejor porque resolvía tareas imposibles. Era mejor porque se negaba a permitir que una sola tarea imposible detuviera todas las demás tareas posibles. Ésa es toda la contribución, expresada con la mayor precisión posible. Preferiría que recordaras esa frase que cualquier porcentaje.
Así es como se ve iteración por iteración, usando una configuración representativa de 10 ramas que ejecutan 4 tareas en profundidad:
Observe cómo la columna de Espera pasa de 25 a 0 mientras que Listo sube de 6 a 23. Observe cómo Recuperados y Preguntados aumentan en las iteraciones exactas en las que el controlador resolvió un recurso o una decisión que había estado bloqueando una rama.
Un ejecutor lineal produce exactamente una línea en total. En las nueve configuraciones que probé, se detuvo en la segunda o tercera tarea de la primera rama en cinco de ellas, y en la primera tarea de la segunda rama en las otras cuatro, y nunca alcanzó la mayoría de las ramas en una sola ejecución, independientemente de si hubieran tenido éxito limpiamente.
Quiero ser preciso sobre ese último punto porque explica la mayor parte de la brecha en las cifras. El tamaño de esta brecha es en parte una propiedad de mi diseño de escenario, que impone una parada brusca y ningún intento adicional. No se trata de afirmar que el responsable del tratamiento sea, en términos generales, más capaz.
Lo que evidentemente hace el controlador es convertir una falla catastrófica, de todo o nada, en una falla parcial y aislada. Esto representa una propiedad de ingeniería real y útil. No es en absoluto lo mismo afirmar que llamar al sistema más inteligente.
Lo que este punto de referencia no muestra
Para evitar exagerar estos resultados, permítanme ser claro. El controlador no completa el 100% de las tareas, y se supone que no debe hacerlo. En ambos sistemas siguen sin resolverse recursos que faltan permanentemente y decisiones realmente sin respuesta. Ningún patrón de flujo de control, ya sea determinista o basado en modelos, puede recuperar un recurso que no existe o responder una pregunta sin respuesta disponible. Aproximadamente la mitad de las tareas en una ejecución típica quedan sin resolver exactamente por esa razón.
Esto tampoco es una afirmación de que los bucles de control deterministas sean suficientes para sistemas agentes reales. La mayoría de los bucles de agentes de producción necesitan un modelo o un ser humano que tome decisiones en algún paso. Esta es precisamente la razón por la que mi arquitectura aísla ese paso como una llamada de función única e intercambiable en lugar de incorporar una estrategia de razonamiento específica en el flujo de control mismo.
Finalmente, este no es un punto de referencia de la ingeniería de bucles en su conjunto. Ese término cubre la programación, la memoria persistente, la separación entre el verificador y el generador y varias otras preocupaciones que este pequeño sistema no aborda en absoluto. Lo que he demostrado aquí es una propiedad única, que aislé a propósito para que puedas comprobarla.
Cómo saber si su propia tubería necesita este patrón
Si está creando canales de agentes y se pregunta si algo de esto se aplica a usted, aquí está la lista de verificación honesta que uso, basada en lo que me enseñó la construcción de este sistema.
Probablemente tengas un problema de ejecutor lineal si coincides con estos signos:
Un solo paso fallido en cualquier parte de su canalización anula todos los pasos posteriores, incluidos los pasos que no tienen dependencia del que falló. Su lógica de reintento es un intento general de volver a intentar todo el proceso en lugar de un sistema que identifica qué paso específico necesita otro intento. No puede responder a la pregunta de qué partes independientes de este trabajo terminaron realmente después de un fallo parcial, porque su registro sólo le indica dónde se detuvo la ejecución. Agregar una nueva rama de trabajo independiente a la tubería significa que debe modificar el manejo de fallas para cada rama existente, en lugar de que la nueva rama simplemente se conecte al mismo bucle de control.
Puede omitir con seguridad un controlador dirigido a objetivos si su situación se ve así:
Su canalización es completamente secuencial. Si cada paso realmente depende del anterior, no tienes ramas independientes. Cuando no hay nada que aislar, el aislamiento de fallas es inútil. Los gastos generales de ingeniería son demasiado altos. No construya ni mantenga una máquina de estados compleja si volver a ejecutar una tubería corta desde cero es barato. Si tiene un trabajo de cinco pasos que finaliza en menos de un segundo, limítese a un ejecutor lineal con un simple reintento de nivel superior. Es simplemente más fácil de mantener. Su verdadero obstáculo es la calidad del juicio. Este patrón no solucionará la falta de precisión o las malas decisiones en un paso específico. Sólo gestiona lo que sucede después de que falla un paso. Ése es un problema de razonamiento, no un problema de flujo de control. Ningún diseño de bucle inteligente hará que su modelo sea más inteligente.
Si realmente desea construir esto, tres opciones de diseño específicas harán o desharán el sistema. Si se equivoca, le afectarán absolutamente en la producción.
Así es como se clasifican según el daño potencial:
Nunca infieras el estatus a partir del comportamiento. Debe distinguir "todavía funcionando" de "permanentemente atascado" directamente en el nivel de datos. Un retorno booleano de una verificación de preparación es una trampa absoluta. Si un solo Falso significa tanto un retraso temporal como una falla permanente, su sistema no puede tomar decisiones inteligentes. Utilice un tercer estado explícito. No confíe en las heurísticas de terminación. Es fácil asumir que nada cambió en la última pasada, por lo que nada cambiará jamás. Eso está mal. Falla exactamente cuando necesita que funcione: sondeos, retrocesos o espera de API externas. Su bucle necesita realizar un seguimiento del estado físico, no de conjeturas de tiempo. Aísle el paso de razonamiento. Envuelva todo lo que decida el siguiente paso detrás de una única interfaz intercambiable. Al flujo de control central no debería importarle si se trata de una regla de Python, una llamada de LLM o una devolución de llamada humana. Mantener este límite completamente limpio es la única razón por la que podría comparar la arquitectura de forma aislada.
Código completo: https://github.com/Emmimal/loop-engine/
Recursos
Addy Osmani, “Loop Engineering”, junio de 2026. El ensayo que nombró y estructuró el patrón. https://addyosmani.com/blog/loop-engineering/ Hagamos ciencia de datos. Los ingenieros adoptan la ingeniería de bucles para agentes de IA. Informe sobre la entrevista CNBC de Boris Cherny (a través de Business Insider), la publicación X de Peter Steinberger y comentarios relacionados. https://letsdatascience.com/news/engineers-embrace-loop-engineering-for-ai-agents-cb1a1d6a Geoffrey Huntley, “Ralph Wiggum como 'ingeniero de software'”, julio de 2025. La publicación original que describe la técnica de Ralph. https://ghuntley.com/ralph/ Tosea.ai, "¿Qué es la ingeniería de bucles? Una guía completa desde Prompt hasta Harness Engineering", 16 de junio de 2026. Fuente de la progresión de la capa de aviso a contexto a arnés a bucle a la que se hace referencia anteriormente. https://tosea.ai/blog/loop-engineering-ai-agents-complete-guide-2026 Guía de campo de la comunidad DEV que sintetiza fuentes profesionales sobre bucles agentes, incluida la técnica Ralph y trabajos relacionados. https://dev.to/truongpx396/the-agentic-loop-a-practical-field-guide-mnc Adnan Masood, “Loop Engineering: A Guide for Engineers and Practitioners”, Medium, 24 de junio de 2026. https://medium.com/@adnanmasood/loop-engineering-a-guide-for-engineers-and-practitioners-893bb65ea943
Divulgación
Todo el código de este artículo fue escrito por mí y es un trabajo original, desarrollado y probado en Python 3.12.10. Los números de referencia provienen de ejecuciones reales en mi máquina local (Windows, solo CPU) y se pueden reproducir clonando el repositorio y ejecutando benchmark.py y sanity_check.py, excepto cuando el artículo señala explícitamente que un número es un objetivo de diseño en lugar de un resultado observado (verificado con tasas reales en la verificación de cordura). Este proyecto tiene cero dependencias externas; Todas las funciones se ejecutan únicamente en la biblioteca estándar de Python, sin llamadas LLM en ninguna parte del punto de referencia. No tengo ninguna relación financiera con ninguna herramienta, biblioteca o empresa mencionada en este artículo.