Arquitecturas de agentes de IA: visión general

¿Por qué arquitecturas de agentes?

Un agente LLM es más que un modelo con herramientas: necesita una estructura que determine cuándo razona, cuándo llama a una herramienta, cuándo elabora un plan y cuándo se corrige a sí mismo. Eso es justo lo que describen las arquitecturas de agentes: patrones de diseño recurrentes que en los últimos años se han convertido en el vocabulario común del sector.

Llama la atención lo cerca que están sus orígenes: los cinco patrones canónicos ReAct, Reflexion, Plan-and-Execute, ReWOO y Tree-of-Thoughts surgieron en un breve intervalo entre octubre de 2022 y mayo de 2023, sobre todo en el entorno de Princeton, Google y Northeastern (Shunyu Yao es coautor de tres de los cinco papers). Desde entonces, el sector ha generalizado estos patrones como primitivas de framework (por ejemplo, create_agent de LangChain, antes create_react_agent de LangGraph, o planning=True de CrewAI) o los ha hibridado en patrones sucesores (LATS, LLMCompiler, Plan-and-Act).

Para los responsables de decisión y los tech leads de empresas en Europa, la pregunta clave rara vez es «¿Qué patrón es el más avanzado?», sino «¿Qué patrón resuelve esta tarea concreta con un coste, una latencia y una auditabilidad razonables?». Esta visión general ofrece para ello un mapa independiente de proveedores.

ReAct: razonamiento y acción entrelazados

ReAct (Yao et al., arXiv:2210.03629, octubre de 2022, ICLR 2023) es la base de casi todos los agentes actuales que usan herramientas. La idea: el LLM genera de forma alterna tokens «Thought» (razonamiento) formulados libremente y tokens «Action» (llamadas a herramientas), y lee de vuelta la «Observation» (el resultado de la herramienta). El bucle Thought → Action → Observation → Thought → … se repite hasta que el modelo emite un Finish[answer] final.

El problema que resuelve: el Chain-of-Thought (CoT) puro alucina hechos porque no está anclado en la realidad. Los agentes que solo actúan (action-only), a su vez, no pueden razonar en abstracto sobre objetivos a largo plazo ni recuperarse de errores. ReAct une ambas cosas: el razonamiento guía el uso de herramientas y las observaciones de las herramientas corrigen el razonamiento. En el estudio original, esto supuso +34 puntos porcentuales en ALFWorld (tareas domésticas basadas en texto) y +10 puntos porcentuales en WebShop (navegación de e-commerce) frente a los baselines de imitación/RL de entonces, aunque con modelos de la generación GPT-3/PaLM. Las cifras absolutas hoy están superadas y solo deben leerse como efectos relativos.

Puntos fuertes: baja latencia, poca complejidad de implementación y alta interpretabilidad gracias a una traza de razonamiento fácil de seguir. En LangChain, ReAct cabe en una sola línea (create_agent, se ejecuta sobre LangGraph). Su predecesor create_react_agent está obsoleto desde LangGraph v1. CrewAI usa ReAct internamente en cada agente. n8n implementa el bucle en el nodo nativo AI Agent mediante function calling. La vista de ejecución del nodo registra cada llamada a herramienta. Así, los equipos de marketing sin desarrolladores propios obtienen un log auditable. El antiguo tipo de agente «ReAct Agent» quedó obsoleto en n8n con la versión 1.82.0: los nuevos nodos AI Agent funcionan como «Tools Agent», y con n8n 3.0 desaparece por completo la versión antigua del nodo con la opción ReAct.

Puntos débiles: con descripciones de herramientas ambiguas, el modelo alucina los argumentos de las herramientas. Existe el «reasoning drift»: una vez aferrado a una idea errónea, el agente interpreta las observaciones posteriores de forma que encajen con ella. Y el contexto se infla, porque cada paso vuelve a arrastrar el prompt de sistema y toda la trayectoria anterior (coste O(N·T)). En la práctica, el límite suele estar en 10–25 pasos antes de que dominen la pérdida de contexto o la deriva.

Una lección práctica importante: los modelos frontier modernos dominan de forma nativa el bucle de razonamiento y acción mediante function calling. Según el blog de n8n, el prompting explícito de ReAct se ha vuelto en gran medida innecesario. Hoy lo decisivo es la memoria, los límites de iteraciones y la trazabilidad. El error de producción más frecuente con modelos más débiles es un JSON defectuoso en los argumentos de las herramientas. Por eso, usa salida estructurada o el modo function calling siempre que el proveedor lo admita.

Reflexion: agentes que se critican a sí mismos

Reflexion (Shinn et al., arXiv:2303.11366, NeurIPS 2023) envuelve un agente existente en un bucle de autocorrección. Tres componentes encajan entre sí: un Actor (normalmente un agente ReAct o CoT) genera una trayectoria; un Evaluator la puntúa (de forma binaria, escalar o mediante una suite de tests externa); un modelo de Self-Reflection convierte la puntuación y la trayectoria en feedback verbal: un párrafo de crítica en lenguaje natural que se guarda en una memoria episódica. En el siguiente intento, esta reflexión se antepone en el contexto del Actor. La «actualización de la política» es puramente lingüística; no se modifica ningún peso.

La conclusión central del paper: el análisis de errores que un LLM verbaliza por sí mismo es una señal de aprendizaje más fuerte que una simple recompensa numérica, y todo ello completamente in-context a lo largo de varios intentos. En HumanEval (generación de código Python), Reflexion alcanzó un 91 % pass@1 frente a alrededor del 80 % del baseline de GPT-4 en el momento del estudio.

Pero cuidado: en MBPP, Reflexion rindió por debajo del baseline, porque los tests unitarios autogenerados tenían una alta tasa de falsos positivos y el agente informaba antes de tiempo de un «éxito». Por tanto, Reflexion no mejora los resultados en cualquier caso. Necesita una señal de evaluación de alta calidad. En tareas sin un oráculo claro (escritura creativa, investigación abierta), las reflexiones degeneran en vaguedades, y las «reflexiones confabuladas» (es decir, causas de error mal diagnosticadas) trasladan la corrección errónea al siguiente intento.

Costes: por intento, aproximadamente de 2 a 5 veces una ejecución de ReAct, multiplicado por K intentos; con el habitual K=3, entre 6 y 15 veces una ejecución de ReAct. Los intentos son necesariamente secuenciales, lo que por lo general descarta los casos de uso en tiempo real.

Tres reglas prácticas: primero, limita siempre las iteraciones (max_reasoning_attempts en CrewAI, revision_number ≤ N en LangGraph). Segundo, siempre que sea posible, aporta una señal de ground truth externa (tests unitarios, evaluador RAG, coincidencia regex), porque la autoevaluación por sí sola no es fiable. Tercero, cachea las reflexiones: muchos equipos las persisten en un almacén vectorial por tipo de tarea y construyen así una biblioteca de habilidades emergente. Una nota sobre la terminología: en algunas fuentes (blog de LangChain), «Reflection» designa cualquier bucle de autocrítica, mientras que «Reflexion» se refiere específicamente al paper de Shinn et al. Por eso conviene distinguir entre Reflexion (Shinn et al.) y el patrón Reflection en sentido amplio.

Plan-and-Execute: primero el plan, después la ejecución

El patrón Plan-and-Execute desacopla la planificación de la ejecución. Un Planner elabora una única vez un plan numerado de varios pasos, un Executor (a menudo un subagente ReAct) lo ejecuta paso a paso, y un Replanner decide tras cada ejecución si termina o emite un plan restante ajustado. Conceptualmente se basa en el prompting «Plan-and-Solve» (Wang et al., arXiv:2305.04091, ACL 2023) y en BabyAGI. El patrón debe su nombre y su difusión a la adaptación de LangChain.

La palanca decisiva: planificar es una tarea de razonamiento exigente (modelo grande); ejecutar es usar herramientas paso a paso (modelo más pequeño y barato). Este escalonamiento de modelos puede ahorrar costes, porque los numerosos pasos de ejecución corren en un modelo más pequeño. LangChain describe este ahorro solo de forma cualitativa, y el artículo original de LangChain admite que el patrón necesita más llamadas al modelo que un agente ReAct. Además, los planes formulados de forma explícita son auditables, un argumento de peso en contextos empresariales y de compliance.

Puntos débiles: fragilidad del plan. Si el plan previo es erróneo, el Executor desperdicia llamadas en pasos condenados al fracaso hasta que el Replanner lo detecta. La ejecución sigue siendo secuencial (sin paralelismo real). Y cada replanificación vuelve a llamar al modelo grande; en entornos muy estocásticos se replanifica casi en cada paso, lo que se come la ventaja en costes. Regla general: úsalo cuando las tareas se dividan en más de tres pasos independientes, exista un oráculo claro para validar el plan y el usuario no perciba directamente la latencia. No lo uses si el entorno es muy estocástico. En ese caso, el bucle reactivo de ReAct es claramente mejor. El patrón «Orchestrator-Workers» de Anthropic es, en esencia, lo mismo con otro envoltorio.

ReWOO: razonar sin observar constantemente

ReWOO (Xu et al., arXiv:2305.18323, mayo de 2023) es la respuesta optimizada en costes al hambre de tokens de ReAct. Tres módulos: un Planner genera en una sola llamada al LLM toda la cadena de pasos del plan y llamadas a herramientas, y una sintaxis de variables (#E1, #E2, …) permite referirse a resultados que aún no existen. Un Worker ejecuta las herramientas en el orden fijado y sustituye los marcadores de posición por los resultados reales. Por último, un Solver lee en una última llamada al LLM la tarea junto con todas las evidencias y formula la respuesta.

El efecto: N llamadas al LLM se sustituyen por exactamente dos (Planner + Solver), independientemente del número de pasos con herramientas. En HotpotQA, el paper reporta una eficiencia de tokens 5 veces mayor con un +4 % de precisión frente a ReAct, y una reducción de tokens consistente en seis benchmarks de NLP. ReWOO también es robusto ante fallos de herramientas: el plan ya está fijado y el Solver detecta limpiamente las evidencias que faltan.

Límites: no hay adaptación a mitad de la ejecución. Si la evidencia 3 contradice el plan, ReWOO no puede replanificar en la misma pasada. Sin contexto del entorno, al Planner le cuesta manejar ecosistemas de herramientas desconocidos (hace falta few-shot prompting o fine-tuning). Y las herramientas se ejecutan de forma secuencial. El paralelismo real solo llega con su sucesor LLMCompiler (Kim et al., arXiv:2312.04511) mediante un DAG.

Para las agencias de marketing, ReWOO suele ser el mejor patrón en n8n: el punto fuerte de n8n son los workflows deterministas y declarativos, la sustitución de variables es nativa, y tareas como «investiga X → enriquece → formatea → envía» resultan así fáciles de depurar, baratas y tolerantes a fallos. Los informes de proyectos reales hablan de una reducción de alrededor del 65 % en costes de tokens con una ganancia de precisión del 4–5 %. Antipatrón: no uses ReWOO en tareas en las que los resultados de las herramientas invaliden el plan con frecuencia (p. ej., navegación web interactiva); ahí Plan-and-Execute o ReAct son mejores.

Tree-of-Thoughts: búsqueda en lugar de línea recta

Tree-of-Thoughts (Yao et al., arXiv:2305.10601, NeurIPS 2023) rompe con la lógica estrictamente de izquierda a derecha del CoT. En lugar de una sola cadena de pensamiento, se despliega un árbol: cada nodo es un «Thought» (una solución parcial), en cada punto el modelo genera k candidatos, un State-Evaluator los puntúa (por ejemplo, con una votación seguro/quizá/imposible) y un algoritmo de búsqueda (BFS o DFS con backtracking) recorre el árbol. El paper lo plantea explícitamente como una búsqueda de «Sistema 2», inspirada en los formalismos de resolución de problemas de Newell & Simon.

Los resultados en tareas centradas en la búsqueda son drásticos: Game of 24 resuelto en un 74 % (frente al 4 % con CoT y el 7,3 % con IO), Mini-Crosswords a nivel de palabra en un 60 % (frente al 16 % con CoT) y escritura creativa con mayor coherencia. Sin embargo, el precio es enorme: aproximadamente de 10 a 100 veces más tokens que una sola llamada CoT, y aún más con árboles de búsqueda anchos y profundos. La tabla de órdenes de magnitud de abajo calcula con anchura b=5 y profundidad d=3, y llega así a 50–150×. Además, la eficacia depende mucho de la calidad del generador (GPT-3.5+ToT solo alcanzó un 19 % en lugar de un 74 % en Game of 24).

La lección de campo más importante sobre ToT: para el razonamiento general, en 2026 está en gran medida obsoleto, porque los modelos de razonamiento modernos (como GPT-5 con razonamiento, Claude con Extended Thinking o Gemini 3 con Thinking) hacen la búsqueda internamente en el modelo. ToT sigue siendo relevante como base conceptual para la búsqueda en árbol de los agentes (es la base de LATS) y para tres nichos: sectores regulados sujetos a auditoría, puzles/optimización con recompensas verificables y despliegues de modelos pequeños con proposers baratos. En herramientas como n8n, ToT no escala en la práctica por la explosión combinatoria. La aproximación limpia es el «Best-of-N sampling»: varias ejecuciones en paralelo de las que un crítico elige la mejor (ToT con profundidad 1).

Routing y patrones jerárquicos

Más allá de los cinco patrones de razonamiento, Anthropic menciona en «Building Effective Agents» (diciembre de 2024) otros dos patrones estructurales que en la práctica suelen formar el marco. El routing clasifica una entrada y la dirige a una ruta especializada, por ejemplo, un paso clasificador que reparte las solicitudes de soporte según su tipo entre distintos prompts o modelos. Las arquitecturas jerárquicas anidan un orquestador con subagentes: un LLM coordinador descompone la tarea de forma dinámica y delega en agentes subordinados. Plan-and-Execute con subagentes ReAct es exactamente esta variante (el Orchestrator-Workers de Anthropic).

En cuanto a la prudencia con las jerarquías, la lección más citada la aporta Cognition (Devin): «Don't Build Multi-Agents» (junio de 2025) advertía de que los agentes en paralelo toman implícitamente decisiones contradictorias y producen resultados frágiles. La posición actualizada «Multi-Agents: What's Actually Working» (abril de 2026) considera viable el enfoque multiagente en setups paralelos en lectura y de un solo hilo en escritura. Traducido para clientes de agencia: apuesta por un agente potente con herramientas. Usa subagentes en paralelo solo para obtener información, nunca para escrituras ni cambios de estado.

Comparativa: qué patrón usar en cada caso

La siguiente tabla de órdenes de magnitud debe leerse como una referencia aproximada (estimaciones sintetizadas a partir de datos de los papers e informes de campo, no mediciones directas). Mídelo con tu propia carga:

El hilo conductor para la práctica

En todos los patrones, la lección de campo más importante de los posts de producción de 2024–2026 (Anthropic, Cognition, LangChain) es sorprendentemente sobria: empieza con el patrón más sencillo que funcione (normalmente ReAct) y escala a planificación, Reflexion o búsqueda solo cuando los modos de fallo medidos lo exijan. Anthropic lo formula así: «Las implementaciones más exitosas usaban patrones sencillos y componibles en lugar de frameworks complejos».

Los patrones sucesores desde el otoño de 2023 son, en esencia, recombinaciones de los cinco originales: LATS (Zhou et al., octubre de 2023) = ToT + Reflexion + MCTS, disponible en LangGraph como implementación de referencia; LLMCompiler (Kim et al., diciembre de 2023) = ReWOO + DAG paralelo, según el paper hasta 3,7× más rápido que ReAct; Plan-and-Act (Erdogan et al., marzo de 2025) = Plan-and-Execute para horizontes largos. También los frameworks convergen en una primitiva común de state graph más tool calling: Microsoft ha consolidado AutoGen y Semantic Kernel en el Microsoft Agent Framework (AutoGen está oficialmente en modo de mantenimiento), y LangChain ha sustituido create_react_agent por langchain.agents.create_agent con middleware. Para los responsables de decisión que evalúan el stack de Microsoft, esa es la bifurcación relevante.

Para terminar, tres reglas prácticas innegociables: primero, todo agente necesita límites estrictos (recursion_limit, max_iterations); de lo contrario, los bucles disparan los costes. Segundo, las herramientas de observabilidad (LangSmith, Langfuse, Arize Phoenix) son obligatorias de facto. Tercero, por compliance hay que persistir trazas completas de Thought/Action/Observation con anonimización de PII. Esto es clave sobre todo en sistemas relevantes para el RGPD y el Reglamento de IA de la UE.

Nota: las afirmaciones sobre compliance de este texto son informativas y no constituyen asesoramiento jurídico. Las cifras de benchmarks mencionadas proceden mayoritariamente de los papers originales de 2022–2023 (era GPT-3.5/GPT-4) y deben entenderse como tamaños de efecto relativos, no como valores absolutos para los modelos frontier actuales.