Cuando desplegamos por primera vez un agente de IA para un cliente del sector industrial — tarea: automatizar la elaboración de informes a partir de varios sistemas — arrancamos ingenuamente con un bucle simple, un solo LLM y una serie de herramientas. Funcionó... mientras nada salió diferente de lo previsto. En cuanto una herramienta devolvió una salida inesperada, el agente entró en bucle y estuvo generando tokens durante 40 minutos hasta que lo detuvimos manualmente. El problema no era el modelo. El problema era la arquitectura — no diseñada para condiciones reales.
Hoy existen tres patrones predominantes para las arquitecturas de agentes de IA: ReAct, Plan-and-Execute y reflexión. Cada uno tiene su lugar, cada uno tiene sus límites. Este artículo es un marco de decisión — cuándo elegir cada patrón, qué esperar de él y dónde os va a meter en problemas.
Por qué importa la elección de la arquitectura
La elección de la arquitectura no es un mero detalle técnico. Influye directamente en cuatro métricas que importan en producción:
- Fiabilidad — cómo responde el agente a salidas inesperadas de herramientas o a errores
- Costes — cuántos tokens consume por tarea
- Latencia — con qué rapidez recibe el usuario el resultado
- Depurabilidad — con qué facilidad encontráis dónde y por qué falló el agente
Aclaración importante: ReAct, Plan-and-Execute y Reflexion son patrones académicos de los años 2022–2023 (Yao et al. 2022 para ReAct). LangGraph, AutoGen, CrewAI y otros frameworks *implementan* estos patrones — pero no los inventaron. La elección del framework es una decisión secundaria. La primaria es la elección del patrón.
ReAct: el bucle Reason-Act-Observe
ReAct (Reasoning + Acting) es el patrón más sencillo y más extendido. El agente trabaja en un bucle:
- 1.Reason — a partir del estado actual y del historial, el LLM «razona» (genera texto que describe el razonamiento)
- 2.Act — selecciona y llama a una herramienta con parámetros concretos
- 3.Observe — recibe la salida de la herramienta y la incorpora al contexto
- 4.Repite hasta alcanzar el objetivo o llegar a la respuesta final
El punto fuerte de ReAct es la adaptabilidad. Si algo cambia durante la ejecución — una herramienta devuelve un resultado inesperado, una API cambia de formato — el agente lo ve en la fase Observe y puede cambiar de rumbo. No según un plan escrito de antemano, sino de forma reactiva.
Dónde funciona bien ReAct
- Tareas con 2–4 pasos y un objetivo claro (busca X, procesa Y, escribe Z)
- Herramientas interactivas donde el contexto cambia en tiempo real
- Prototipado — ReAct es el más rápido de implementar
- Cuando queréis el log de auditoría más sencillo posible (cada paso Reason-Act-Observe es visible)
Dónde falla ReAct
- Tareas largas con muchos pasos — cada nuevo paso añade al contexto todo el historial; los costes crecen cuadráticamente
- Tareas paralelas — ReAct es secuencial, no puede ejecutar varias ramas al mismo tiempo
- Sin límite `max_steps` es peligroso — y no es una exageración. Un agente sin límite de pasos configurado puede quedarse atascado en bucle durante la noche y generar miles de llamadas a API innecesarias — y con ellas una factura de varios miles de euros. Lo vemos en la práctica; no es un riesgo hipotético.
Corrección importante de un mito extendido: la palabra «Reason» en ReAct *no significa* que el agente razone correctamente. El paso Reason es una salida lingüística — el LLM genera texto que parece razonamiento. Puede estar lleno de errores, y el modelo no lo señala de ninguna manera. El «pensamiento» no verificable es una de las causas más frecuentes de fallos silenciosos en agentes ReAct.
Perfil de costes de ReAct
Una tarea ReAct típica consume 2 000–3 000 tokens con 3–4 pasos. A partir de 8+ pasos el consumo puede alcanzar los 10 000–20 000 tokens por tarea, porque todo el historial se repite en cada ventana de contexto. En carga de producción esto se notará en la factura.
Plan-and-Execute: primero el plan, luego los pasos
Plan-and-Execute (P&E) divide el agente en dos fases:
- 1.Planificador — recibe el objetivo y genera un plan explícito de pasos (p. ej. «paso 1: cargar datos de la API, paso 2: transformar formato, paso 3: guardar en la base de datos, paso 4: enviar el informe»)
- 2.Ejecutor — ejecuta los pasos según el plan, uno a uno, sin replanificar
Ventaja clave: el planificador y el ejecutor no tienen por qué ser el mismo modelo. Esto es económicamente interesante — un modelo caro y potente (p. ej. de la clase de Claude Opus o GPT) se encarga de la planificación, donde importa la calidad. Un modelo barato y rápido se encarga de la ejecución, donde importan la velocidad y el precio. Para tareas largas con N pasos, esto puede resultar más barato que un ReAct puro.
Dónde funciona bien P&E
- Tareas largas y estructuradas (5+ pasos con lógica clara)
- Procesamiento por lotes — cuando hay que procesar 1 000 documentos con el mismo procedimiento
- Pipelines auditables — el plan es un documento explícito que el cliente puede ver antes del arranque
- Resistencia a prompt injection — la investigación indica que P&E tiene cierta ventaja inherente: el ejecutor no tiene acceso a las instrucciones del planificador, por lo que un atacante en los datos tiene más difícil redirigirlo (aunque no es una protección completa)
Dónde falla P&E
El P&E básico tiene un plan fijo. Si las condiciones cambian durante la ejecución — la API devuelve un formato diferente, el paso 3 falla — el agente continúa según el plan antiguo o se bloquea. El dynamic replanning (replanificación tras un error) es una extensión, no una característica básica de P&E. Hay que implementarlo explícitamente.
Otro mito que corregir: P&E *no es siempre más preciso* que ReAct. En entornos dinámicos donde las condiciones cambian durante la ejecución, ReAct es más adaptable. P&E es mejor donde el entorno es predecible y el plan seguirá siendo válido hasta el final.
Perfil de costes de P&E
Una tarea P&E típica consume 3 000–4 500 tokens (incluida la fase de planificación). A primera vista es más caro que ReAct. Pero para tareas con 8+ pasos el consumo total es menor — el ejecutor trabaja con un contexto más corto que el bucle ReAct, que acumula todo el historial. Recomendación: para tareas cortas (2–4 pasos) elegid ReAct; para tareas largas (6+ pasos) valorad P&E.
Reflexión y autocrítica
Reflexión (Reflexion, Shinn et al. 2023) añade una capa de autoevaluación sobre ReAct o P&E:
- 1.El agente ejecuta la tarea (ReAct o P&E)
- 2.El módulo de reflexión evalúa el resultado — «¿se alcanzó el objetivo? ¿Dónde se produjeron errores?»
- 3.A partir de la reflexión se actualiza la memoria del agente o se repite el paso con un enfoque ajustado
Ejemplo de resultados: en tareas de CodeContests, GPT-4 pasó de aproximadamente un 19 % de éxito con un prompt simple a alrededor de un 44 % con un enfoque iterativo orientado a tests (el flujo publicado AlphaCodium). Es un aumento real — precisamente en tareas con verificación determinista.
Dónde ayuda la reflexión
- Tareas de codificación con verificación determinista (el código pasa los tests o no)
- Salidas iterativas — cuando la primera versión nunca es suficiente y se quiere mejora automática
- Análisis complejos, donde se necesita una segunda mirada sobre el resultado
Límites de la reflexión
Límite crítico: cuando el mismo modelo genera la salida y la crítica, la reflexión tiende a repetir los mismos errores. El modelo no ve los huecos en su propio razonamiento. Estudios de replicación de 2025 lo confirmaron — el Reflexion de agente único en ciclos iterativos converge hacia la misma respuesta (incorrecta). La solución es bien un modelo diferente para la verificación, bien un verificador externo determinista (tests, linter, validación de esquema).
Más sobre cómo los guardrails para agentes de IA ayudan a capturar estos fallos antes de que lleguen al usuario.
Cuándo basta con una sola llamada al LLM
Antes de elegir una arquitectura de agente hay que hacerse la pregunta: *¿realmente necesito un agente?*
Estimamos que el 40–50 % de los casos de uso con los que los clientes llegan solicitando un agente se resuelven con una o dos llamadas al LLM sin ningún bucle. Ejemplos:
- Clasificación de un documento (una llamada, structured output)
- Extracción de campos de una factura (una llamada + JSON mode)
- Generación de un informe a partir de datos preparados (una llamada, prompt largo)
- Resumen con citas (una llamada + pipeline agentic RAG)
Regla: si se pueden definir de antemano con precisión las entradas, las salidas y la transformación — no se necesita un agente. El agente añade valor cuando los pasos no se conocen de antemano o el entorno es dinámico.
Decisión relacionada: chatbot vs copilot vs agente — dónde están los límites exactos entre estos conceptos.
Marco de decisión
En lugar de una tabla (que simplificaría el trade-off) ofrecemos una serie de preguntas:
1. ¿Cuántos pasos tiene la tarea? - 1–3 pasos → una llamada LLM o ReAct simple - 4–7 pasos, entorno predecible → Plan-and-Execute - 8+ pasos con lógica paralela → P&E + ejecutor DAG o multi-agent
2. ¿Cambia el entorno durante la ejecución? - No (procesamiento por lotes, procedimiento determinista) → P&E - Sí (interactivo, datos en tiempo real, API impredecibles) → ReAct
3. ¿Necesitáis una salida auditable? - Sí, el cliente quiere ver el plan antes del arranque → P&E - No, lo importante es el resultado → ReAct (menor tiempo de arranque)
4. ¿Cuál es el coste del error? - Bajo (herramienta interna, fácilmente corregible) → ReAct con límite max_steps - Alto (cliente, área regulada) → P&E + reflexión + human-in-the-loop
5. ¿Tenéis un equipo dedicado al mantenimiento? - No → El patrón más simple posible. ReAct con max_steps claro, logging de cada paso. - Sí → Podéis permitiros P&E + dynamic replanning + reflexión.
Arquitecturas híbridas en la práctica
En producción casi nunca vemos un ReAct puro ni un P&E puro. Combinaciones habituales:
- P&E + ejecutor ReAct — el planificador genera los pasos, cada paso lo ejecuta un mini-agente ReAct con acceso a herramientas
- ReAct + reflexión — tras completar el bucle ReAct se activa el módulo de reflexión, que evalúa la calidad de la salida
- P&E + dynamic replanning — ante el fallo de un paso se reconsidera todo el plan, no solo ese paso
LangGraph es hoy el estándar de facto para implementar estos patrones híbridos en Python. Alternativas como AutoGen (Microsoft) o CrewAI son potentes para la coordinación multi-agent, pero LangGraph tiene el mayor ecosistema y estabilidad en producción.
Una perspectiva más amplia sobre cuánto cuesta un agente en producción, incluida la tarificación por llamada y formas de optimización, la encontraréis en un artículo aparte.
Depurabilidad — la dimensión infravalorada
La arquitectura también influye en la facilidad para encontrar un error. Desde la práctica:
ReAct: cada paso Reason-Act-Observe es visible en el trace log. Cuando el agente falla en el paso 7, se ve exactamente qué entrada Observe recibió y qué Reason generó. Bien depurable — si se registra correctamente cada paso.
P&E: el plan es un documento explícito — es fácil ver dónde el ejecutor se desvió del plan. Pero los errores en el propio plan (lógica incorrecta del planificador) son más difíciles de detectar, porque el planificador se ejecuta una vez y sus decisiones no son incrementales.
Reflexión: la peor de depurar. Los ciclos iterativos producen muchos logs, y cuando el modelo repite el mismo error en cada ciclo puede ser difícil determinar la causa raíz.
Más sobre cómo configurar la observabilidad para agentes de IA — tracing, logging y alertas — en despliegues en producción.
Preguntas frecuentes
¿Qué es la arquitectura ReAct y dónde surgió?
ReAct (Reasoning + Acting) es un patrón para agentes de IA diseñado por Yao et al. en 2022 (publicación académica). El agente trabaja en el bucle Reason–Act–Observe: el LLM razona, selecciona una herramienta, recibe el resultado y repite. LangGraph, LangChain y otros frameworks implementan este patrón, pero no lo inventaron.
¿Cuándo elegir Plan-and-Execute en lugar de ReAct?
Plan-and-Execute es adecuado para tareas largas y estructuradas (6+ pasos) con un entorno predecible, donde se quiere un plan auditable antes del arranque. ReAct es mejor para tareas cortas y dinámicas, donde las condiciones cambian durante la ejecución. Para 1–3 pasos, valorad si realmente necesitáis un agente.
¿Es Plan-and-Execute siempre más preciso que ReAct?
No. P&E tiene ventaja en tareas estructuradas y predecibles. En entornos dinámicos donde las condiciones cambian durante la ejecución, P&E falla — el agente continúa según un plan obsoleto. ReAct es más adaptable porque reacciona a cada salida Observe.
¿Por qué es peligroso arrancar un agente ReAct sin límite de max_steps?
Sin un límite de pasos configurado, el agente puede entrar en bucle (p. ej. llamando repetidamente a una herramienta que devuelve un error, pero el agente no lo evalúa como estado terminal). Un agente así, sin control, puede generar durante la noche miles de llamadas y una factura de varios miles de euros. Todo agente en producción debe tener configurado un parámetro explícito max_steps o max_iterations.
¿Puedo combinar ReAct y reflexión?
Sí, las arquitecturas híbridas son habituales en producción. Combinación típica: bucle ReAct para la ejecución de pasos, módulo de reflexión al finalizar para evaluar la calidad de la salida. Aviso importante: la reflexión solo funciona de forma fiable cuando la salida la evalúa un modelo diferente o un verificador externo determinista (tests, validación de esquema) — no el mismo modelo que generó la salida.
*Si estáis valorando el despliegue de un agente de IA en vuestra empresa y no tenéis claro qué arquitectura es la adecuada para vuestro caso de uso, con mucho gusto evaluamos la situación concreta. En MP Industrial Solutions ayudamos a los clientes a elegir el enfoque que se ajusta a sus requisitos reales de fiabilidad, costes y capacidades del equipo — no el que queda más impresionante en una demo.*