Plan-and-Solve / Least-to-Most Prompting: Decoupling Planning from Execution

1. Why Reactive Agents Stumble on Complex Tasks

Standard ReAct agents decide their next action greedily at each step. On complex, multi-stage workflows (e.g., "Migrate this database schema, refactor the ORM models, update test suites, and generate a changelog"), greedy step-by-step agents suffer from:

• Myopic Planning: Getting stuck in rabbit holes.
• Lost Sight of the North Star: Forgetting the high-level objective after 10 sub-tool calls.
• Cascading Cost: Exploring dead-end tool paths.

2. Plan-and-Solve Architecture

Pioneered by Wang et al., Plan-and-Solve decouples strategy from execution:

   User Request: "Conduct security audit and refactor authentication service"
                         │
                         ▼
             [ Planner LLM (High Reasoning) ]
             Generates static, DAG-based plan:
             1. Fetch current auth middleware
             2. Inspect JWT signature algorithm
             3. Replace HS256 with RS256 / EdDSA
             4. Verify unit tests pass
                         │
                         ▼
             [ Plan Executor Engine ]
             Executes steps sequentially; updates status:
             [✓ Step 1] ──► [✓ Step 2] ──► [In Progress Step 3] ──► [Pending Step 4]
                         │
                         ▼ (If execution fails)
             [ Re-Planning Loop: Modify remaining steps without restarting ]

3. Production Benefits

1. Explainability: The user inspects the proposed execution plan before any state-changing actions execute.
2. Deterministic Checkpointing: If Step 3 fails, the system retries Step 3 rather than restarting from Step 1.
3. Model Tiering: Use an expensive reasoning model (e.g., Claude 3.5 Sonnet / o1) for the Planner, and a fast, cheap model (e.g., Haiku / Flash) for the Executor.