Plan-and-Execute: cuando la planificación se separa de la ejecución

Plan-and-Execute es una arquitectura de agentes en la que un Planner elabora primero un plan completo de varios pasos y un Executor lo va resolviendo paso a paso. Un Replanner ajusta el plan cuando hace falta. Separar la planificación de la ejecución permite ejecutar cada paso con un modelo más pequeño y mejora el control sobre las tareas de larga duración frente a ReAct puro.

Primero, las respuestas rápidas:

• Qué resuelve: al razonamiento paso a paso de ReAct le falta visión global: en tareas largas, el agente olvida el objetivo original. Plan-and-Execute impone el objetivo mediante un plan explícito elaborado por adelantado.
• Por qué puede salir más barato: un modelo más pequeño y económico ejecuta cada paso. El modelo grande solo planifica y comprueba después de cada paso si el plan sigue en pie (escalonamiento de modelos).
• El compromiso central: mejor control y planes auditables a cambio de planes frágiles y falta de paralelismo real. En entornos muy estocásticos, ReAct es claramente superior.

Origen: Plan-and-Solve, BabyAGI y la adaptación de LangChain

Aquí importa situarlo con precisión, porque la atribución suele simplificarse. El patrón de prompting de base procede de Plan-and-Solve Prompting (Wang et al., arXiv:2305.04091, ACL 2023). El paper propuso un prompt zero-shot en dos fases, que viene a decir «Primero elaboremos un plan / Ejecutemos el plan», y con él superó a Zero-Shot-CoT en razonamiento matemático.

Sin embargo, el nombre del agente, «Plan-and-Execute», viene de la adaptación de LangChain, no del paper original. Además, la arquitectura se inspiró en BabyAGI (Yohei Nakajima, 2023). Formulado con rigor, sería: la arquitectura de agentes Plan-and-Execute popularizada por LangChain, basada en el prompting Plan-and-Solve.

Anthropic describe un patrón muy relacionado en Building Effective Agents (diciembre de 2024): en el workflow Orchestrator-Workers, un LLM central descompone una tarea de forma dinámica, delega las partes en LLM workers y combina sus resultados.

Los tres componentes

La variante de LangGraph consta de tres nodos:

1. Planner: genera una sola vez un plan numerado de varios pasos (Plan: List[str]).
2. Executor: normalmente un subagente ReAct que va resolviendo los pasos del plan uno tras otro.
3. Replanner: después de cada ejecución decide si devuelve una Response final (termina) o emite un plan nuevo, editado si hace falta, para el trabajo restante.

El flujo:

Input → Planner → [Plan: Schritt_1, Schritt_2, …] → Executor(Schritt_1) → Replanner → (Executor(Schritt_2) → Replanner → …) → Response

La innovación central: Plan-and-Execute desacopla la planificación (una tarea de razonamiento pesada, en la que compensa un modelo grande) de la ejecución (uso de herramientas paso a paso, para el que basta un modelo más pequeño y barato).

Ventajas frente a ReAct puro

• Ejecución de varios pasos más rápida: el Executor resuelve por sí solo un paso del plan con todas sus llamadas a herramientas. El modelo grande no vuelve a intervenir hasta después, y no tras cada acción individual.
• Ahorro de costes gracias al escalonamiento de modelos: un gran modelo de frontera planifica y un modelo pequeño y barato ejecuta los pasos. LangChain describe esta ventaja de costes frente a ReAct solo de forma cualitativa. El número total de llamadas no baja necesariamente: en 2023, LangChain citó expresamente más llamadas al LLM como el precio del patrón y reconoció que muchas de las ventajas no se habían sometido a benchmarks.
• Planes explícitos y auditables: un argumento de peso para aplicaciones empresariales y de cumplimiento normativo, porque el plan está a la vista antes de la ejecución.
• Visión global: el objetivo general se mantiene a lo largo de trayectorias largas, en lugar de perderse por la «deriva del razonamiento» de ReAct.

Puntos débiles y modos de fallo

Plan-and-Execute no es una panacea. Sus límites principales:

• Fragilidad del plan: si el plan inicial es erróneo, el Executor malgasta llamadas en pasos sin salida hasta que el Replanner se da cuenta. El propio paper de Plan-and-Solve documenta errores de cálculo, pasos que faltan y malentendidos semánticos.
• Sin paralelismo real: los planes son listas y el Executor las recorre en secuencia. Justo eso es lo que aborda LLMCompiler (Kim et al., arXiv:2312.04511), que emite un DAG en lugar de una lista.
• Coste de replanificar: si el Replanner tiene que replanificar a menudo, se añaden pasos, y cada paso adicional cuesta otra pasada de Executor y Replanner. En entornos ruidosos, esto ocurre casi en cada paso y erosiona la ventaja de costes.
• La elección del modelo es decisiva: si el modelo Executor es demasiado débil para los pasos, fallan más pasos, el Replanner tiene que replanificar más a menudo y la ventaja de costes se reduce.

ReAct vs. Plan-and-Execute: comparación directa

La fila de tokens describe tendencias, no mediciones. Compruébalo con tu propia carga de trabajo.

Pseudocódigo: el bucle de Plan-and-Execute

Simplificado, siguiendo la lógica del esquema de estado de LangGraph:

```

State: input, plan (lista), past_steps (completados), response

def planner(state):
# un modelo grande crea UNA SOLA VEZ el plan completo
state.plan = big_model.plan(state.input) # p. ej. ["1. ...", "2. ...", "3. ..."]
return state

def executor(state):
paso = state.plan[0] # siguiente paso pendiente
resultado = small_model.run_react(paso) # subagente ReAct barato + herramientas
state.past_steps.append((paso, resultado))
return state

def replanner(state):
# o ha terminado -> Response, o emite un nuevo plan para lo que queda
if big_model.is_done(state):
state.response = big_model.final_answer(state)
return state, "END"
state.plan = big_model.replan(state.input, state.past_steps)
return state, "executor"

Grafo: planner -> executor -> replanner -> (executor | END)

```

Lo decisivo: big_model (caro) solo se ejecuta en planner y replanner; small_model (barato) soporta la carga de ejecución real.

Ejemplo concreto: informe de marketing diario

Una agencia crea un agente que cada mañana elabora un informe de la competencia. Tarea: «Investiga a los tres competidores principales, recopila su contenido nuevo de las últimas 24 horas, resúmelo y envíalo por correo electrónico».

Con ReAct puro, el agente volvería a llamar al modelo completo después de cada acción individual (búsqueda, scraping, resumen), incluida toda la ventana de contexto acumulada hasta ese momento. Con 12 pasos, eso son 12 llamadas caras más un prefijo que no para de crecer.

Con Plan-and-Execute, el Planner elabora el plan una sola vez (1 llamada cara):

```
Plan:

1. Identificar a los competidores A, B, C
2. Para cada uno: extraer con scraping el contenido nuevo de blog y redes sociales de las últimas 24h
3. Hacer un breve resumen por competidor
4. Dar formato al informe completo
5. Enviarlo por correo electrónico al equipo
   ```

Los pasos 2-5 pasan entonces por un Executor barato. El modelo grande solo comprueba después de cada paso si el plan sigue en pie y replanifica si, por ejemplo, una fuente no está disponible. Si eso sigue siendo la excepción, esta tarea por lotes ahorra costes, porque el trabajo real recae en el modelo barato. Además, la agencia tiene el plan documentado de forma trazable.

Uso en frameworks (situación en 2026)

• LangGraph: soporte nativo con tutorial oficial. Esquema de estado canónico con input, plan: List[str], past_steps y response; nodos planner, agent (Executor) y replan. Una arista condicional should_end lleva de vuelta al Executor o a END.
• CrewAI: encaje directo mediante Crew(planning=True). Esto activa un AgentPlanner que, antes de cada iteración de la crew, crea un plan paso a paso y lo inyecta en cada descripción de tarea. Con Process.hierarchical más manager_agent/manager_llm se añade una capa de gestión que replanifica.
• AutoGen / Microsoft Agent Framework: se implementa con un group chat que incluye un agente Planner dedicado y agentes worker (RoundRobinGroupChat o SelectorGroupChat). En Microsoft Agent Framework, la orquestación Magentic es lo que más se acerca al patrón: un agente manager crea un plan de tareas, reparte los pasos entre agentes especializados y replanifica cuando el progreso se estanca. Si se quiere, una persona aprueba el plan antes de la ejecución. En 2026, AutoGen está en modo de mantenimiento; Microsoft remite los proyectos nuevos a MS Agent Framework.
• n8n: no hay un nodo nativo de Plan-and-Execute, pero es viable con dos nodos AI Agent (Planner + Executor) conectados mediante un bucle SplitInBatches que recorre los puntos del plan. Limitación: sin almacenamiento externo, los bucles de n8n no conservan el estado entre ejecuciones. Eso basta para trabajos por lotes (informes diarios, pipelines de contenido), pero no para agentes en tiempo real de alta frecuencia.

Cuándo usarlo y cuándo no

Usa Plan-and-Execute cuando (a) las tareas se puedan descomponer en más de tres pasos independientes, (b) tengas una instancia clara que verifique la validez del plan y (c) la latencia no sea directamente visible para el usuario.

Prescinde de él si el entorno es muy estocástico. Si cualquier observación puede invalidar el plan (por ejemplo, en la navegación web interactiva), el bucle reactivo de ReAct es claramente mejor. Para workflows críticos en materia de cumplimiento normativo en la UE (RGPD, Reglamento de IA de la UE) encaja Plan-and-Execute con human-in-the-loop: plan auditable y ejecución trazable paso a paso.

Para agencias y decisores B2B

Plan-and-Execute es el patrón natural para procesos de varios pasos planificables y recurrentes, como los que forman el día a día de una agencia: pipelines de reporting, workflows de investigación, producción de contenido. El patrón aporta dos cosas: una posible reducción de costes gracias al escalonamiento de modelos y un plan revisable que está a la vista desde el principio. Ambas responden justo a las exigencias de cumplimiento normativo y control presupuestario del entorno B2B en Europa. Aun así, el consejo pragmático que deja la experiencia en producción también vale aquí: empieza con el patrón más simple que funcione (casi siempre ReAct) y cambia a Plan-and-Execute solo cuando lo justifiquen modos de fallo medidos, como la deriva del razonamiento, los costes o la falta de visión global. Si estás evaluando qué arquitectura de agentes encaja con tu caso de uso concreto, Blck Alpaca te ayuda con la selección, el escalonamiento de modelos y una implementación auditable.