Plan-and-Solve Prompting

The fundamental characteristic of Plan-and-Solve is the strict decoupling of planning from execution. The model is first instructed to generate a high-level, abstract plan—a sequence of sub-goals or steps—without performing detailed calculations or retrievals. This plan acts as a blueprint. In a subsequent, distinct phase, the model or a separate system executes each step of the plan, filling in the specific details, computations, and reasoning required. This separation reduces cognitive load in a single pass and allows for error checking and optimization of the plan itself before resource-intensive execution begins.

The initial planning phase focuses on strategy over computation. The generated plan consists of declarative steps (e.g., '1. Calculate the total cost. 2. Determine the applicable tax rate. 3. Apply the discount. 4. Sum the final amount.') rather than executed code or filled-in numbers. This abstraction allows the plan to be evaluated for logical soundness, completeness, and adherence to constraints before any concrete work is done. It mirrors software engineering best practices, where system architecture is designed before code is written.

By isolating the planning stage, this method mitigates cascading reasoning errors. In a single-pass Chain-of-Thought, an early mistake can invalidate all subsequent steps. With Plan-and-Solve, the abstract plan can be reviewed for logical flaws. Furthermore, during the execution phase, each step is solved in relative isolation, often with the ability to use external tools (calculators, APIs) for precision. If an error occurs in step 3, it does not necessarily corrupt the logic defined for steps 4 and 5, making debugging and correction more tractable.

The solve/execution phase is the natural integration layer for external tools. Once a plan like 'Fetch the current price of commodity X from API Y' is established, the execution phase can hand off that specific task to a dedicated tool-calling module or agent. This makes Plan-and-Solve a cornerstone of agentic architectures like ReWOO (Reasoning Without Observation), where a planner LLM creates a full plan of tool calls that are then executed by specialized workers without further LLM inference, dramatically improving efficiency and reliability.

Plan-and-Solve differs from basic Chain-of-Thought (CoT) in its enforced structure. Standard CoT interleaves planning and detailed reasoning in a single, continuous narrative (e.g., 'First, I need the total. The items cost $5 and $7, so that's $12. Now the tax...'). Plan-and-Solve mandates two distinct outputs: first the plan, then the solved steps. Least-to-Most Prompting is a closer relative, as it also involves decomposition, but it typically does not demand a fully articulated plan upfront before beginning execution on the first sub-problem.

Effective prompts for this technique follow a clear, two-stage template:

• Stage 1 (Plan): First, devise a step-by-step plan to solve the problem. List the steps as bullet points. Do not perform calculations yet.
• Stage 2 (Solve): Now, execute your plan step by step. For each step from your plan, show your work and provide the result. This structure can be implemented in a single multi-turn prompt or across two separate LLM calls, with the plan from the first call fed as context into the second. The key is the instructional boundary that prevents the model from jumping ahead to execution.

The foundational technique for eliciting explicit, step-by-step reasoning. It involves providing the model with examples (few-shot) or instructions (zero-shot) that demonstrate a logical progression from a problem to its solution.

• Core Mechanism: The model is conditioned to output intermediate reasoning steps before a final answer.
• Key Benefit: Dramatically improves performance on arithmetic, commonsense, and symbolic reasoning tasks by decomposing complex problems.
• Example: Instead of asking "What is 15% of 80?", a CoT prompt would include an example like: "20% of 50 is 10, because 0.2 * 50 = 10. Therefore, 15% of 80 is..."

A decomposition technique that explicitly breaks a complex problem into a sequence of simpler sub-problems. The model solves each sub-problem in order, using the solution from prior steps to address subsequent ones.

• Relation to Plan-and-Solve: It is a specific, structured instantiation of the planning phase. Where Plan-and-Solve may generate a high-level plan, Least-to-Most generates an explicit list of sub-questions.
• Process: 1. Decomposition: "What sub-questions do we need to answer?" 2. Sequential Solution: The model answers Q1, then Q2 using A1, etc.
• Use Case: Excellent for compositional generalization tasks where problems can be naturally broken down (e.g., multi-hop question answering).

A framework that interleaves verbalized reasoning traces with actionable tool or API calls. This creates a dynamic loop where the model reasons about what to do next, acts using a tool, observes the result, and then reasons again.

• Key Difference from Plan-and-Solve: ReAct is interactive and adaptive; the plan emerges step-by-step based on environmental feedback. Plan-and-Solve typically creates a full plan before any execution.
• Components: Thought: Internal reasoning. Act: Tool call (e.g., Search(...), Calculator(...)). Observe: Result from the tool.
• Application: Ideal for tasks requiring real-time information lookup, precise calculation, or interaction with external systems.

An advanced reasoning framework that extends Chain-of-Thought by exploring multiple reasoning paths in parallel. It treats intermediate steps as nodes in a tree, which can be evaluated and expanded using search algorithms like breadth-first or depth-first search.

• Contrast with Linear Reasoning: While Plan-and-Solve and standard CoT follow a single, linear path, ToT enables exploration and backtracking.
• Mechanism: 1. Thought Generation: Create multiple possible next steps. 2. State Evaluation: Heuristically score the quality of each intermediate state. 3. Search Algorithm: Decide which path(s) to explore further.
• Use Case: Complex problem-solving where the solution path is not obvious, such as strategic game playing or creative writing with constraints.

A decoding and aggregation strategy used to improve the reliability of Chain-of-Thought reasoning. Instead of generating a single reasoning chain, the model samples multiple, diverse chains and selects the most consistent final answer via majority vote.

• Purpose: Mitigates the brittleness of single-path reasoning, where a small error in an early step can derail the entire process.
• Process: 1. Sample n different reasoning paths from the model (using temperature > 0). 2. Extract the final answer from each path. 3. Output the answer that appears most frequently.
• Result: Often yields significant accuracy gains on reasoning benchmarks, as it averages out individual chain errors.

A self-critique and fact-checking method. The model first generates a baseline answer, then plans and executes a series of verification questions to audit its own response, leading to a revised, more accurate final output.

• Relation to Plan-and-Solve: It applies a planning phase specifically to the meta-task of verification. The "plan" is a set of verification steps.
• Four-Step Process: 1. Draft an initial response. 2. Plan verification questions that could expose flaws. 3. Execute the verification plan, possibly using tools. 4. Generate a final, verified answer incorporating the audit results.
• Benefit: Reduces hallucinations and factual errors by introducing an explicit, structured self-review loop.