Planificar es el paso que separa a un agente que resuelve tareas de una frase de otro capaz de completar un trabajo largo de varios pasos. En lugar de decidir la siguiente acción sobre la marcha, un agente que planifica primero descompone el objetivo en subtareas ordenadas y luego las ejecuta. En esta guía verás por qué la planificación importa, cómo se descompone una tarea, qué estructuras usan los planificadores y cómo replanificar cuando algo sale mal. La misma explicación está disponible en inglés.

Puntos clave

  • Planificar es descomponer un objetivo en subtareas ordenadas antes de actuar, en vez de improvisar acción por acción.
  • El artículo Plan-and-Solve (arXiv 2305.04091[1], ACL 2023) demostró que pedir al modelo que primero trace un plan reduce los errores de pasos omitidos frente al razonamiento directo.
  • En el juego de las 24, GPT-4 con razonamiento encadenado resolvía el 4 % de las partidas; con el método Tree of Thoughts, que explora un árbol de planes, subió al 74 %.
  • El patrón planificador-ejecutor separa dos papeles: un planificador que traza la lista de pasos y un ejecutor que los realiza uno a uno con herramientas.
  • La replanificación es la pieza que hace robusto al agente: tras cada paso revisa lo que ha aprendido y ajusta el plan restante.

¿Por qué un agente necesita planificar?

Un agente que solo mira el paso siguiente funciona bien en tareas cortas, pero se pierde en las largas. Sin un plan, cada decisión depende únicamente del estado actual, así que el agente olvida el objetivo general, repite trabajo o se queda atascado en un callejón sin salida. El bucle agéntico (el ciclo de razonar, actuar y observar con el que un agente usa herramientas paso a paso) resuelve la reacción inmediata, pero no garantiza que la suma de esas reacciones llegue a la meta.

La planificación añade una capa por encima de ese bucle: antes de tocar ninguna herramienta, el agente escribe una hoja de ruta. Esa hoja de ruta cumple tres funciones. Sirve de memoria externa que mantiene el objetivo a la vista; permite estimar cuántos pasos hará falta; y deja ver los errores antes de ejecutarlos, porque un plan malo se detecta leyéndolo, no gastando llamadas en él. El artículo Plan-and-Solve lo formalizó como una técnica de dos partes: «primero, trazar un plan que divida la tarea completa en subtareas más pequeñas, y después, ejecutar las subtareas según el plan».

Descomposición de tareas en subtareas

Descomponer es partir un objetivo grande en trozos que el agente sepa resolver de uno en uno. Supón que el objetivo es «publica un resumen del último informe de ventas en el blog». Un modelo no puede hacerlo de una sola llamada, pero sí puede planear la secuencia:

Objetivo: publicar un resumen del ultimo informe de ventas en el blog.

Plan:
  1. Leer el archivo informe-ventas.csv y calcular el total por region.
  2. Redactar un resumen de 200 palabras con esas cifras.
  3. Publicar el resumen como borrador en el CMS.

Cada línea es una subtarea concreta, con un verbo de acción y un resultado comprobable. La buena descomposición cumple dos reglas: los pasos son independientes en la medida de lo posible, y cada uno deja un resultado que el siguiente puede usar. Anthropic describe esta idea con dos de sus patrones. En el encadenado de prompts, «se descompone una tarea en una secuencia de pasos» fijos; en el patrón orquestador-trabajadores, «un modelo central descompone las tareas de forma dinámica, las delega en modelos trabajadores y sintetiza sus resultados», útil cuando no sabes de antemano cuántas subtareas harán falta.

Planificadores: del árbol de tareas al grafo

No todos los planes son una lista recta. Según la tarea, un planificador puede organizar las subtareas en tres formas cada vez más ricas:

  • Lista secuencial. Los pasos van uno detrás de otro. Es lo que produce Plan-and-Solve y basta para tareas lineales.
  • Árbol de tareas. El agente explora varias ramas de plan a la vez y se queda con la mejor. El método Tree of Thoughts (arXiv 2305.10601[2]) hace justo esto: genera pensamientos alternativos, los evalúa y descarta las ramas malas. Ese árbol es lo que llevó el juego de las 24 del 4 % al 74 % de aciertos, a cambio de gastar unos 5 500 tokens por problema.
  • Grafo de dependencias. Cuando unas subtareas dependen de otras, el plan se representa como un grafo dirigido. La arquitectura LLMCompiler organiza así las tareas y las ejecuta en paralelo en cuanto se cumplen sus dependencias, lo que su artículo cifra en una aceleración de 3,6 veces frente a la ejecución en serie.

Elegir la estructura es un compromiso: una lista es barata pero rígida; un árbol explora mejor pero cuesta más tokens; un grafo permite paralelizar a cambio de más complejidad. Frameworks como LangGraph, que alcanzó su versión estable 1.0 en octubre de 2025, traen estas estructuras ya montadas, como mostramos en flujos de agentes con LangGraph.

El patrón planificador-ejecutor

El patrón planificador-ejecutor (plan-and-execute) reparte el trabajo entre dos papeles. Un planificador convierte el objetivo del usuario en una lista de pasos. Un ejecutor, que suele ser un agente con herramientas, realiza cada paso por separado. La ventaja frente al bucle ReAct puro es que no se consulta al modelo grande después de cada acción: el plan ya está trazado, así que el agente avanza más rápido y más barato, y puede reservar el modelo potente solo para planificar. En pseudocódigo, el esqueleto cabe en pocas líneas:

def agente_plan_ejecuta(objetivo, planificador, ejecutor):
    plan = planificador.crear_plan(objetivo)    # lista de subtareas
    hechos = []
    while plan:
        paso = plan.pop(0)
        resultado = ejecutor.ejecutar(paso)      # un agente con herramientas
        hechos.append(resultado)
        plan = planificador.replanificar(objetivo, hechos, plan)
    return planificador.responder(objetivo, hechos)

Una variante que ahorra aún más llamadas es ReWOO (Reasoning WithOut Observations), donde el planificador usa variables para encadenar los resultados sin volver a llamar al modelo entre pasos:

Plan: buscar la poblacion de Francia.
E1 = buscar["poblacion de Francia"]
Plan: buscar la poblacion de Alemania.
E2 = buscar["poblacion de Alemania"]
Plan: sumar las dos cifras.
E3 = calcular[#E1 + #E2]

Cada #E1 referencia el resultado del paso anterior, de modo que el modelo traza todo el plan de una vez y un ejecutor lo resuelve después. Cuando conviene un patrón u otro lo tratamos a fondo en plan-and-execute frente a ReAct.

Replanificación ante errores

Ningún plan sobrevive intacto al contacto con la realidad. Una herramienta devuelve un error, un archivo no existe o un resultado invalida un supuesto del plan. Por eso el patrón incluye un tercer papel, el replanificador, que tras cada paso mira el historial completo (el plan original más los resultados ya obtenidos) y decide si continúa con lo previsto, reescribe los pasos restantes o da la tarea por terminada.

La replanificación es lo que convierte una lista estática en un plan vivo. En la práctica, el replanificador recibe los hechos acumulados y devuelve un plan actualizado, exactamente el bucle del pseudocódigo anterior. Este ciclo de planear, ejecutar y ajustar es también la base de los sistemas donde varios agentes se reparten un plan, que ampliamos en patrones de sistemas multiagente. Sin replanificación, el agente sigue un mapa obsoleto; con ella, corrige el rumbo igual que corregirías tú al toparte con un imprevisto.

Preguntas frecuentes

¿En qué se diferencia planificar de razonar con ReAct?

En ReAct el agente decide la acción siguiente en cada vuelta del bucle, sin una hoja de ruta previa. Planificar añade un paso anterior: el modelo traza toda la secuencia de subtareas antes de actuar. ReAct es más flexible ante la sorpresa; planificar es más eficiente en tareas largas y predecibles, porque evita consultar al modelo grande tras cada acción.

¿Cuándo conviene planificar y cuándo no?

Planificar compensa cuando la tarea tiene varios pasos con dependencias claras y un objetivo estable, porque el plan reduce llamadas y mantiene el rumbo. No compensa en tareas de un solo paso o muy exploratorias, donde el entorno cambia tanto que cualquier plan queda obsoleto enseguida; ahí un bucle reactivo con buena replanificación rinde mejor.

¿Qué es la replanificación?

Es el paso en el que el agente, tras ejecutar una o varias subtareas, revisa lo aprendido y ajusta el plan restante. Puede reordenar pasos, añadir nuevos, descartar los que ya no aplican o terminar si el objetivo se ha cumplido. Es lo que permite al agente recuperarse de errores y de resultados inesperados sin abandonar la tarea.

Conclusión

La planificación es lo que permite a un agente de IA abordar trabajos largos sin perderse: descompone el objetivo en subtareas, las organiza en una lista, un árbol o un grafo, y las ejecuta con un patrón planificador-ejecutor que sabe replanificar cuando algo falla. Es un compromiso entre eficiencia y flexibilidad, no una bala de plata. El siguiente paso natural es comparar este enfoque con el bucle reactivo en plan-and-execute frente a ReAct y ver cómo se combinan ambos.

Fuentes: [1] Plan-and-Solve Prompting (Wang et al., 2023)[1], [2] Tree of Thoughts (Yao et al., 2023)[2], [3] Plan-and-Execute Agents (blog de LangChain)[3], [4] Building effective agents (Anthropic, 2024)[4].

Visitas: 0

Fuentes

  1. arXiv 2305.04091
  2. arXiv 2305.10601
  3. Plan-and-Execute Agents (blog de LangChain)
  4. Building effective agents (Anthropic, 2024)

Ruta: Fundamentos de los agentes de IA