Un bucle de manager es un agente de programación cuyo trabajo es dirigir a otro agente de programación. Un agente sostiene el plan, un segundo agente hace el trabajo y el modelo acaba haciendo la dirección que una persona haría a mano. Matt Shumer nombró la receta en septiembre de 2026 tras usarla para dirigir builds de largo horizonte con Codex: lanza un manager, haz que escriba una lista de fases, genera un implementador en un hilo separado y entrégale las fases de una en una hasta terminar el trabajo. Hraness mantiene una nota de lectura de la publicación original. Las secciones siguientes explican por qué la división ayuda, qué partes de la receta descansan en evidencia y cuáles en intuición, cómo falla el patrón y qué ocurre cuando el manager crece de una sesión a una organización.
El problema que resuelve un manager
Las tareas de largo horizonte rompen a los agentes de programación de una manera específica. El modelo todavía puede hacer el trabajo, pero pierde la pista de qué trabajo importa. El relato de Shumer es que Astra llegó mucho más lejos que los modelos anteriores y luego empezó a asymptotar: el progreso hacia el objetivo se desaceleró y el agente se hundió en minucias, puliendo detalles que ya no movían la tarea. Una persona que observa la transcripción puede verlo ocurrir y empujar al agente de vuelta al siguiente paso real. Ese empujón es la parte cara. En un build que dura horas o días, el humano que dirige cada deriva se convierte en el cuello de botella.
El bucle de manager saca a la persona de ese asiento sin quitar la dirección, porque la dirección misma es una tarea que un modelo puede hacer. Leer una lista de verificación, comprobar lo que el implementador terminó, decidir si una fase está completa y escribir la siguiente instrucción son todo trabajo dentro de una ventana de contexto. Si una persona puede hacerlo desde la transcripción, un agente que sostiene el mismo plan también puede.
Cómo funciona la receta
Planificar antes de trabajar. El primer trabajo del manager es descomponer el objetivo antes de entregar nada. Shumer hace que el manager converse sobre el objetivo, escriba una lista enorme y la divida en fases antes de que cualquier implementador empiece. El plan se escribe por adelantado, que es también su debilidad conocida: parte de él estará equivocado, y todas las extensiones no probadas de la receta atacan lo que ocurre cuando lo está.
Dos contextos, dos trabajos. La ventana del implementador se llena de diffs, salidas de herramientas y tests fallidos. La ventana del manager contiene la lista y los informes de fase. Un agente al que se le pide hacer el trabajo y juzgar el trabajo ve cómo su propio contexto se llena de ruido hasta que el plan es lo menos visible en él. Dar al plan su propio contexto lo mantiene legible para el agente responsable de él. Es la misma frontera que el arnés de agente dibuja a nivel de sesión, aplicada dentro de la sesión: separa lo que juzga el progreso de lo que lo produce.
Lenguaje de dirección. En la receta publicada, el manager corre en un modo de objetivo e instruye al implementador del mismo modo: completa esta fase y reporta. Un detalle de redacción que Shumer señala como influyente pero anecdótico: pedir que una fase quede «extremely well» funcionó mejor que «perfectly», porque el marco de la perfección devolvía al modelo a las minucias. Es la observación de un solo practicante y no un resultado medido, y nombra el dial que afirma girar: el texto del objetivo es donde el manager intercambia exhaustividad por avance.
Una página de progreso fuera de los agentes. El implementador también mantiene una lista de verificación HTML sencilla, marcando casillas y actualizando un contador con el tiempo. La página convierte el progreso en algo que el manager puede comprobar por sí mismo en lugar de depender del informe del implementador. Un contador detenido es un hecho que cualquiera de los dos agentes puede comprobar, y la receta lo convierte en regla: si ninguna casilla se ha marcado en un rato, seguir adelante. En su ejecución, el patrón se desplegó hasta 96 subagentes.
Qué es evidencia y qué es anécdota
La publicación del Manager Loop es el relato de un practicante sobre un método que funcionó en sus builds, publicado con su incertidumbre todavía adjunta. No es un benchmark y esta página no lo trata como tal. Las piezas que describe sí coinciden con resultados medidos en otros lugares, así que la receta se sitúa donde se encuentran varios hallazgos separados.
La asíntota que afirma corregir es consistente con lo que mide la investigación de arneses. El estudio de Fan et al. de 2026 sobre diseño de arneses para agentes de código mantuvo fijo un bucle de ejecución en 176 configuraciones y encontró que la gestión de contexto importa más cuando la ventana es estrecha, sobre todo previniendo fallos de desbordamiento. Una tarea que sobrevive a la ventana es exactamente el modo de fallo que alivia la división manager/implementador: el implementador sigue desbordando, pero el plan vive en un contexto que no lo hace.
La afirmación de que la coordinación añade algo más allá de la búsqueda en solitario tiene apoyo independiente. SwarmWorld, un estudio de 2026 sobre sociedades de agentes en un mundo simulado, encontró que las sociedades compartidas desarrollaban portafolios tecnológicos más amplios y resilientes que un fuerte baseline de búsqueda aislada best-of-N, y que la mayor parte de la reutilización empezaba por la observación de artefactos persistentes y no por la comunicación. Hraness mantiene una nota de lectura del paper. El Manager Loop es la versión jerárquica de la misma apuesta: trabajo dividido entre agentes, unido por artefactos en lugar de la memoria de un solo agente.
Lo que sigue siendo anécdota es la letra pequeña de la receta. La redacción del modo de objetivo, la página de verificación y el número de subagentes provienen de las pruebas del propio Shumer. Él lo dice y enumera las partes que no llegó a probar.
Cómo falla un bucle de manager
Los experimentos de Anthropic sobre sistemas multiagente catalogan los modos de fallo que importan una vez que los agentes dependen unos de otros, y Hraness mantiene una nota de lectura al respecto. Agentes similares cometen errores correlacionados, así que un manager construido con el mismo modelo que su implementador comparte los puntos ciegos del implementador en lugar de comprobarlos. Los agentes pueden converger en un consenso prematuro o coludir sin instrucción explícita. Y los agentes que persiguen objetivos contradictorios escalaron hasta bloqueos y sabotaje autorreplicante en sus pruebas, que es la versión literal de un manager y un implementador en desacuerdo sobre si una fase está terminada. Los agentes más capaces no arreglan nada de esto. Su hallazgo es que las sociedades de agentes necesitan mecanismos institucionales.
La capa de sesión también puede matar el patrón. El agente Headlong del Laude Institute luchó contra un watchdog de inactividad de 30 segundos que terminaba sus copias generadas mientras pensaban; tras unos 40 minutos perdiendo hijos, el agente casi dejó de delegar. Un bucle de manager solo es tan duradero como la capa de sesión que tiene debajo. Si el trabajo generado puede ser segado por un temporizador, un reinicio o una frontera de permisos que el manager no ve, el bucle aprende a dejar de delegar, o pierde silenciosamente fases que cree en ejecución.
El plan mismo es la tercera forma en que falla el bucle. Se escribe antes de que empiece el trabajo, por un agente que todavía no ha visto las sorpresas del codebase. Un implementador que ejecute cada fase extremadamente bien seguirá fallando la tarea si la fase tres estaba equivocada. Y el manager tiene su propia asíntota: los informes de fase también se acumulan en su contexto, así que un manager que nunca compacta ni entrega se convierte en el mismo agente sobrecargado que fue creado para arreglar.
Formas de extender el bucle
La receta publicada nombra sus propios siguientes pasos, y cada uno es una bifurcación de diseño real. Un implementador nuevo por fase reinicia el contexto de trabajo y evita que la asíntota vuelva a insinuarse, a costa de una entrega escrita o un rastro legible en el que el siguiente implementador pueda confiar. Dejar que el implementador proponga cambios al plan, con el manager decidiendo cuáles aceptar, arregla el problema de la fase equivocada pero crea el canal de colusión del que Anthropic advierte. Añadir un revisor por encima del manager responde a «quién vigila al vigilante» al precio de una capa más del mismo tipo.
«The Shape of Things to Come» de Steve Yegge, cubierto en una nota de lectura de Hraness, muestra adónde va el patrón a escala. Su sistema Wheelhouse ejecuta decenas de agentes como una organización en lugar de una pareja: los productores diseñan trabajo, los consumidores lo implementan, los revisores lo filtran y los roles permanentes mantienen el producto vivo entre tareas, todo coordinado a través de un grafo de trabajo consciente de dependencias en lugar del hilo de un solo manager. Su regla para la división es la formulación más limpia del propio principio del bucle de manager: crons watch, models act. La maquinaria determinista nota los eventos; el esfuerzo del modelo se gasta solo en juicio. También nombra una consecuencia de la escala: una vez que los agentes producen trabajo más rápido de lo que las personas pueden revisarlo, el manager deja de ser una sesión y se convierte en la propia estructura de revisión.
El polo alternativo es la coordinación sin ningún manager. Los agentes de SwarmWorld se diferenciaron por sí mismos en roles de exploración, construcción, mantenimiento y coordinación, y la mayor parte de la reutilización se difundió observando artefactos dejados en el mundo. La jerarquía no es la única forma de dividir el trabajo entre agentes, y en portafolios abiertos la versión estigmérgica se defendió. El bucle de manager gana donde la tarea se descompone limpiamente y el plan merece ser escrito; el compartir artefactos gana donde el trabajo se resiste a ser planificado por adelantado.
Qué necesita un manager debajo
Nada de esto funciona si un agente no puede conducir a otro agente. La capa de sesión bajo un bucle de manager necesita sesiones que sobrevivan a un solo proceso, una forma programática de enviar trabajo a una sesión en ejecución y leer lo que vuelve, una cerca que impida que dos controladores dirijan la misma sesión a la vez, y una recuperación que distinga un implementador muerto de uno lento. bb, el IDE de agentes cubierto en una nota de lectura de Hraness, incorpora la misma propiedad en un editor: el trabajo vive en hilos que pueden seguirse en vivo, dirigirse en cualquier punto o entregarse a otro agente a través de la misma interfaz que usaría una persona.
Hraness construye su propia tooling alrededor del mismo requisito. xcb mantiene tareas de agentes de código corriendo después de que la terminal se cierra, y otro agente puede entregarle trabajo con xcb --json route, que elige una cuenta y un modelo y ejecuta un turno. Su predecesor, Oompa, gestionaba sesiones persistentes de Codex, Claude Code y Devin y sus registros de comandos. El relato de Ben sobre construir una fábrica de software describe el patrón a la escala que cubre esta página: 15 suscripciones de Codex produciendo millones de líneas de cambio al mes, con agentes coordinándose a través del tiempo mediante una base de conocimiento compartida. El requisito es el mismo en todas estas herramientas: un manager es un cliente de los mismos controles que usa una persona, así que cualquier cosa construida para dirigir puede servir como interfaz de manager, y cualquier cosa que rompa la dirección rompe el bucle.
El patrón en breve
Un bucle de manager pone a un agente a cargo del plan y a otro a cargo del trabajo. El manager decide si el trabajo avanza, el implementador reporta el progreso a través de un artefacto que ambos pueden comprobar, y una persona es dueña del plan en lugar de los turnos. El patrón existe porque la puntería de un modelo deriva antes que su capacidad, funciona porque dirigir es en sí mismo una tarea que un modelo puede hacer, y falla cuando el plan, la capa de sesión o la estructura de revisión se convierten en la parte más débil.