tl;dr Todo agente de IA en CLI es, en el fondo, un while que repite: llama al modelo → ejecuta herramientas → mete el resultado de vuelta → vuelve a llamar al modelo, hasta que no quedan herramientas que llamar. Eso es la teoría. Lo interesante es para qué se está usando ese bucle de verdad: correr tareas autónomas mientras duermes, reiniciar el contexto en cada vuelta para que el modelo no se vuelva tonto (la técnica Ralph), poner topes de gasto y de iteraciones (loop engineering), y encadenar equipos de agentes que planifican → codifican → prueban → abren un PR sin que toques el teclado. Aquí va el panorama real, con sus límites y su factura.

Cuando ves a un agente de terminal como Claude Code “trabajar solo” —leer archivos, editar código, correr los tests, arreglar lo que falló y volver a correrlos— parece magia. No lo es. Debajo hay una de las estructuras más viejas de la programación: un bucle. Pero la pregunta que me interesa en este post no es cómo funciona el loop (eso se explica en cinco minutos), sino para qué lo están usando realmente los que llevan estos agentes al límite. Porque entre el diagrama de manual y lo que pasa en producción hay un abismo.

Manifiesto de ética de siempre: un loop de agente es un sistema estocástico ejecutando acciones reales sin un humano revisando cada paso. Mientras más larga la cadena, más lejos llega antes de que alguien lo note. Diseña con topes, registra todo y pon checkpoints humanos antes de cualquier acción irreversible. Volveremos sobre esto al final.

---

1. El loop, en su versión honesta

Todo agente en CLI sigue el mismo ciclo. La documentación del Agent SDK de Anthropic lo describe en cinco pasos que se repiten:

1. Recibe el prompt junto con el system prompt, las definiciones de herramientas y el historial.
2. Evalúa y responde. El modelo decide: o contesta texto, o pide una o más llamadas a herramientas, o ambas.
3. Ejecuta las herramientas y recoge los resultados.
4. Repite. Los pasos 2 y 3 forman un turno. El modelo sigue llamando herramientas y procesando resultados…
5. …hasta que produce una respuesta sin llamadas a herramientas. Ahí el loop termina y te devuelve el control.

Dicho en una línea: model call → tool execution → result injection → next model call, girando hasta que el modelo dice “listo”. Es literalmente un while (hay_tool_calls) { ... }. La arquitectura de Claude Code es justo eso: un single-threaded master loop, un solo hilo con un historial plano de mensajes, evitando a propósito la complejidad de múltiples personalidades de agente compitiendo.

Esto se resume a menudo como el ciclo Razonar → Actuar → Observar (heredado del patrón ReAct de 2022). Bonito en el diagrama. El problema aparece cuando lo sueltas a correr de verdad.

---

2. Por qué el loop “de manual” no alcanza

En 2023, AutoGPT popularizó la idea de dejar un loop corriendo solo hacia una meta. Y fue un desastre célebre: bucles infinitos, costos disparados, agentes dando vueltas sin avanzar. El loop ingenuo tiene tres enfermedades crónicas:

• No sabe cuándo parar. Sin un criterio claro de terminación, sigue hasta agotar tu presupuesto o tu paciencia.
• Se vuelve tonto con el contexto lleno. Los LLMs empiezan a degradarse alrededor del 40% de la ventana de contexto ocupada. Cuanto más larga la sesión, más basura acumulada y peores decisiones.
• Repite errores. Sin memoria de lo que ya falló, tropieza con la misma piedra.

De ahí que el campo madurara hacia algo que hoy se llama loop engineering: dejar de pensar en “soltar un agente” y empezar a pensar en diseñar autonomía acotada. Es el cambio mental clave de 2026. Y es exactamente aquí donde aparecen los usos reales de los loops.

---

3. Para qué los están usando de verdad

3.1. Correr tareas autónomas durante horas (mientras no estás)

El uso estrella. Los agentes de CLI ahora corren en loops de ejecución prolongada, muchas veces en entornos de fondo (background execution) pensados para eso. Le das una tarea grande —“refactoriza el módulo de auth y actualiza los tests”— y el loop encadena docenas de llamadas a herramientas a lo largo de muchos turnos, ajustando según cada resultado, sin pedirte permiso en cada paso.

El patrón típico de un agente de código autónomo: planifica → edita archivos en el repo → corre los tests → si fallan, re-planifica → vuelve a probar → abre un Pull Request. Devin, el “ingeniero de software autónomo”, o el Copilot Coding Agent de GitHub (que toma un issue y abre un PR en borrador solo) son ejemplos en producción. El loop deja de ser un autocompletado y pasa a ser un trabajador de turno nocturno.

3.2. Reiniciar el contexto en cada vuelta: la técnica Ralph

Este es, para mí, el truco más elegante de todos. Si el problema es que el modelo se vuelve tonto cuando el contexto se llena, ¿la solución? Vaciar el contexto en cada iteración.

La técnica Ralph (bautizada por Ralph Wiggum, de Los Simpson; creada por Geoffrey Huntley a mediados de 2025) es un loop infinito que le da el mismo prompt al agente una y otra vez, pero con un principio radical: el progreso vive en los archivos y en Git, no en la ventana de contexto del modelo.

Cada iteración:

1. Arranca un proceso nuevo, con contexto vacío (solo specs + plan de implementación).
2. El agente implementa exactamente una tarea.
3. Commitea los cambios y guarda los aprendizajes en disco.
4. Sale. Un script externo verifica si ya terminó.
5. Si no, resetea el contexto y vuelve a empezar desde cero.

El contexto se trata como memoria efímera; el estado real se persiste en Git y archivos. Así el modelo siempre trabaja en su “zona inteligente” (contexto fresco) y nunca arrastra la basura de las vueltas anteriores. Es contraintuitivo —tirar la memoria a propósito— pero funciona justamente por eso.

Nota práctica: la versión mínima de Ralph es un simple bucle de bash llamando al CLI con el mismo prompt. No necesitas un framework; necesitas disciplina de estado en disco. Esto conecta directo con los cronjobs + IA: un cron que dispara un agente con contexto fresco es, en esencia, un Ralph loop con reloj.

3.3. Equipos de agentes: el loop como línea de montaje

El otro uso fuerte es dejar de pensar en un agente y montar varios especializados en cadena. El patrón que se está estandarizando imita a un equipo de ingeniería real:

Planner → Architect → Implementer → Tester → Reviewer

Cada agente tiene un rol y un loop propio; la salida de uno alimenta al siguiente. La fiabilidad sube porque ningún agente carga con todo el problema a la vez. En Claude Code esto se hace con subagentes: cada uno arranca con un contexto limpio, hace su parte, y solo su respuesta final vuelve al agente principal como resultado de herramienta. El contexto del orquestador crece por ese resumen, no por toda la transcripción del subtrabajo. Es la misma idea de Ralph (contexto acotado) aplicada en paralelo en lugar de en serie.

3.4. Loops con meta y evaluador

La evolución más reciente: loops que corren hacia una condición de completitud verificable, con un evaluador separado que comprueba si la meta se cumplió antes de parar. La fórmula mínima de un loop agéntico es “un disparador + una meta verificable; el agente corre hasta cumplirla”, sin que tú escribas nada entre iteraciones. Tests que pasan, cobertura que se alcanza, un endpoint que responde 200: el criterio de parada deja de ser “el modelo cree que terminó” y pasa a ser algo medible por fuera.

---

4. Loop engineering: las barandas que lo hacen viable

Nada de lo anterior es seguro sin guardarraíles. “Loop engineering” es justamente el arte de poner límites. Los que importan:

• Tope de iteraciones (max_turns en el SDK). Cuenta solo los turnos con herramientas; al llegar al límite, corta y te avisa con un error_max_turns.
• Presupuesto de gasto (max_budget_usd). Para el loop al cruzar un umbral de dólares. Es el default recomendado para producción.
• Detección de no-progreso. Si el estado no cambió entre vueltas, salir. Evita el AutoGPT dando círculos.
• Circuit breakers en reintentos de herramientas.
• Criterios de terminación explícitos (tests verdes, umbral de cobertura).
• Checkpoints humanos antes de acciones irreversibles. Innegociable.

Y los modos de permiso son parte de esto: acceptEdits auto-aprueba ediciones de archivos pero sigue pidiendo permiso para comandos peligrosos; bypassPermissions corre todo sin preguntar y solo debe usarse en entornos aislados (CI, contenedores). Elegir el modo correcto es loop engineering.

---

5. La factura: el detalle que nadie te cuenta primero

Todo esto tiene un costo muy concreto. Los números que circulan en 2026:

• Un agente individual consume alrededor de 4× los tokens de un chat normal.
• Un sistema multi-agente, hasta 15× más.

Quienes corren 5+ instancias de Claude en paralelo —usando un archivo CLAUDE.md como memoria semántica persistente, donde anotan los fallos para que las sesiones futuras no los repitan— suelen operar en entornos con tokens ilimitados. La mayoría de nosotros no. Por eso el max_budget_usd no es un detalle: es lo que separa un experimento útil de una sorpresa en la tarjeta. Y enlaza con un debate que ya toqué: comprar un curso de IA o gastarme los tokens experimentando — los loops son, precisamente, la forma más rápida de quemar esos tokens… para bien o para mal.

---

6. Cierre: el loop no es el truco, las barandas lo son

Si te quedas con una sola idea: el bucle while no es lo valioso ni lo difícil. Lo difícil —y lo que de verdad están usando los equipos serios— es todo lo que rodea al loop: cómo lo paras, cómo le reinicias el contexto para que no se vuelva tonto, cómo verificas que terminó de verdad, cómo lo encadenas con otros agentes y cómo evitas que se gaste tu presupuesto en círculos.

El loop de manual (Razonar → Actuar → Observar) es de 2022. Lo que cambió en 2026 es que aprendimos a domesticarlo: contexto efímero, estado en disco, topes duros, evaluadores externos y un humano en los puntos de no retorno. Esa es la respuesta honesta a “para qué están usando los loops”: no para que la IA piense sola, sino para que trabaje sola dentro de una jaula bien diseñada.

Y como siempre con la automatización sin supervisión: la potencia del loop es exactamente proporcional al cuidado con que lo encierras.

---

Referencias

• How the agent loop works — Claude Agent SDK Docs
• Agentic Loops: From ReAct to Loop Engineering (2026 Guide) — Data Science Dojo
• The Ralph Technique — DeepWiki
• The Ralph Wiggum Loop: Autonomous Code Generation with a Fresh Context — codecentric
• Claude Code Agent Architecture: Single-Threaded Master Loop — ZenML LLMOps Database
• The Agent Loop: How AI Agents Actually Work — you.com
• The State of AI Coding Agents (2026) — Dave Patten, Medium

---

#Agentes IA, #CLI, #Claude Code, #LLMs, #Automatización, #Agentic Loops,