Loop engineering: los agentes ya montan su propio bucle
Qué significa que un agente ejecute su propio bucle de tareas sin esperar aprobación, los cinco componentes que lo sostienen y los controles que hay que montar antes de ponerlo en producción.
El agente que empieza a trabajar a las ocho de la mañana
Imagina un agente de código. A las ocho de la mañana, sin que nadie le diga nada, se pone a trabajar. Revisa los fallos de ayer, escribe la corrección y asigna un segundo agente para que revise su propio trabajo.
Anthropic probó este montaje dentro de su propio equipo de ingeniería en los últimos meses. La proporción de pull requests que recibían un comentario de revisión relevante pasó del 16 al 54 por ciento, y los ingenieros discutieron menos del 1 por ciento de los hallazgos. Lo que me interesa no son los porcentajes: ya no hay una persona en cada eslabón de la cadena.
Este montaje tiene nombre, loop engineering. La idea es sencilla. Una vez que el agente tiene su tarea, no espera aprobación en cada paso: se dirige a sí mismo y saca el trabajo adelante.
Primero, el flujo clásico
¿Qué hace un agente exactamente? Recoge la tarea que se le ha dado, elige las herramientas que puede usar, planifica los pasos y produce un resultado. Hasta aquí, todo conocido.
El flujo al que estamos acostumbrados es este: una persona arranca el agente, le da la tarea, el agente trabaja y presenta el resultado. La persona lo revisa, lo aprueba y quizá le da una tarea nueva. En cada eslabón hay una intervención humana.
Ese flujo da tranquilidad, sin discusión. Lo que cuesta es velocidad y autonomía. Loop engineering cambia la pregunta justo en este punto: ¿algunos trabajos necesitan de verdad a una persona en cada paso?
Por qué la palabra es "loop"
La fuerza de la palabra está aquí: las tareas se disparan entre sí. Cuando termina una, el agente decide cuál es la siguiente y la arranca él mismo.
Observación, razonamiento, ejecución y evaluación se van encadenando. El agente ve el resultado, se vuelve a promptear a sí mismo y da la misma vuelta hasta llegar al objetivo. El prompt manual queda sustituido por automatización atada a un objetivo.
Aquí hay un matiz que se suele pasar por alto. La persona no desaparece del todo: arranca el bucle y marca la dirección general. A partir de ahí, el agente mantiene el flujo.
El alcance se desplaza de la persona al agente
El mejor marco para entender esto es el desplazamiento del alcance. Cuanto más trabajo le pides a los agentes, más se mueve de la persona al agente la iniciativa de empezar ese trabajo.
Al principio una persona definía cada tarea. Después los agentes empezaron a hacer una tarea entera de principio a fin. Con loop engineering damos un paso más, porque el agente decide por su cuenta cuál es la tarea siguiente.
Esto es una inercia, no un salto puntual. A medida que la iniciativa pasa al agente tú te apartas del trabajo básico, pero la responsabilidad se mueve con él. Por eso la sección sobre control está al final de este artículo.
Los cinco componentes que sostienen el bucle
Loop engineering no se monta con una sola herramienta. Sale de cinco componentes trabajando juntos, y cada uno cubre una debilidad distinta del bucle.
Automation: lo que realmente arranca el bucle
La idea es conocida. Igual que las tareas cron de tu sistema ejecutan un comando a una hora concreta, aquí una hora o un intervalo le indican al agente que se ponga a trabajar.
A un agente de código se le promptea a las ocho para que mire GitHub y revise los fallos de CI del día anterior. Otra programación le pide priorizar las issues recién abiertas, y otra lo manda a cazar errores que crecen en silencio dentro del proyecto.
El disparador no tiene por qué depender del reloj. Un pulso corto medido en segundos, un evento que llega de un webhook o directamente un objetivo también pueden arrancar el bucle. Lo que tienen en común: ninguno espera a que una persona diga "haz esto ahora".
Work tree: cada agente en su propia isla
Piensa en el worktree de git. El agente tiene un directorio de trabajo aparte sobre su propia rama, y los cambios que hace no tocan el entorno de los demás agentes.
¿Por qué nos importa? Todos hemos visto cómo un cambio mínimo en un proyecto web afecta a otros componentes. Multiplica eso, porque puede haber varios agentes ejecutando varias tareas a la vez. Sin aislamiento, el cambio de uno rompe el runtime del otro.
La garantía de fondo es esta: cuando el agente rompe algo, rompe una copia y no tu rama principal. La buena noticia es que la mayoría de los agentes de código de hoy ya traen ese soporte.
Skills: el conocimiento del oficio, a mano
Un skill es un archivo escrito en markdown. Dentro están los métodos para hacer un trabajo concreto y los límites dentro de los que hay que moverse. Piénsalo como la alternativa a pegar un muro de instrucciones cada vez: pones el conocimiento en un archivo una sola vez y el agente lo llama cuando lo necesita.
La parte elegante está en cómo se carga. Al arrancar, el agente solo ve el nombre y la descripción corta de cada skill, unas pocas decenas de tokens. El cuerpo del archivo espera en disco hasta que ese skill se dispara. Así puedes llevar cientos de skills encima sin llenar tu ventana de contexto.
Plugins y connectors: la puerta al mundo exterior
Separar esto de los skills importa. Los skills dan conocimiento, los plugins dan acceso.
Un agente de código puede llegar a los documentos de Notion, a los datos de pago de Stripe o a la base de datos de la empresa. Estas conexiones se montan normalmente sobre un protocolo estándar como MCP, y a qué sistemas se abre es una decisión que tomas proyecto a proyecto.
Con loop engineering este componente pesa más. Un agente plenamente autónomo no puede terminar su trabajo solo con archivos locales: necesita alcanzar los sistemas externos de los que depende la tarea. Cuanto más se amplía el acceso, mayor es el radio de impacto del agente.
Sub agents: divide el trabajo y luego hazlo auditar
El agente principal parte la tarea en trozos, asigna subagentes, y estos trabajan y reportan el resultado. En el contexto de un bucle, esta estructura hace dos cosas.
La primera es velocidad. Cuando una tarea grande se reparte, los subagentes trabajan en paralelo, y como cada uno abre con una ventana de contexto limpia, la memoria del bucle principal no se llena.
La segunda, para mí la más valiosa, es la revisión independiente. En las mediciones de Anthropic, el 84 por ciento de los cambios de más de mil líneas generó hallazgos, con una media de 7,5 problemas por cambio. En los cambios de menos de cincuenta líneas la proporción bajó al 31 por ciento y el número de problemas a 0,5. El tiempo medio de revisión rondó los 20 minutos. Cuanto más grande es el trabajo, más falta hace un par de ojos externos, y no de forma lineal.
No hay una única estructura correcta
Aclaremos una cosa: no existe un organismo oficial ni un estándar rígido que defina qué constituye exactamente loop engineering. Es un campo que se está desarrollando en directo y toma formas distintas en cada proyecto.
Un buen ejemplo. Algunos montajes añaden una capa de memoria encima de los cinco componentes. Al final de cada vuelta el agente escribe lo que ha hecho en un archivo markdown o en un tablero de tareas, y en la vuelta siguiente continúa desde ahí. La función real de esa capa no es recordar el pasado, sino evitar que cometa el mismo error dos veces.
Las estructuras cambian, pero el fondo se mantiene: el alcance crece desde la iniciativa humana hacia la iniciativa del agente.
Cuanto mayor es el alcance, más se acumulan los errores
Esta es la parte más importante del artículo. Cuanto más trabajo hace el agente por su cuenta, mayor es el riesgo de que se acumulen errores que nadie ha visto. A medida que la persona se aleja del bucle, quedan menos ojos para detectar un fallo.
El peligro real es que los errores se sumen unos a otros. Una decisión equivocada pequeña crece sin que se note en el paso siguiente, y unas cuantas vueltas después tienes un resultado cuyo origen no sabes rastrear. Por eso los mecanismos de control y equilibrio, los checks and balances, se montan a la vez que el bucle. El control añadido después no deshace los errores ya acumulados.
En la práctica se traduce en tres cosas:
- Pon un techo de vueltas al bucle. Unas cincuenta vueltas es un valor de partida razonable, no un hallazgo de investigación.
- Ata la condición de salida a una medida dura y no al criterio del propio agente. Cero tests fallando, por ejemplo.
- Añade un paso de verificación independiente que revise todo el código base, no solo el código que se acaba de producir.
Para cerrar
Loop engineering es el nombre que reciben los bucles de tareas en los que los agentes se dirigen a sí mismos sin aprobación humana. Automation ata el bucle a un momento o a un evento, work tree evita las colisiones, skills hace persistente el conocimiento, los plugins abren la puerta a los sistemas externos, y los sub agents dividen el trabajo y además auditan al agente principal. Si quieres, añade encima una capa de memoria y dale al bucle memoria entre vueltas.
Pero antes que nada: no pongas el bucle en producción sin checks and balances. Con ellos montados, el agente le da fuerza a tu flujo de trabajo. Sin ellos, se convierte en una carga nueva que tendrás que limpiar.
Fuentes
- El sistema de revisión de código con agentes de Anthropic, resultados del despliegue interno y hallazgos por PR
- Qué es loop engineering, definición del concepto y su lugar en los flujos de agentes autónomos (IBM Think)
- Construir bucles de agentes que se ejecutan solos, tipos de disparador, techo de vueltas y condición de salida
- Loop engineering y agentes de código, los componentes de automatización, worktree, skills, connector y subagentes
- Documentación de Agent Skills, estructura del archivo de skill y carga progresiva