ReAct y las arquitecturas de agentes: qué usar y cuándo

La pregunta “¿cuál es la mejor arquitectura de agente?” está mal planteada. ReAct, Chain-of-Thought, Reflexion, Tree of Thoughts, RAG, memoria o RL no compiten entre sí: resuelven problemas distintos y se combinan. Este informe parte por ReAct —el bucle que está debajo de casi todo agente con herramientas—, explica qué tomar de él y qué no copiar del paper de 2022, recorre las alternativas con su costo real, y termina en una arquitectura híbrida y un roadmap concreto de prototipo a producción.

Fecha de los datos: octubre 2026. Las cifras de los papers son resultados históricos en configuraciones concretas de 2022–2023, no comparaciones con modelos actuales. Las valoraciones de madurez, latencia y costo de las tablas comparativas son valoración técnica propia, no ratings de los autores.

Resumen ejecutivo

ReAct —de Reasoning + Acting (razonar + actuar)— es un patrón en el que el modelo alterna razonamiento, elección de una acción, ejecución de una herramienta y observación del resultado, repitiendo el ciclo hasta cumplir el objetivo. “REACT” en mayúsculas es la misma palabra escrita informalmente, no otra arquitectura. El paper original (Yao et al., ICLR 2023) mostró que entrelazar razonamiento y acción podía superar tanto a los enfoques que solo razonan como a los que solo actúan, sobre todo cuando la tarea exige consultar información o interactuar con un entorno.

La idea sigue plenamente vigente, pero el ReAct de 2022/2023 no se debería copiar literal como arquitectura de producción en 2026. El paper armaba prompts few-shot (con unos pocos ejemplos) con trazas de razonamiento escritas a mano; un sistema moderno reemplaza gran parte de ese protocolo de texto por tool calling estructurado (llamadas a herramientas con esquema), estado explícito, validación, memoria controlada, límites de ejecución y observabilidad. Además, los modelos de razonamiento actuales piensan en buena parte internamente, así que no conviene —ni siempre se puede— controlar el agente leyendo su cadena de pensamiento.

La conclusión central: no existe una única arquitectura óptima. Conviene separar problemas que suelen mezclarse:

Problema	Técnica como punto de partida
Razonar mejor dentro de una sola llamada	Prompting, CoT, Plan-and-Solve
Consultar APIs, buscadores o ejecutar código	ReAct / tool calling nativo
Explorar alternativas y volver atrás	Tree of Thoughts
Aprender de errores entre intentos sin entrenar	Reflexion
Acceder a conocimiento corporativo o documental	RAG
Recordar información entre sesiones	Sistema de memoria explícito
Trabajo largo y descomponible	Planificación jerárquica / orchestrator-workers
Flujos críticos o repetibles	Workflow determinista con pasos agénticos acotados
Aprender a usar herramientas	SFT/RL al estilo Toolformer
Optimizar un agente con experiencia	RL agéntico
Producción mantenible	Máquina de estados, guardrails y evals

Esta separación calza con CoALA (un marco que modela al agente como memoria + espacio de acciones + proceso de decisión) y con la guía de ingeniería de Anthropic, que distingue workflows (el código fija la ruta) de agentes (el modelo decide dinámicamente qué hacer) y recomienda partir por lo más simple y sumar autonomía solo cuando aporte valor medible.

Para la mayoría de los productos nuevos, la recomendación es un híbrido “workflow + ReAct”:

una máquina de estados o grafo explícito gobierna las fases críticas;
el modelo decide localmente cuándo y cómo usar un set restringido de herramientas;
RAG aporta el conocimiento externo;
la memoria persistente guarda solo lo que merece sobrevivir a la sesión;
un validador revisa los resultados antes de cualquier operación de alto impacto;
hay límites de pasos, tiempo, costo y permisos;
todas las trayectorias se registran para evaluar y depurar.

Así se conserva la flexibilidad de ReAct sin la fragilidad de un agente totalmente autónomo. LangGraph, por ejemplo, está diseñado justamente como capa de orquestación de bajo nivel para agentes con estado, ejecución durable, intervención humana y memoria, mezclando pasos deterministas con decisiones del LLM.

No se recomienda usar AutoGPT Classic ni BabyAGI como base de un sistema empresarial nuevo. Son históricamente importantes —popularizaron los ciclos autónomos y la creación dinámica de tareas—, pero AutoGPT hoy es una plataforma de workflows mucho más amplia, y el propio repositorio de BabyAGI dice que el proyecto original se archivó y que la versión actual es experimental y no apta para producción.

Cuando ReAct estándar no basta, las extensiones tienen perfiles muy distintos: Reflexion agrega aprendizaje verbal entre intentos sin tocar pesos; Tree of Thoughts explora varias ramas y es bastante más caro; Plan-and-Solve planifica antes de ejecutar; Toolformer entrena al propio modelo para decidir cuándo y cómo llamar APIs; y el RL agéntico aprende políticas desde recompensas, a cambio de una infraestructura de entrenamiento mucho mayor.

Por último, seguridad y evaluación no se agregan al final. τ-bench muestra que el éxito en una ejecución puede esconder baja consistencia entre ejecuciones, y Agent-SafetyBench encontró fallas de seguridad importantes incluso en agentes avanzados, con defensas basadas solo en prompts insuficientes. Un agente de producción se evalúa a la vez por éxito, fiabilidad, costo, latencia, corrección de las llamadas, seguridad y cuánta intervención humana necesita.

ReAct en profundidad

El paper de Yao, Zhao, Yu, Du, Shafran, Narasimhan y Cao propone intercalar dos capacidades que antes se estudiaban por separado: el razonamiento en lenguaje y las acciones sobre un entorno. Las trazas de razonamiento permiten armar, seguir y corregir planes y manejar excepciones; las acciones permiten traer información nueva desde bases de conocimiento, buscadores o entornos interactivos.

Recursos primarios:

El repositorio trae notebooks para HotpotQA, FEVER, ALFWorld y WebShop y reproduce la metodología de prompting del paper. Hay que verlo como código de investigación de referencia, no como runtime de producción: no implementa persistencia durable, autorización granular, colas, observabilidad distribuida ni manejo de secretos.

El ciclo

       ┌──────────────────────┐
       │ Objetivo del usuario │
       └──────────┬───────────┘
                  ▼
       ┌──────────────────────┐
       │ Contexto + estado    │◄────────────────┐
       └──────────┬───────────┘                 │
                  ▼                             │
       ┌──────────────────────┐                 │
       │ LLM: ¿actuar o       │                 │
       │ terminar?            │                 │
       └────┬────────────┬────┘                 │
     actuar │            │ terminar             │
            ▼            ▼                      │
  ┌──────────────┐  ┌──────────────┐            │
  │ Tool +       │  │ Validar      │            │
  │ argumentos   │  │ respuesta    │            │
  └──────┬───────┘  └──────┬───────┘            │
         ▼                 ▼                    │
  ┌──────────────┐  ┌──────────────┐            │
  │ Validación y │  │ Respuesta    │            │
  │ autorización │  │ final        │            │
  └──────┬───────┘  └──────────────┘            │
         ▼                                      │
  ┌──────────────┐                              │
  │ Herramienta  │                              │
  └──────┬───────┘                              │
         ▼                                      │
  ┌──────────────┐                              │
  │ Observación  ├──────────────────────────────┘
  └──────────────┘

En el ReAct histórico, eso se escribía como texto plano en el prompt:

Question: ...

Thought: necesito averiguar X.
Action: Search[X]
Observation: ...

Thought: con esto puedo investigar Y.
Action: Lookup[Y]
Observation: ...

Thought: ya tengo suficiente evidencia.
Answer: ...

El sitio oficial especifica que los prompts incluían trayectorias de ejemplo con razonamientos escritos por humanos, acciones y observaciones del entorno. En tareas de decisión, los autores razonaban de forma más esporádica y dejaban que el modelo eligiera cuándo pensar y cuándo actuar.

En una implementación moderna conviene separar esas piezas en estructura:

{
  "status": "needs_tool",
  "current_subgoal": "obtener la cotización validada",
  "tool": "get_quote",
  "arguments": {
    "symbol": "XYZ"
  }
}

El modelo razona por dentro y el programa conserva un estado operativo auditable: subobjetivo, herramienta, argumentos, observación, errores, costos y resultado. Así el runtime no depende de una transcripción literal del razonamiento, que en varios modelos de razonamiento actuales ni siquiera se expone completo por la API.

Los componentes, con precisión

Componente	Qué significa en ReAct	Qué conviene hacer hoy
Reasoning	Traza intermedia que interpreta observaciones y decide el siguiente paso	Razonamiento del modelo + estado o plan resumido y estructurado
Acting	Emitir una acción concreta hacia el entorno	Tool calling tipado
Tool use	En el paper: APIs como Wikipedia y acciones del entorno	Registro de herramientas con JSON Schema, permisos y timeouts
Observation	Resultado que vuelve y condiciona el ciclo siguiente	Normalizar, etiquetar procedencia y limitar tamaño
Planning	No hay un planner separado: emerge del razonamiento	En tareas largas, separar planner y executor
Working memory	Historial de pensamientos, acciones y observaciones en el contexto	Estado explícito y compactación del contexto
Long-term memory	No es parte del ReAct original	Agregarla solo si el caso de uso necesita persistencia
Prompting	Trayectorias ReAct de ejemplo (few-shot)	Política de sistema + descripción de tools + esquemas; ejemplos solo si aportan

Ojo: llamar “ReAct” a cualquier sistema con base vectorial, planner, RAG y herramientas esconde el diseño real. ReAct es el bucle razonar → actuar → observar; RAG, memoria persistente, reflexión y planificación jerárquica son extensiones independientes.

Qué rindió en el paper

Frente a métodos previos de imitación y RL de sus experimentos, los autores reportaron que ReAct mejoraba la tasa de éxito en ALFWorld en 34 puntos absolutos y en WebShop en 10, con solo una o dos demostraciones en el prompt. En preguntas y verificación de hechos, consultar Wikipedia reducía la alucinación y la propagación de errores del baseline que solo razonaba.

El README del repositorio publica estos resultados absolutos por benchmark:

Modelo del experimento	HotpotQA (EM)	FEVER (EM)	ALFWorld (éxito)	WebShop (éxito)
PaLM-540B (resultados del paper)	29,4	62,2	70,9	40,0
GPT-3 `davinci-002` (ejecución del repo)	30,4	54,0	78,4	35,8

EM = exact match (coincidencia exacta con la respuesta correcta). Son resultados históricos de 2022–2023, no comparables con modelos de 2026.

El resultado conceptual dura más que las cifras: el baseline que solo razona puede inventar o sostener información equivocada porque no consulta el entorno; el que solo actúa recupera información pero no la sintetiza bien. ReAct junta ambas cosas.

Fortalezas y límites

Fortalezas. Es simple de implementar, encaja naturalmente con herramientas, corrige decisiones a partir de resultados nuevos, deja una trayectoria observable y no requiere entrenar el modelo. Basta un LLM que siga instrucciones, una interfaz de herramientas y un bucle de control. El cómputo se va en inferencia y crece con el número de iteraciones y llamadas a tools, no en entrenamiento.

Límites. El agente puede elegir la herramienta equivocada, armar mal los argumentos, entrar en loops, malinterpretar una observación, agotar el contexto o acumular errores a lo largo de la trayectoria. Cada iteración suma latencia y costo. El propio paper reconoce fallas incluso en ALFWorld y los límites de contexto del prompting, por lo que los autores también probaron fine-tuning sobre el formato ReAct.

Por eso conviene ver a ReAct como un excelente mecanismo local de decisión, no como el controlador global automático de cualquier proceso de negocio.

Estrategias de razonamiento, planificación y aprendizaje

Estas técnicas se presentan a menudo como competidoras, pero operan en capas distintas: CoT y Plan-and-Solve son estrategias de prompting; ReAct agrega interacción con el entorno; Reflexion agrega aprendizaje textual entre intentos; Tree of Thoughts convierte la inferencia en búsqueda; Toolformer modifica el modelo.

Enfoque	Qué hace	Requisitos	Fortalezas	Debilidades	Madurez	Cuándo usarlo
Prompt engineering	Instrucciones, contexto, ejemplos, formatos y descripción de tools	Solo inferencia	Barato, rápido, versionable	Frágil en tareas muy complejas; no crea memoria ni aprendizaje	Alta	Primera capa de todo sistema, con prompts versionados y evaluados
Chain-of-Thought (CoT)	El modelo escribe pasos intermedios antes de responder	Modelo capaz; few-shot en el paper	Mejora tareas de varios pasos sin herramientas	Más tokens y latencia; sin anclaje externo; no es prueba de corrección	Alta	Razonamiento interno; nunca como reemplazo de herramientas o validadores
Plan-and-Solve (PS+)	Pide al modelo idear un plan con subtareas y luego ejecutarlo paso a paso	Solo inferencia: un prompt zero-shot (sin ejemplos); en sistemas reales a veces se separa en dos llamadas	Reduce pasos omitidos; fácil de adoptar	Un plan inicial malo arrastra toda la ejecución	Media-alta	El paso natural después del prompting simple, antes de multi-agente
ReAct	Alterna razonar → actuar → observar	LLM + tools; sin entrenamiento	Anclaje en datos reales, adaptación, integración con APIs	Loops, errores acumulados, costo por paso	Alta como patrón	Por defecto cuando hay herramientas, con máquina de estados y límites
Reflexion	Tras un intento, un evaluador escribe una reflexión que se guarda y condiciona el siguiente intento	Varias inferencias + una señal de éxito; no toca pesos	Aprende de fallas sin fine-tuning; se monta sobre ReAct	Más costo y latencia; puede diagnosticar mal; necesita una buena señal	Media / experimental	Solo después de una falla, con reintentos limitados
Tree of Thoughts (ToT)	Genera varios estados de razonamiento, los evalúa y explora con búsqueda y retroceso	Muchas inferencias (ramas × profundidad × evaluación)	Sirve cuando las decisiones tempranas hay que reconsiderarlas	Latencia y costo altos; el mismo LLM puede ser mal juez de sus ramas	Investigación / selectiva	Solo donde la búsqueda realmente mejora el KPI
Toolformer	Genera y filtra ejemplos de llamadas a APIs y entrena al modelo para decidir si, cuándo, cuál y con qué argumentos llamar	Generación de datos + entrenamiento	Interioriza buenas políticas de uso de tools	Costo de datos y entrenamiento; difícil adaptarse a APIs que cambian	Investigación (idea muy influyente)	Solo cuando un agente basado en prompting ya genera trazas suficientes y el volumen lo justifica

Datos de los papers, en sus configuraciones originales: CoT mostró grandes mejoras en aritmética, razonamiento simbólico y sentido común; Plan-and-Solve mejoró sobre Zero-shot-CoT en los diez datasets que evaluó; Reflexion reportó 91% pass@1 en HumanEval; y Tree of Thoughts resolvió 74% de Game of 24 frente a 4% de CoT con GPT-4.

Repositorios: Plan-and-Solve · Reflexion · Tree of Thoughts.

“Usar herramientas” no es Toolformer. Un agente ReAct mantiene el modelo congelado y elige herramientas al inferir; Toolformer genera ejemplos de llamadas y entrena los pesos para integrarlas en la predicción. Una versión moderna “al estilo Toolformer” consiste en juntar trayectorias correctas de tool calling y usarlas para SFT (supervised fine-tuning, ajuste supervisado), optimización por preferencias o RL, con el mismo objetivo: mejorar la política de elección y uso de herramientas.

Reflexion tampoco es RL tradicional. Sus autores lo llaman verbal reinforcement learning porque el feedback queda en memoria de texto, sin ajustar parámetros. Eso lo hace atractivo cuando tienes un verificador —un compilador, una suite de tests, una señal de éxito— y quieres una segunda oportunidad sin entrenar nada.

Los agentes con RL sí modifican la política del modelo. WebGPT fue un ejemplo temprano: OpenAI entrenó un modelo para navegar con un navegador de texto, primero imitando demostraciones humanas y luego optimizando la calidad con feedback humano (su mejor versión usó muestreo best-of-n contra un modelo de recompensa entrenado con preferencias humanas). Agent Lightning lleva esa línea a agentes modernos: representa las ejecuciones como transiciones aprovechables para asignar crédito y entrenar con RL, desacoplando el runtime del sistema de entrenamiento.

Cuidado: la estrategia correcta para RL no es empezar por RL. Primero se construye un agente competente, se registran miles de trayectorias, se define una recompensa difícil de manipular, se monta una evaluación offline estable y se comprueba que prompting o SFT no resuelven el problema. Recién ahí el costo extra se justifica.

Herramientas, RAG, memoria y arquitecturas modulares

Un agente real necesita bastante más que una estrategia de razonamiento. CoALA es útil para diseñarlo porque separa memoria, espacio de acciones y procedimiento de decisión, y trata tanto la interacción con la memoria como con el mundo externo como acciones estructuradas.

Una arquitectura modular recomendable:

  ┌────────────────┐
  │ Usuario/evento │
  └───────┬────────┘
          ▼
  ┌────────────────┐     ┌────────────────┐
  │ Política +     ├───► │ Planner        │
  │ intención      │     └───────┬────────┘
  └────────────────┘             ▼
  ┌─────────────────────────────────────────┐
  │ Orquestador / máquina de estados        │
  │                                         │
  │  RAG · workers · tools/APIs             │
  │  memoria de trabajo · memoria larga     │
  │  tracing · métricas · auditoría         │
  └────────────────────┬────────────────────┘
                       ▼
             ┌───────────────────┐
             │ Evaluador /       │
             │ verificador       │
             └──┬──────┬──────┬──┘
         retry  │      │      │ ok
       ┌────────┘      │      └────────┐
       ▼               ▼               ▼
  ┌──────────┐  ┌──────────────┐  ┌──────────┐
  │ volver al│  │ aprobación   │  │ Resultado│
  │ orquest. │  │ humana       │  │          │
  └──────────┘  │ (alto impac.)│  └──────────┘
                └──────────────┘

Este grafo no exige varios modelos: planner, executor y evaluador pueden ser llamadas distintas al mismo modelo con prompts y permisos diferentes. Separar roles es sobre todo una decisión de control de software, no de arquitectura multi-modelo.

RAG como herramienta

RAG (Retrieval-Augmented Generation, generación aumentada con recuperación) es un subsistema de conocimiento, no una alternativa completa a ReAct. El trabajo original de Lewis et al. combina la memoria del modelo (sus parámetros) con una memoria externa recuperada desde un índice de documentos, motivado por lo difícil que es actualizar conocimiento guardado solo en los pesos y dar procedencia.

En un agente moderno, RAG suele convertirse en una herramienta más:

Agente
  ├─ search_internal_docs(query)
  ├─ search_web(query)
  ├─ get_customer(id)
  └─ create_ticket(...)

Así el agente decide cuándo recuperar en vez de meter documentos en cada solicitud. El costo es una nueva clase de fallas —recuperación incorrecta, documentos desactualizados, contexto contaminado, más latencia—; el beneficio es que el conocimiento se actualiza sin reentrenar el modelo.

Memoria no es “poner una base vectorial”

Memoria	Contenido	Persistencia	Implementación típica
Estado de trabajo	Objetivo, pasos completados, resultados recientes	La ejecución	Objeto de estado / checkpoint
Conversacional	Mensajes relevantes	La sesión	Historial + compactación
Episódica	Experiencias o ejecuciones anteriores	Largo plazo	Base de datos + búsqueda temporal o semántica
Semántica	Hechos sobre el usuario, una entidad o el dominio	Largo plazo	SQL / clave-valor / índice vectorial
Procedimental	Reglas, skills, instrucciones	Versionada	Código, prompts, registro de skills
De artefactos	Documentos, código, archivos generados	Largo plazo	Object storage / repositorio

MemGPT se diseñó en torno a una jerarquía inspirada en la memoria virtual de los sistemas operativos, moviendo información entre niveles para superar el contexto limitado; esa línea evolucionó después a Letta. Generative Agents ofrece otro patrón: guarda experiencias, recupera recuerdos, sintetiza reflexiones de nivel superior y las usa para planificar; sus ablaciones (pruebas quitando una pieza a la vez) mostraron que observación, planificación y reflexión aportaban al comportamiento en su simulación de 25 agentes.

Ojo: la memoria trae riesgos propios —información obsoleta, contradicciones, crecimiento sin límite, filtración entre usuarios y consolidación de errores—. Una memoria seria necesita política de escritura, expiración o invalidación donde corresponda, procedencia, namespaces por usuario o tenant, y una decisión explícita de qué merece persistir.

Planificación jerárquica y multi-agente

La planificación jerárquica sirve cuando una tarea se descompone en decenas de pasos: el nivel superior define subtareas, los workers las resuelven con ventanas de contexto más chicas y el orquestador junta los resultados. Corresponde al patrón orchestrator-workers que describe Anthropic y a los subgrafos y subagentes de los frameworks actuales.

Su gran beneficio es acortar el “horizonte” que cada worker debe sostener. Pero multi-agente no es gratis: más llamadas, más contexto que propagar, más puntos de falla y más difícil atribuir un error. No conviene crear un agente por cada rol del negocio solo porque se ve elegante. Como regla práctica, un solo agente con cinco tools es más fácil de operar y depurar que cinco agentes conversando entre sí, salvo que haya una razón concreta: aislar contextos, separar permisos, especializar o paralelizar.

AutoGPT, BabyAGI y LangGraph hoy

AutoGPT sigue activo, pero cambió de significado: el repositorio distingue el AutoGPT Classic original de la plataforma actual, que permite construir, desplegar y correr workflows completos con triggers y agendamiento, como servicio gestionado o self-hosted. No hay que evaluarlo como si fuera el famoso bucle autónomo de 2023. Repositorio
BabyAGI: el README indica que el original de marzo de 2023 (planificación de tareas para agentes autónomos) se archivó en 2024; la variante posterior explora un agente que construye y registra sus propias funciones, con advertencia explícita de que no es para producción. Hoy vale más como laboratorio conceptual. Repositorio
LangChain / LangGraph: LangChain aporta integraciones y componentes de alto nivel; LangGraph es la capa de orquestación de bajo nivel para agentes con estado y ejecuciones largas, con persistencia, human-in-the-loop, memoria y observabilidad. Su propiedad clave: no esconde la arquitectura detrás de una abstracción de “agente”, sino que permite mezclar nodos deterministas y agénticos en un grafo explícito. LangGraph · LangChain

Madurez práctica en 2026 (valoración propia)

Familia	Madurez	Evaluación
Tool calling estructurado	Alta	Base recomendada
RAG	Alta	Base recomendada cuando hay conocimiento externo
Workflows deterministas + LLM	Alta	Preferible en operaciones críticas
ReAct	Alta como patrón	Excelente para uso local de herramientas
LangGraph / máquina de estados agéntica	Alta	Adecuado para sistemas complejos
Memoria de corto plazo / persistencia explícita	Alta	Necesaria en tareas largas
Memoria “auto-curada” por el agente	Media	Requiere evals fuertes
Planificación jerárquica	Media-alta	Muy útil en tareas largas
Multi-agente dinámico	Media	Solo con justificación
AutoGPT Platform	Media-alta como plataforma	Evaluar según integración y producto
AutoGPT Classic	Histórico / experimental	No usar como base de producción
BabyAGI	Experimental	Investigación y prototipos
CoALA	Alta como marco conceptual	Excelente guía de arquitectura
Toolformer tal cual	Investigación	Entrenamiento especializado
RL agéntico	Investigación avanzada → emergente	Solo con escala y una buena señal de recompensa

Comparativa de rendimiento, costo y complejidad

No hay un benchmark único que ponga todas estas arquitecturas en una tabla justa: CoT, RAG, LangGraph y RL resuelven problemas distintos. La tabla siguiente es una evaluación relativa de ingeniería, suponiendo el mismo modelo base y una tarea típica de varios pasos. “Latencia alta” significa más llamadas al modelo o a tools que el baseline; “costo” incluye complejidad operativa, no solo tokens.

Enfoque	Latencia	Interpretabilidad operativa	Escalabilidad	Facilidad	Integración tools	Seguridad intrínseca	Costo relativo
Prompting simple	Baja	Alta	Alta	Muy alta	Baja	Baja	Bajo
CoT	Baja–media	Media	Alta	Muy alta	Baja	Baja	Bajo–medio
Plan-and-Solve	Media	Alta	Alta	Alta	Media	Media	Medio
ReAct	Media–alta	Alta	Alta con buen runtime	Alta	Muy alta	Media-baja	Medio–alto
Reflexion	Alta	Alta	Media	Media	Alta	Media	Alto
Tree of Thoughts	Muy alta	Alta	Baja–media	Media-baja	Media	Media	Muy alto
Toolformer-like entrenado	Baja–media al inferir	Media	Muy alta	Baja	Muy alta	Media	Alto en entrenamiento
RAG	Media	Alta por procedencia	Alta	Alta	Media–alta	Media	Medio
Memoria persistente	+Baja–media	Alta si hay procedencia	Alta	Media	Media	Media	Medio
Workflow determinista + tools	Baja–media	Muy alta	Muy alta	Media	Alta	Alta	Medio
LangGraph / modular	Media	Muy alta	Alta	Media	Muy alta	Alta si se diseña bien	Medio
Multi-agente jerárquico	Alta–muy alta	Alta	Media–alta	Baja	Muy alta	Media	Alto–muy alto
Autónomo estilo AutoGPT	Alta	Media	Media	Alta para demo	Alta	Baja sin controles	Alto
Estilo BabyAGI	Alta	Media	Baja–media	Alta para experimentar	Media	Baja	Medio–alto
Agente con RL	Media al correr / entrenamiento enorme	Baja–media	Alta una vez entrenado	Muy baja	Alta	Variable	Muy alto al inicio

Sobre interpretabilidad: ver una cadena de pensamiento no garantiza que sea una representación fiel del cálculo interno del modelo. En operaciones de negocio, la interpretabilidad que sirve es otra: estado de la tarea, plan declarado, herramienta elegida, argumentos, observación, política aplicada, duración, costo y veredicto del verificador.

La escalabilidad tiene dos ejes. Una arquitectura puede escalar bien en número de solicitudes y mal en pasos por solicitud. ToT tiene el segundo problema por su búsqueda ramificada; un workflow determinista procesa volúmenes enormes con trayectorias cortas; un multi-agente puede paralelizar workers pero gasta muchas más inferencias por tarea.

El costo total de una tarea se puede pensar así:

Costo(tarea) = Σ costo de cada llamada al LLM
             + Σ costo de cada tool
             + costo de recuperación (RAG)
             + costo de memoria
             + costo de infraestructura

y la latencia crítica, así:

Latencia(tarea) ≈ Σ latencias de los pasos secuenciales
                + máx. latencia entre ramas paralelas

Por eso reducir pasos secuenciales suele importar tanto como usar un modelo barato. Un ReAct de diez iteraciones con un modelo económico puede salir más lento y caro que un planner mejor que resuelve la misma tarea en tres llamadas. Y repartir el problema entre agentes sin criterio suma tokens de pura coordinación.

La práctica útil es fijar un presupuesto agéntico explícito (valores de ejemplo; se calibran con tus propias evals):

max_steps = 12
max_model_calls = 15
max_tool_calls = 20
max_parallel_workers = 4
wall_clock_timeout = 120 s
maximum_external_cost = ...

Llegar a un límite debe producir un estado controlado como NEEDS_REVIEW, nunca un loop abierto.

Seguridad, guardrails y evaluación

El gran cambio al pasar de un chatbot a un agente es que un error de texto se puede convertir en una acción. Por eso la seguridad se construye alrededor del runtime, no solo dentro del prompt.

  ┌─────────┐   ┌──────────────┐   ┌──────────────┐
  │ Input   ├─► │ Política de  ├─► │ LLM/planner  │◄──┐
  └─────────┘   │ entrada      │   └──────┬───────┘   │
                └──────────────┘          ▼           │
                                   ┌──────────────┐   │
                                   │ Tool call    │   │
                                   │ propuesta    │   │
                                   └──────┬───────┘   │
                                          ▼           │
                                   ┌──────────────┐   │
                                   │ Validar      │   │
                                   │ esquema      │   │
                                   └──────┬───────┘   │
                                          ▼           │
                                   ┌──────────────┐   │
                                   │ Autorizar    │   │
                                   │ (mín. priv.) │   │
                                   └──────┬───────┘   │
                                          ▼           │
                ┌──────────────┐   ┌──────────────┐   │
                │ Aprobación   │◄──┤ ¿Acción      │   │
                │ humana       │sí │ sensible?    │   │
                └──────┬───────┘   └──────┬───────┘   │
                       │                  │ no        │
                       ▼                  ▼           │
                ┌─────────────────────────────────┐   │
                │ Sandbox / ejecutor              │   │
                └────────────────┬────────────────┘   │
                                 ▼                    │
                ┌─────────────────────────────────┐   │
                │ Observación: sanitizar +        ├───┘
                │ procedencia                     │
                └─────────────────────────────────┘

  Respuesta final ──► política de salida / verificador
  Todo el recorrido ──► traza de auditoría

La evidencia empírica respalda los controles fuera del prompt: Agent-SafetyBench evaluó 16 agentes en 349 entornos y 2.000 casos de prueba; ninguno superó 60% en su métrica de seguridad, y los autores concluyeron que las defensas basadas solo en prompts son insuficientes.

Un sistema de producción aplica defensa en profundidad:

Sandbox y mínimo privilegio. El modelo nunca recibe una credencial todopoderosa. read_customer() y refund_customer() deben tener permisos, políticas y, si corresponde, flujos de aprobación distintos.
Validación de argumentos. La salida del modelo no se convierte directo en SQL, shell, HTTP arbitrario ni una operación financiera: pasa por validación de esquema, reglas de negocio, allowlists y autenticación independientes del modelo.
Human-in-the-loop en lo irreversible. Pausar para inspeccionar o modificar el estado antes de pagos, borrados, despliegues, comunicaciones externas sensibles o cambios de permisos.
Presupuestos y circuit breakers. Topes de pasos, tokens, costo, reintentos y duración para que un error local no se transforme en una ejecución indefinida.
Lo que devuelven las herramientas es input no confiable. Web, correo, documentos recuperados y respuestas de terceros pueden traer instrucciones maliciosas (prompt injection). Es la aplicación, no el texto recuperado, la que define qué herramientas y permisos existen.
Idempotencia y compensación. Las herramientas que modifican sistemas deberían aceptar claves de idempotencia, para que un reintento no duplique un pago, un correo o un ticket.

Cómo evaluar un agente

Un agente no se mide solo por accuracy. AgentBench evaluó LLMs como agentes en múltiples entornos y encontró dificultades sobre todo en razonamiento largo, toma de decisiones y seguimiento de instrucciones. GAIA se diseñó con tareas generales que combinan razonamiento, multimodalidad, búsqueda web y herramientas: evaluar un agente exige mucho más que preguntas y respuestas estáticas.

Dimensión	Métricas recomendadas
Éxito de la tarea	Tasa de éxito, exact match, tests que pasan, objetivo cumplido
Fiabilidad	Éxito en N repeticiones, varianza, `pass^k`
Uso de tools	Precisión al elegir tool, precisión de argumentos, tasa de llamadas inválidas
Trayectoria	Pasos hasta el éxito, tasa de loops, reintentos, llamadas innecesarias
RAG	Recall@k de recuperación, citas correctas, respuestas ancladas en fuentes
Latencia	p50, p95, p99 de punta a punta y por tool
Costo	Tokens de input/output, costo de tools, costo por tarea exitosa
Seguridad	Violaciones de política, acciones inseguras, tasa de éxito de inyecciones
Autonomía	% completado sin intervención
Carga humana	Aprobaciones o escalamientos cada 100 tareas
Experiencia	Satisfacción y tasa de corrección manual
Robustez	Éxito ante errores de API, timeouts, datos incompletos y caídas de tools

τ-bench aporta una idea clave: pass^k, que pregunta si el sistema resuelve la tarea correctamente en todas de k ejecuciones, no si alguna sale bien. En el trabajo original, incluso agentes de punta como gpt-4o tenían consistencia limitada: en el dominio retail, su pass^8 quedaba bajo 25%.

Eso cambia cómo se hace el testing de aceptación. Un 90% de éxito por ejecución suena alto, pero suponiendo independencia (una simplificación), la probabilidad de ocho éxitos seguidos es 0,9⁸ ≈ 43%; con 95% por ejecución, 0,95⁸ ≈ 66%. Por eso una operación realmente crítica puede necesitar workflow determinista, verificadores y aprobaciones aunque el modelo parezca “muy bueno”.

Un patrón ReAct moderno (independiente del proveedor)

Pseudocódigo que no depende de una cadena de pensamiento en texto y mantiene un registro operativo:

from dataclasses import dataclass, field
from typing import Any


@dataclass
class AgentState:
    goal: str
    observations: list[dict[str, Any]] = field(default_factory=list)
    step: int = 0


MAX_STEPS = 12


def run_agent(goal: str) -> str:
    state = AgentState(goal=goal)

    for _ in range(MAX_STEPS):
        state.step += 1

        # El modelo recibe:
        # - objetivo
        # - estado resumido
        # - resultados de tools relevantes
        # - herramientas permitidas y sus esquemas
        decision = model.decide(
            goal=state.goal,
            observations=compact(state.observations),
            tools=tool_registry.schemas(),
        )

        if decision.type == "final":
            result = verify_final_answer(decision.answer, state)

            if result.accepted:
                return decision.answer

            state.observations.append({
                "type": "verification_failure",
                "details": result.feedback,
            })
            continue

        if decision.type != "tool_call":
            raise RuntimeError("Decisión de agente inválida")

        tool = tool_registry.get(decision.tool)

        # Control externo al LLM.
        validate_schema(tool, decision.arguments)
        authorize(tool, decision.arguments)

        if is_high_impact(tool, decision.arguments):
            require_human_approval(tool, decision.arguments)

        try:
            observation = sandbox_execute(
                tool,
                arguments=decision.arguments,
                timeout_seconds=20,
            )
        except Exception as exc:
            observation = {
                "status": "error",
                "error_type": type(exc).__name__,
            }

        state.observations.append({
            "tool": decision.tool,
            "arguments": redact_secrets(decision.arguments),
            "result": sanitize(observation),
        })

    raise RuntimeError("Agente detenido: se agotó el presupuesto de pasos")

Conceptualmente es ReAct: decisión → acción → observación → nueva decisión. Pero la seguridad, el control y el estado pertenecen al programa, no a la obediencia del modelo.

Una segunda mejora es planificar solo cuando hace falta:

plan = planner.create_plan(task)

for subtask in plan:
    result = executor.solve_with_tools(
        subtask=subtask,
        max_steps=6,
    )

    if not evaluator.accept(result):
        result = executor.retry(
            subtask=subtask,
            feedback=evaluator.feedback,
            max_steps=3,
        )

    memory.save_artifact(subtask, result)

Aquí conviven Plan-and-Solve + ReAct + Reflexion (evaluador) + memoria, cada pieza con una responsabilidad explícita. Esa composición le gana a la búsqueda del “algoritmo de agente ganador”.

Recomendaciones prácticas y roadmap

La recomendación cambia según el objetivo (valoración propia; supone inferencia por API o servicio gestionado y sin certificaciones regulatorias especiales).

Objetivo	Arquitectura	Infraestructura	Riesgo técnico
Prototipo rápido	ReAct / tool calling + RAG opcional	API de LLM; sin GPU propia	Bajo–medio
Producción escalable	Máquina de estados + ReAct local + RAG + memoria + verificador + guardrails	APIs o inferencia gestionada + BD + tracing + sandbox	Medio
Investigación avanzada	Jerárquico / ToT / Reflexion / SFT-RL	Clúster GPU o gran presupuesto de inferencia	Alto

Prototipo rápido

Un solo agente con tool calling. Python, Pydantic para los contratos, FastAPI si hay que exponer un servicio, SQLite o PostgreSQL para el estado y un proveedor de LLM con tool calling. RAG solo si existe un corpus externo real. Nada de base vectorial, multi-agente, Reflexion o memoria de largo plazo “por si acaso”.

El objetivo del prototipo no es “tener autonomía”, sino construir un dataset de evaluación real: un conjunto de tareas representativas de tu caso real antes de optimizar la arquitectura. Por cada ejecución, registrar objetivo, tools permitidas, llamadas hechas, argumentos, resultado, costo, latencia y causa de falla.

Python
  │
  ├── API de LLM con tool calling / salida estructurada
  ├── Pydantic / JSON Schema
  ├── bucle ReAct propio y corto
  ├── PostgreSQL o SQLite
  ├── pgvector solo si hay RAG real
  ├── pytest + dataset de evaluación
  └── tracing estructurado

Una abstracción mínima permite entender qué está fallando antes de meter un framework.

Producción escalable

Migrar el loop a un grafo o máquina de estados durable. LangGraph es una opción razonable porque combina lógica determinista con pasos agénticos, checkpoints, human-in-the-loop y memoria; una implementación propia equivalente también vale si el equipo quiere minimizar dependencias.

API / Event Bus
       │
       ▼
Workflow durable / LangGraph / máquina de estados
       │
       ├── Planner acotado
       ├── Executor ReAct
       ├── Servicio de recuperación
       ├── Tool gateway
       │     ├── esquemas
       │     ├── permisos
       │     ├── idempotencia
       │     └── sandbox
       ├── Evaluador
       └── Servicio de aprobaciones
              │
              ▼
     PostgreSQL + object store
              │
              ▼
     Tracing + métricas + auditoría

Para equipos que prefieren un servicio gestionado, ya existen runtimes agénticos de los proveedores. Por ejemplo, OpenAI lanzó el 10 de septiembre de 2026 su Agents API en beta pública: sesiones durables, orquestación, compactación de contexto, herramientas (incluido MCP), subagentes y ejecución en un sandbox gestionado o propio. Es una alternativa a construir todo el harness en casa; revisa sus condiciones de residencia y retención de datos antes de usarla con información sensible.

Cómo decidir entre framework y desarrollo propio:

Situación	Recomendación
Pocas tools, ejecución breve	Loop propio
Flujo lineal y estable	Workflow tradicional
Ramificaciones, reintentos, checkpoints	LangGraph / máquina de estados
Tareas de minutos u horas	Runtime durable
Necesidad fuerte de infraestructura gestionada	Plataforma de agentes
Requisitos regulatorios / control total	Runtime propio o self-hosted
Investigar el algoritmo agéntico	Código propio mínimo, para no mezclar variables

Investigación avanzada

Recién después de tener un baseline ReAct y una suite de evals, probar mejoras de a una:

Baseline: tool calling / ReAct
                 │
                 ├── + planificación explícita
                 │     ¿mejora éxito/costo?
                 │
                 ├── + recuperación
                 │     ¿mejora factualidad?
                 │
                 ├── + Reflexion
                 │     ¿mejora éxito tras fallar?
                 │
                 ├── + búsqueda en árbol
                 │     ¿justifica el costo?
                 │
                 ├── + workers jerárquicos
                 │     ¿mejora tareas largas?
                 │
                 └── + SFT / RL
                       ¿mejora la política de acción?

Cuidado: comparar ReAct contra ReAct + Reflexion + RAG + planner + modelo más grande y concluir que “Reflexion funciona” es un error de diseño experimental. Cada intervención se aísla con ablaciones.

Tree of Thoughts: pocas ramas y un presupuesto fijo; su valor viene justamente de generar, evaluar y retroceder, que es también la fuente de su sobrecosto.
Reflexion: memoria de fallas asociada a la tarea o clase de tarea, con expiración o puntaje de confianza. Una reflexión autogenerada nunca se convierte sola en regla global permanente.
Al estilo Toolformer: primero juntar un corpus grande de trayectorias exitosas y fallidas; después entrenar elección de tool y generación de argumentos con SFT, y solo entonces pasar a RL.
RL agéntico: exige tres condiciones —recompensa verificable, volumen suficiente de episodios y evaluación protegida contra contaminación y reward hacking (que el modelo aprenda a engañar la métrica)—. Trabajos como Agent Lightning muestran que se puede, pero suma toda una segunda plataforma: generación de rollouts, entrenamiento, versionado de políticas y evaluación.

Roadmap recomendado

Fase	Qué implementar	Criterio para avanzar
Baseline	Prompt + salida estructurada	Eval reproducible
Tools	Tool calling + esquemas	La gran mayoría de llamadas sintácticamente válidas en la suite propia
ReAct	Loop acción/observación + presupuestos	Mejora el éxito frente al baseline
RAG	Recuperación como herramienta	Mejora factualidad y anclaje
Estado	Checkpoints + resumen de contexto	Tareas largas sin degradación excesiva
Seguridad	Permisos, sandbox, aprobaciones	Red-teaming y eval de acciones
Producción	Ejecución durable + tracing	SLO de latencia y fiabilidad
Memoria	Episódica/semántica, selectiva	Evidencia de mejora entre sesiones
Planificación	Plan-and-Solve / jerárquica	Mejora tareas largas, neto de costo
Reflexión	Evaluador + reintento controlado	Mayor éxito tras una falla
Búsqueda	ToT solo en rutas difíciles	La calidad compensa el costo
Aprendizaje	SFT → RL	Dataset y recompensa maduros

Los umbrales de la tabla son objetivos de ingeniería sugeridos, no cifras universales.

La arquitectura final recomendada

Para la mayoría de los agentes comerciales complejos:

┌──────────┐     ┌─────────────────┐
│ Objetivo │ ──► │ Router/política │
└──────────┘     └────────┬────────┘
                          ▼
                 ┌─────────────────┐ sí  ┌──────────────┐
                 │ ¿Tarea simple?  │ ──► │ Una llamada  │
                 └────────┬────────┘     │ al LLM       │
                       no ▼              └──────────────┘
                 ┌─────────────────┐
                 │ Planner liviano │◄───────────────┐
                 └────────┬────────┘                │
                          ▼                         │
                 ┌─────────────────┐                │
                 │ Máquina estados │                │
                 │ + memorias      │                │
                 │ + traza/audit.  │                │
                 └────────┬────────┘                │
                          ▼                         │
                 ┌─────────────────┐                │
                 │ Executor ReAct  │◄────────┐      │
                 │ RAG·APIs·código │         │      │
                 └────────┬────────┘         │      │
                          ▼                  │      │
                 ┌─────────────────┐ fallo   │      │
                 │ Verificador     ├─────────┘      │
                 │                 ├────────────────┘
                 └────────┬────────┘ nueva estrategia
                       ok ▼
           respuesta final (o aprobación humana
           si la acción es de alto impacto)

Toma de ReAct el bucle adaptativo acción-observación; de Plan-and-Solve, la planificación cuando hace falta; de RAG, el anclaje en fuentes; de Reflexion, los reintentos con feedback; de CoALA y MemGPT, la separación entre memoria y estado; y de los sistemas de workflows modernos, el control determinista, la persistencia y el human-in-the-loop.

La prioridad es siempre subir la autonomía solo donde una evaluación demuestre que mejora el resultado neto. Pasar de un LLM con tools a un agente totalmente autónomo no es una progresión obligatoria. En muchas aplicaciones el óptimo está deliberadamente al medio: el software convencional controla seguridad, estado y flujo; el LLM pone razonamiento flexible solo en los nodos donde la variabilidad del problema lo exige.

La frase para llevarse

ReAct es el motor, no el auto: el bucle razonar → actuar → observar decide bien a nivel local, pero el estado, los permisos, los límites y la evaluación los pone el programa, no el modelo.

Referencias primarias

ReAct (paper) · ReAct (repo) · Chain-of-Thought · Toolformer · Reflexion · Reflexion (repo) · Tree of Thoughts · ToT (repo) · Plan-and-Solve · Plan-and-Solve (repo) · CoALA · Recursos CoALA · RAG · MemGPT · Generative Agents · Generative Agents (repo) · LangGraph · AutoGPT · BabyAGI

Material relacionado

Cómo funciona un agente — la base, si el bucle ReAct todavía te suena abstracto
LangGraph 05: tools y ReAct — el bucle implementado paso a paso en un grafo
LangGraph 12: patrones avanzados — reflexión, plan-and-execute y map-reduce en código
Evals 05: evaluar trayectorias y Evals 06: evaluar tool use — cómo medir lo que propone la tabla de evaluación
Seguridad 05: agentes con tools — la defensa en profundidad en detalle
RL 09: test-time compute — cómo los modelos de razonamiento gastan cómputo pensando antes de responder
OpenClaw y Hermes — dos harnesses reales construidos sobre el bucle ReAct
Glosario de agentes IA — ReAct, Reflexion, Tree of Thoughts, pass^k y el resto de los términos