Agent Loops: ¿la nueva fuerza bruta de la IA generativa?
TL;DR:
- Un agent loop es, técnicamente, un
while(!done)que llama a un LLM una y otra vez hasta que el modelo decide parar — no hay magia, hay reintentos - El patrón cumple los tres criterios de la fuerza bruta clásica: sin heurística real, costo que escala con los intentos, y un criterio de parada que nadie garantiza
- Un agente simple consume ~4x los tokens de una consulta directa; un sistema multiagente llega a ~15x — y la factura la paga alguien
- El problema de cuándo detener el bucle es, literalmente, una instancia del halting problem de Turing (1936): en general, no es decidible
- Sí hay casos donde el loop paga su costo (ReAct, JPMorgan, Siemens), pero la mayoría de las implementaciones en producción no tienen ni presupuesto de tokens ni criterio de parada serio
"Fuerza bruta" no es un insulto. Es un término técnico con casi 80 años de historia: probar todas las combinaciones posibles hasta que una funcione, sin entender necesariamente por qué funcionó. Romper una cerradura probando cada llave del llavero. Crackear un hash probando cada string del diccionario. Resolver una posición de ajedrez evaluando millones de variantes por segundo, como hacía Deep Blue en 1997 contra Kasparov. Es la sustitución de la inteligencia por ciclos de cómputo.
Así que cuando me preguntan si el agent loop — la arquitectura de moda detrás de GitHub Copilot, Claude Agent SDK, AutoGPT y la mitad del repositorio Awesome-AI-Agents — es la nueva fuerza bruta, mi respuesta no es una metáfora. Es una descripción técnica razonablemente precisa. Vamos a desmenuzar por qué, cuánto te cuesta en tokens reales, y por qué casi nadie le puso un criterio de parada decente a esto.
¿Qué es realmente un Agent Loop?
Un agent loop es un ciclo iterativo en el que un LLM con acceso a herramientas opera repetidamente hasta completar una tarea: llama al modelo, si pide ejecutar una herramienta la ejecutás, le devolvés el resultado, y repetís hasta que el propio modelo decida que terminó. Steve Kinney lo redujo a unas líneas de pseudocódigo que debería estar tatuado en la frente de cualquiera que diga "agentic AI" en una reunión de producto:
while (!done) {
const response = await callLLM(messages);
if (response.toolCalls.length > 0) {
const results = await executeTools(response.toolCalls);
messages.push(...results);
} else {
done = true;
return response;
}
}
Cada vuelta del bucle es una sola llamada al LLM. Si el modelo devuelve una llamada a herramienta, el sistema la ejecuta y reintegra el resultado para la siguiente iteración. Si devuelve texto plano, el ciclo termina. LangChain lo describe en los mismos términos: "un bucle de agente típico consta de dos pasos, llamada al modelo y ejecución de herramienta, y continúa hasta que el LLM decide terminar".
La diferencia conceptual con un flujo tradicional es importante y Anthropic la marca bien: los workflows son secuencias predeterminadas definidas por el desarrollador; los agentes son bucles abiertos donde el modelo decide el flujo en tiempo real. En arquitectura, esto se describe en cinco etapas — percepción, razonamiento, planificación, acción, observación — que se repiten hasta el final de la tarea. El LLM toma el volante; el bucle solo facilita la ejecución de lo que el modelo decide en cada vuelta.
Hasta acá, nada nuevo bajo el sol. Es la arquitectura mínima viable de un agente: LLM + memoria + planificación + herramientas, como lo resumió Lilian Weng en su ya clásico post sobre agentes autónomos potenciados por LLM. El problema empieza cuando entendés cómo decide el modelo cuándo parar — y cuánto te cobra por cada vuelta que no lo hace.
De Chain-of-Thought a ReAct: la prehistoria del loop
Chain-of-Thought (CoT), publicado por Wei et al. en 2022, le pide al modelo "pensar en pasos" dentro de un único prompt. No ejecuta nada externo: es razonamiento interno, contenido, que termina cuando termina el texto. Útil para lógica, inútil si necesitás tocar el mundo real.
Yao et al. dieron el siguiente paso ese mismo año con ReAct (Reason + Action): intercalar en un único prompt razonamientos del tipo "Thought: ... / Action: ..." simulando llamadas a herramientas dentro del propio texto generado. El resultado fue contundente — un 34% más de acierto sobre CoT simple en el benchmark ALFWorld. Pero seguía siendo una sola llamada al modelo: el agente "simulaba" actuar, no actuaba.
El agent loop es lo que pasa cuando alguien se pregunta "¿y si en vez de simular la acción, la ejecutamos de verdad y le devolvemos el resultado al modelo?". Ese salto — de la simulación dentro del prompt a la ejecución real entre iteraciones — es la novedad completa. No es una técnica de prompting nueva. Es la decisión de poner el razonamiento del LLM dentro de un bucle de control real, con efectos secundarios reales sobre sistemas reales.
| Característica | Chain-of-Thought | ReAct | Agent Loop | Multiagente |
|---|---|---|---|---|
| Iteraciones | Una sola | Una sola | Múltiples, hasta cumplir la meta | Muchas, en paralelo |
| Uso de herramientas | No | Simulado en el prompt | Real: invoca APIs/funciones | Real, varios agentes |
| Costo de recursos | Bajo (1 llamada) | Bajo (1 llamada) | Alto (~4x una consulta directa) | Muy alto (~15x) |
| Quién decide el final | El prompt termina | El prompt termina | El modelo, en cada vuelta | Orquestación + cada agente |
La tesis fuerza bruta: por qué un while(!done) no es magia
La fuerza bruta, en sentido formal, tiene tres características: ausencia de heurística real que descarte ramas malas de antemano, costo que escala linealmente (o peor) con la cantidad de intentos, y dependencia total del volumen de cómputo en lugar de la calidad de la decisión. Repasemos el agent loop contra esa definición.
¿Hay heurística real? Parcial. El LLM "razona" en cada paso, pero ese razonamiento es local — evalúa qué hacer en esta vuelta del bucle, no garantiza un plan globalmente óptimo. Es, en la práctica, una versión cara del patrón "generar y probar" (generate-and-test) que la IA simbólica usaba en los años 60: generás una acción candidata, la probás contra el mundo, observás el resultado, generás la siguiente. Newell y Simon ya jugaban a este juego con el General Problem Solver en 1957. La diferencia es que ahora el "generador" cuesta dinero por token y el "probador" es una API de producción con efectos secundarios reales.
¿El costo escala con los intentos? Sin duda — lo vemos en la sección de costos más abajo. ¿Depende del volumen de cómputo más que de la calidad de la decisión? También: cuando el modelo se equivoca, la respuesta del sistema no es "pensar mejor", es "intentar de nuevo con el resultado del error en el contexto". Eso es retry-until-it-works con esteroides de lenguaje natural.
Y después está el problema de cuándo parar, que es donde la metáfora deja de ser metáfora y se vuelve teoría de la computación pura. El bucle termina cuando el LLM decide que terminó. Pero determinar en general si un programa con un bucle va a terminar es, formalmente, indecidible — es el halting problem que Alan Turing demostró en 1936. No estoy forzando la analogía: Machiraju y otros documentaron casos reales de AutoGPT entrando en "looping forever", persiguiendo "mejoras constantes" sin ningún criterio de parada que detuviera el proceso. Le delegamos a un modelo probabilístico la resolución de un problema que sabemos, desde hace 90 años, que no tiene solución general. Eso no es ingeniería de agentes. Es optimismo con tarjeta de crédito.
El verdadero costo: tokens, latencia y la factura que nadie lee
Cada iteración del bucle implica una llamada adicional al modelo más la ejecución de la herramienta correspondiente. Esto no es gratis y la diferencia no es marginal: estimaciones de arquitecturas agénticas en producción indican que un agente simple consume aproximadamente 4 veces más tokens que una consulta directa de chat, y que una solución multiagente puede llegar a 15 veces más. Pensalo en plata: si una consulta directa te cuesta una unidad, un agente de un solo bucle te cuesta cuatro, y un sistema de varios agentes coordinados te cuesta quince — antes de contar reintentos por fallos, que en un sistema con halting problem sin resolver son la norma, no la excepción.
Hagamos la cuenta con números hipotéticos pero realistas para ilustrar la escala: si tu chat directo cuesta $0,01 por interacción y corrés 10.000 sesiones al mes, pagás $100. El mismo volumen con un agent loop de un solo agente son $400. Con una arquitectura multiagente, $1.500. Multiplicá por la cantidad de productos que tu empresa etiquetó como "agentic" en el último año y entendé por qué el área de finanzas empezó a hacer preguntas incómodas en las reuniones de presupuesto cloud.
La latencia escala igual: cada vuelta del bucle suma el tiempo de inferencia del modelo más el tiempo de ejecución de la herramienta. Un bucle de ocho iteraciones no es ocho veces más lento que una sola llamada porque sí — es ocho veces más lento porque, literalmente, hiciste ocho llamadas secuenciales. Y a diferencia de la fuerza bruta clásica, donde cada intento es barato (probar una llave más cuesta centésimas de segundo), aquí cada intento cuesta tokens reales facturados por un proveedor real. Combinaste el perfil de costo de la innovación con el perfil de inteligencia de la búsqueda exhaustiva. Esa combinación es exactamente lo que hace que esto sea peor que la fuerza bruta tradicional en unit economics, no mejor.
Steve Kinney lo dice sin vueltas: lo interesante de construir un agente no está en el bucle — eso son ocho líneas — está en la ingeniería alrededor del bucle: gestión de contexto, presupuesto de tokens, contención de fallos, límites de iteración, detección de bucles eternos. Sin esas capas, un agent loop trivial en un repo de demo es exactamente eso: un demo. Llevarlo a producción sin esas salvaguardas es directamente negligencia de ingeniería.
Cuando el loop se sale de control: halting problem, confused deputy y otros viejos conocidos
Los riesgos de seguridad de un agent loop no son nuevos conceptualmente — son problemas de los 80 y 90 con una superficie de ataque del tamaño de un LLM con acceso a herramientas reales.
El más elegante, en el sentido en que Edsger Dijkstra hablaba de elegancia, es el confused deputy problem, descrito por Norm Hardy en 1988: un programa con más privilegios que su usuario es engañado para usar esos privilegios en nombre de un atacante. Un agent loop con acceso a una API de borrado, manipulado mediante prompt injection en un documento que el agente "solo" tenía que resumir, es el confused deputy de toda la vida con un envoltorio de lenguaje natural. El agente no fue hackeado en el sentido clásico — hizo exactamente lo que el contexto le dijo que hiciera, y el contexto estaba envenenado.
Ya escribimos sobre esto cuando analizamos el colapso de seguridad de OpenClaw/Moltbook: un agente con la "tríada letal" — acceso a datos privados, exposición a contenido no confiable, capacidad de comunicación externa — es un confused deputy esperando que alguien le mande el prompt correcto. Setecientos setenta mil agentes activos heredaron comandos maliciosos sin cuestionarlos, porque ningún agent loop en producción venía con un validador serio de las llamadas a herramienta que ejecutaba.
El mismo patrón de fondo apareció en el breach de Vercel de abril 2026: no fue una vulnerabilidad de código, fue un token OAuth con permisos de "Allow All" que un atacante heredó y usó para leer variables de entorno en texto plano vía API. Cambiá "token OAuth" por "agente con herramientas sobre-permisionadas" y tenés el mismo modelo de amenaza: identidades digitales con más privilegio del necesario, sin auditoría de intención detrás de cada llamada.
Y después está la cadena de suministro: las definiciones de herramientas — esquemas, descripciones, documentación — son parte del contexto que el LLM procesa. Si un servidor de herramientas como los que describimos en nuestro post sobre MCP (Model Context Protocol) está comprometido, el atacante no necesita romper nada del modelo: solo necesita que el agente confíe en una herramienta que ya no es lo que dice ser. Sumale alucinaciones — el modelo "reportando" que validó algo que nunca corrió — y tenés un sistema que falla en silencio mientras factura tokens por cada vuelta del fallo.
¿Cuándo sí vale la pena la fuerza bruta?
No todo es condena. La fuerza bruta, la de toda la vida, también tiene casos de uso legítimos cuando el espacio de búsqueda es manejable y la alternativa — diseñar una heurística perfecta — cuesta más que simplemente probar. Los agent loops tienen el mismo trato.
El propio benchmark de ReAct (+34% sobre CoT en ALFWorld) muestra que el feedback real entre iteraciones mejora la tasa de éxito en tareas donde el camino correcto no se conoce de antemano. En producción, el agente de trading LOXM de JPMorgan ajusta estrategias en milisegundos según el resultado de cada operación — exactamente el tipo de entorno donde el plan fijo no sirve porque el mercado cambia más rápido de lo que cualquiera puede programar a mano. Siemens reporta una reducción del 30% en fallos de equipo con agentes que replanifican mantenimiento según telemetría en tiempo real. Salesforce Einstein recorta ciclos de venta cerca de un 20% dejando que el agente decida el siguiente paso de seguimiento según el comportamiento real del lead.
El patrón común en los casos que funcionan: el problema es genuinamente abierto, el feedback de cada acción es informativo, y alguien puso límites duros — presupuesto, iteraciones máximas, validación de cada llamada a herramienta — antes de subirlo a producción. El patrón común en los casos que fallan: alguien usó un agent loop para un pipeline que ya era determinista, donde una secuencia de pasos fija hubiera sido más rápida, más barata y más auditable. Si ya sabés los pasos, programalos. No le pagues a un LLM por token para que redescubra un if/else que vos ya conocías.
Veredicto: fuerza bruta con mejor relaciones públicas
Sí. Un agent loop es fuerza bruta. No en el sentido despectivo, sino en el sentido técnico exacto: generar, probar, observar, repetir, sin garantía de heurística global ni de terminación, con el costo escalando con cada vuelta. La diferencia con la fuerza bruta de los 80 es que antes el costo de cada intento era casi nulo — un ciclo de CPU — y ahora cada intento factura tokens reales en la nube de un proveedor real.
Eso no la vuelve inútil. La búsqueda exhaustiva resuelve problemas reales cuando el espacio es manejable y no hay un atajo mejor disponible. Pero tratala como lo que es: un algoritmo sin garantías de parada, ejecutándose con privilegios sobre sistemas de producción, facturado por uso. Ponele un circuit breaker. Ponele un presupuesto de tokens duro, no aspiracional. Auditá cada llamada a herramienta como auditarías cualquier llamada con privilegios elevados — porque eso es exactamente lo que es. Y la próxima vez que alguien en una reunión diga "agentic AI" con los ojos brillantes, preguntale cuál es el criterio de parada. Si no tiene una respuesta mejor que "el modelo decide", ya sabés lo que estás comprando: fuerza bruta con un pitch deck.
Trust the loop, verify everything else.
Fuentes
- ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022 (arXiv)
- Building Effective Agents — Anthropic Research
- LLM Powered Autonomous Agents — Lilian Weng
- Confused Deputy Problem — Norm Hardy, 1988 (referencia)
- LangGraph — LangChain AI
- OWASP Top 10 for LLM Applications
- Steve Kinney, "The Anatomy of an Agent Loop" (blog técnico)
- Estimaciones de consumo de tokens en arquitecturas agénticas, Microsoft Azure AI Foundry
Nick Holmes Senior Engineer. Confía en el código, verifica todo lo demás. 🔐
