Cómo funciona el bucle agéntico de Claude Code

Claude Code no sigue una lista fija de pasos: repite un ciclo hasta que la tarea termina. Esta página explica cómo funciona ese ciclo y cuándo vale la pena dividir el trabajo entre varios agentes — y cuándo eso solo crea más problemas de los que resuelve.

¿Qué pasa en cada vuelta del bucle?

Un agente de Claude Code pasa por tres fases en cada vuelta: reúne contexto (lee archivos, ejecuta un comando, consulta una tool), toma una acción (edita código, ejecuta una prueba, llama a una tool) y verifica el resultado antes de decidir el siguiente paso. No existe una cuarta fase fija de "planificar" ni una de "hacer deploy" — el bucle son esas tres fases, repetidas tantas veces como la tarea lo pida.

Por eso dos tareas parecidas gastan números de iteraciones muy distintos: renombrar una variable usada en tres archivos puede cerrarse en una sola vuelta, mientras que depurar una prueba que falla de forma intermitente puede llevar diez, porque cada intento de corrección necesita verificarse antes del siguiente.

Cuándo vale la pena abrir un subagente

Un subagente se ejecuta en una sesión separada y devuelve solo un resumen al contexto principal — la exploración ruidosa (archivos leídos, comandos que fallaron, callejones sin salida) queda fuera. Eso mantiene la sesión principal ligera incluso en tareas grandes.

La regla que decide si vale la pena: la tarea delegada tiene que ser acotada y verificable. "Revisa la seguridad de estos 40 archivos independientes" se divide bien entre subagentes porque cada parte tiene un criterio de éxito claro. "Mejora el backend" no se delega bien a nadie — ni a un subagente, ni a una persona — porque no existe criterio para saber cuándo terminó.

Delegar también es decidir qué modelo usa cada subagente. Una tarea mecánica — renombrar una variable en todo el proyecto — no necesita el modelo más caro disponible; una tarea que exige juicio sobre compromisos arquitectónicos sí lo necesita. Enrutar hacia el modelo más barato que aún resuelve la tarea correctamente es parte del diseño de la delegación, no un ajuste de costo aparte.

Por qué ejecutar agentes en paralelo no siempre funciona

El fan-out — lanzar varios subagentes al mismo tiempo — solo funciona cuando las partes son realmente independientes. Dos tareas que tocan el mismo archivo, o que dependen del resultado una de la otra, fallan en paralelo del mismo modo en que fallarían si dos personas editaran el mismo archivo a la vez sin coordinarse antes.

Ejecutar varias sesiones sobre el mismo repositorio tiene un problema concreto: compiten por el mismo working tree. Los git worktrees resuelven esto dando a cada sesión su propia copia de trabajo, todas apuntando al mismo repositorio — sin el riesgo de que una sesión pise lo que otra estaba editando.

Por qué vale la pena que un segundo agente revise al primero

Pedirle al mismo agente que revise su propio trabajo tiene un sesgo estructural: tiende a confirmar las decisiones que acaba de tomar. Un segundo agente, en una sesión separada y sin ver el razonamiento del primero, tiene más probabilidad de detectar un error real porque no arrastra el mismo punto ciego.

Eso solo reduce falsos positivos de verdad si el agente verificador es independiente — contexto propio, no el resumen del primero — y tiene un criterio objetivo para juzgar. Sin esas dos condiciones, la "verificación" se vuelve solo una segunda opinión sesgada por la primera.