Agent Planning Strategies

The Spectrum of Planning Strategies

Agent planning isn't a single technique but a spectrum of design choices. These choices revolve around three key questions that directly impact an agent's performance, cost, and reliability:

1. When does the agent plan? Is it step-by-step, or is there an upfront master plan?
2. How many LLM calls are needed? Does every action require a new reasoning step, or can planning be separated from execution?
3. How does the agent handle failure? Does it adapt on the fly, replan from scratch, or learn from its mistakes?

The previous lesson's focus, ReAct, represents one end of this spectrum: it plans one step at a time, making an LLM call at each turn. This makes it highly adaptive but also potentially expensive and "myopic," unable to see the overall optimal path.

An excellent article from "The AI Engineer" newsletter breaks down these patterns and their trade-offs. We will use it as our guide for this lesson.

Plan-and-Execute: The Architect's Approach

To counter the myopic, high-cost nature of ReAct, the Plan-and-Execute pattern separates planning from execution. This strategy aligns well with your interest in cost engineering and building predictable systems.

The process involves two or three distinct phases:

1. Planner: A powerful, sophisticated LLM (like GPT-4o) analyzes the user's entire request and generates a complete, multi-step plan. This plan is often a list or a directed acyclic graph (DAG) of subtasks.
2. Executor: A simpler, cheaper, and faster model (or even just deterministic code) executes each step of the plan sequentially. The executor's job is to follow instructions, not to reason about the next step.
3. Replanner (Optional): If a step fails or produces an unexpected result, a replanning module can be triggered. This module assesses the situation and revises the rest of the plan.

This separation offers significant advantages for production systems:

• Cost Efficiency: You make one expensive LLM call for the plan and then use cheaper models or direct tool calls for execution. This is much more economical than using a large model for every single step as ReAct does.
• Predictability and Validation: The entire plan is generated upfront. You can log it, show it to a user for approval, or run validation checks on it before any actions are taken.
• Reduced Latency: The executor can run through its steps without the overhead of an LLM reasoning cycle between each action.

However, its primary weakness is rigidity. A flawless plan can be derailed by one unexpected real-world outcome.

The following video from the LangChain team provides an excellent conceptual overview and demonstrates how to build a Plan-and-Execute agent in LangGraph.

Now, let's read the detailed breakdown of this pattern to solidify your understanding of its pros, cons, and ideal use cases.

As a brief aside, an even more aggressive and token-efficient version of this is ReWOO (Reasoning Without Observation), which you can read about in the same article. ReWOO plans all steps upfront with placeholders for future results, allowing independent tool calls to run in parallel. It's extremely fast and cheap but even more brittle than Plan-and-Execute, as it has no mechanism for mid-execution adaptation.

Reflexion: The Self-Correcting Agent

What if the goal isn't just to complete a task, but to get it right, even if it takes a few tries? This is where the Reflexion pattern comes in. Rather than a primary planning strategy, Reflexion is a meta-pattern that adds a self-correction loop on top of another agent, like ReAct or even Plan-and-Execute.

The Reflexion loop looks like this:

1. Attempt: An "actor" agent attempts the task and produces an output (e.g., a piece of code, a written summary).
2. Evaluate: An "evaluator" module checks the output against objective criteria. For code, this could be a unit test suite. For data extraction, it could be a schema validator.
3. Reflect: If the evaluation fails, a "reflector" LLM is given the failed output and the reason for failure. It generates a natural-language critique, explaining what went wrong and how to fix it.
4. Retry: This critique is added to the actor agent's memory. The agent then retries the entire task, now aware of its previous mistake.

This is powerful for tasks with clear pass/fail conditions, as it allows the agent to learn within a single session. On the HumanEval coding benchmark, this technique famously boosted GPT-4's success rate from 80% to 91%.

The primary trade-offs are, once again, cost and latency. Each retry is a full execution of the underlying agent, plus the overhead of evaluation and reflection. This makes it unsuitable for real-time applications where a user is waiting for an immediate response.

The following video demonstrates this "Evaluator-Optimizer" workflow, which is a perfect implementation of the Reflexion pattern.

To complete your understanding, let's see how the reference article describes this pattern.

A Framework for Choosing Your Pattern

You now have a mental toolkit of three distinct planning paradigms: iterative adaptation (ReAct), upfront planning (Plan-and-Execute), and iterative self-correction (Reflexion). The key to effective agent design is not to pick one "best" pattern, but to choose the right one for the job based on the task's requirements and constraints.

The flowchart below provides a simple but effective decision-making framework.

Let's walk through the logic:

• "Does each step depend on the previous result?"
  • Yes: Your task is exploratory and requires adaptation. A rigid upfront plan would fail. This leads you to choose between ReAct and Reflexion.
    • "Need self-correction?" If the task has clear success criteria and correctness is paramount, the high cost of Reflexion is justified. Otherwise, the step-by-step adaptability of ReAct is sufficient.
  • No: Your task is predictable. You can gain efficiency with an upfront plan. This leads you to choose between ReWOO and Plan-and-Execute.
    • "Is token cost the top priority?" If you need maximum efficiency and can tolerate rigidity, ReWOO's two-call, parallel-execution model is ideal. If you need a bit more safety and robustness, Plan-and-Execute with its replanning capability is the better choice.

In production, you'll often build hybrid systems. A common and powerful combination is ReAct + Reflexion: use the adaptive ReAct loop for the main task, and if the final result fails validation, trigger a Reflexion cycle to try again with a self-critique.

Conclusion

In this lesson, we moved beyond the single-step ReAct pattern to compare a range of agent planning strategies. You've analyzed the fundamental trade-offs between flexibility, cost, and reliability that drive agent architecture.

Here are your key takeaways:

• Single-Step (ReAct): Highly adaptive and easy to debug, but can be costly and myopic. Best for exploratory tasks where the path isn't known in advance.
• Plan-and-Execute: Cost-effective and predictable, using different models for planning and execution. Best for well-defined workflows but can be rigid when faced with unexpected outcomes.
• Reflexion: Enables an agent to learn from its mistakes through a cycle of evaluation and self-critique. Powerful for improving accuracy on tasks with clear success criteria, but very expensive in terms of cost and latency.
• Choosing a Pattern: The right choice depends on the task's predictability, the need for correctness, and your tolerance for cost and latency.

You are now equipped to think architecturally about agent design. This moves you from simply using an agent to consciously designing one that fits the technical and business constraints of a problem.

In our next lesson, we will zoom in on a mechanism that powers all of these patterns: tool use. We'll explore exactly how an LLM selects a function from a list, formats the call, and interprets the result it gets back.