El bucle ReAct

El bucle ReAct es el mecanismo por el que un modelo de lenguaje deja de contestar y empieza a actuar. El modelo recibe una tarea, escribe un razonamiento breve, pide una acción (buscar un dato, leer un fichero, ejecutar una orden), el programa que lo rodea ejecuta esa acción y le devuelve el resultado, y el modelo vuelve a razonar con el resultado delante. El ciclo se repite hasta que el modelo decide que ha terminado o hasta que alguien le pone un límite. El nombre es la contracción de las dos palabras inglesas que lo describen, reasoning y acting, razonar y actuar, y viene del artículo que Shunyu Yao y sus coautores publicaron en octubre de 2022. Casi todo lo que hoy se vende como agente autónomo, del asistente que programa al que reserva un viaje, es este bucle con distinta ropa.

La aportación del artículo original fue mostrar que las dos mitades se necesitan. Hasta entonces había dos líneas de trabajo separadas. Una pedía al modelo que pensara paso a paso antes de responder, la llamada cadena de pensamiento, y conseguía mejores respuestas en problemas de razonamiento, pero el modelo razonaba sobre lo que ya sabía y, cuando le faltaba un dato, lo inventaba con la misma soltura con que razonaba lo demás. La otra pedía al modelo que generara directamente acciones para un entorno, como un juego de texto o una tienda en línea simulada, y el modelo actuaba sin un plan que pudiera revisar cuando algo salía mal. Yao y sus coautores intercalaron las dos cosas en la misma secuencia de texto: pensamiento, acción, observación, pensamiento, acción, observación. Con una interfaz mínima a la Wikipedia, que solo permitía buscar una página y buscar una frase dentro de ella, el modelo dejaba de inventar datos porque podía consultarlos, y dejaba de perderse porque sus propios pensamientos escritos le servían de plan. En dos bancos de pruebas de toma de decisiones, ALFWorld y WebShop, la versión ReAct superó a métodos entrenados por imitación y por refuerzo en 34 y 10 puntos de tasa de éxito, con solo uno o dos ejemplos en el enunciado.

Lo que el patrón hace, visto desde el programa, es sorprendentemente poco. El modelo nunca toca el mundo. Escribe una petición estructurada, por ejemplo el nombre de una herramienta y sus argumentos, y es el código que lo rodea quien decide si la ejecuta, cómo y qué le devuelve. Las interfaces actuales de los proveedores formalizan esa frontera: la respuesta del modelo llega marcada como petición de herramienta, el programa responde con un bloque de resultado enlazado a esa petición, y la conversación sigue. Esa separación es lo que hace gobernable a un agente. Todos los controles que se le pueden poner, pedir confirmación antes de borrar algo, limitar el número de pasos, prohibir una herramienta a partir de cierto momento, viven en ese punto de paso entre lo que el modelo pide y lo que el programa hace.

Anthropic, en la guía que publicó en diciembre de 2024 y que se ha convertido en la referencia más citada del oficio, usa esta distinción para separar dos cosas que el mercado llama igual. Un flujo de trabajo es un sistema en el que el modelo y las herramientas se orquestan por caminos de código predefinidos: el programador sabe de antemano que primero se extrae, luego se valida y luego se guarda, y el modelo rellena cada paso. Un agente es un sistema en el que el modelo dirige su propio proceso y decide qué herramienta usar y en qué orden. El bucle ReAct es la forma mínima del segundo. La recomendación de la guía es tan poco espectacular como útil: empezar por lo más simple, una sola llamada bien preparada, y subir a un flujo y luego a un agente solo cuando lo anterior falla de forma medible, porque cada escalón cuesta más, tarda más y es menos predecible.

Hay una razón mecánica para esa cautela, y es el coste del propio bucle.

La figura hace visible algo que la factura esconde. Las interfaces de programación de los modelos de lenguaje no tienen memoria entre llamadas: cada petición contiene la conversación entera. Si un agente da treinta pasos y cada resultado de herramienta ocupa mil quinientos tokens, la conversación final ocupa unos sesenta mil, pero el modelo ha tenido que leer un millón, porque el paso treinta releyó los veintinueve anteriores, el veintinueve releyó los veintiocho, y así hasta el principio. La suma de una progresión aritmética crece con el cuadrado de su longitud. Doblar los pasos cuadruplica la lectura. Por eso, según las cifras que Anthropic publicó en 2025 sobre su sistema de investigación, un agente consume unas cuatro veces los tokens de una conversación con el mismo modelo, y un sistema de varios agentes unas quince, y por eso la decisión de usar un agente donde bastaba un flujo es, antes que una cuestión de elegancia, una cuestión de dinero.

La primera defensa es la caché de prefijo (prompt caching). Como cada petición repite exactamente el principio de la anterior, el proveedor puede guardar el estado interno que calculó para ese principio y reutilizarlo, y cobra la lectura de lo guardado a una fracción del precio normal. Con la caché activada, la figura muestra que la factura de un bucle largo baja a una fracción de lo que costaría sin ella. Tiene una condición estricta que explica muchos disgustos: la coincidencia tiene que ser byte a byte. Una fecha con la hora al principio de las instrucciones, una lista de herramientas que cambia de orden entre llamadas o un campo de un objeto serializado sin ordenar invalidan la caché entera sin ningún error visible, y la factura vuelve a la curva cuadrática sin que nadie lo note hasta final de mes.

La segunda defensa es la compactación: cuando la conversación se acerca a un umbral, se sustituye la historia por un resumen y se sigue desde ahí. Resuelve el techo, porque la conversación deja de crecer, pero tiene un precio que la figura no puede dibujar y que conviene tener presente. Después de compactar, el modelo ya no trabaja con lo que vio, sino con lo que alguien, normalmente el propio modelo, decidió que era importante recordar. Si el detalle que resultará decisivo en el paso cincuenta no parecía importante en el paso treinta, se ha perdido. Cognition, la empresa que desarrolla el agente de programación Devin, defendió en 2025 que para tareas largas la compactación por un modelo dedicado es preferible a repartir el trabajo entre varios agentes, precisamente porque conserva una única historia coherente. La guía de Anthropic de septiembre de 2025 sobre lo que llama ingeniería de contexto la sitúa junto a otras dos técnicas, las notas estructuradas que el agente escribe en un fichero para recuperarlas después y la delegación en subagentes con contexto propio.

El tercer problema del bucle no es de coste sino de terminación. Un agente confundido puede repetir la misma búsqueda fallida cuarenta veces, cada vez con la conversación un poco más larga y, por tanto, un poco más cara. Ningún agente en producción debería funcionar sin un límite de pasos o un presupuesto de tokens que el programa haga cumplir. Algunos proveedores permiten ya comunicar ese presupuesto al propio modelo, de modo que pueda administrarse y cerrar la tarea con lo que tiene en lugar de ser cortado a media frase, pero el límite duro del programa sigue siendo necesario, porque es el único que no depende de que el modelo lo respete.

Queda la objeción más seria al patrón, que no viene de su coste sino de su fiabilidad. Un bucle de muchos pasos acumula errores: si cada paso sale bien el noventa y cinco por ciento de las veces y ningún error se corrige, un agente de veinte pasos termina bien algo más de un tercio de las veces. La evaluación de agentes mide precisamente esto, y la conclusión práctica de quienes construyen estos sistemas es que el bucle ReAct funciona bien donde el mundo devuelve señales claras de error que el modelo puede leer y corregir (una prueba que falla, un compilador que protesta, una búsqueda vacía) y mal donde un paso equivocado no deja rastro. Con los años el bucle se ha ido cargando de variantes que atacan ese punto débil, y cada una tiene su artículo en esta colección. Consisten en dejar que el modelo actúe escribiendo código en lugar de llamadas sueltas, repartir la lectura entre subagentes con contexto propio, añadir un evaluador que revise cada intento. Y, sobre todo, conviene entender por qué la longitud de las tareas que un agente completa depende menos de lo que sabe que de su capacidad para darse cuenta de que se ha equivocado.