Two-stage prompting
Split complex tasks into a planning phase and an execution phase. The first call produces a structured plan; the second call executes it step by step. Dramatically more reliable than single-shot for multi-step reasoning.
Why two stages?
Single-shot prompting asks the model to plan and execute in one pass. For simple queries this works fine. For tasks that require reasoning across multiple steps — code generation with dependencies, data analysis pipelines, multi-turn tool use — the model often loses coherence halfway through. Two-stage prompting separates concerns: first, produce a verifiable plan; second, follow it.
Stage one — Planning
The first call receives the full task description and returns a structured plan. The plan enumerates discrete steps, identifies dependencies between them, and specifies the expected output of each step. You review the plan before proceeding — if the model misunderstood the task, you catch it here before any work is done.
User: Build a REST API for a todo app with CRUD endpoints, input validation, and error handling.
Stage two — Execution
The second call receives the original task plus the approved plan. It executes each step sequentially, carrying forward outputs from completed steps as context for dependent ones. Because the model now has a roadmap, it rarely drifts or forgets constraints mid-generation.
User: Task: Build a REST API for a todo app. Plan: [step 1: define routes, step 2: add validation, step 3: add error handling]. Execute step 1 now.
When to use it
- Tasks with 3+ distinct sub-tasks or dependencies
- Code generation where correctness matters more than latency
- Multi-turn tool calling with state carried across calls
- Any task where a bad plan is cheaper to fix than bad output
Tradeoffs
Upsides
- Higher accuracy on complex tasks
- Plan is auditable before execution
- Easier to debug failures per-step
Downsides
- 2× latency (two round trips)
- 2× token cost for the planning pass
- Overkill for simple single-turn tasks