Overview
How might we show what an agent will do before it acts, so people can catch a wrong approach early and follow progress through a multi-step goal?
When a goal needs ordered steps with review before run
- Multi-step agent tasks where users benefit from seeing intent before side effects start.
- Long-running workflows (research, prep, ops) where progress must stay legible step by step.
- Products where catching a wrong plan early saves time, cost, or trust.
- Agents paired with tools or writes where "what will happen" should be inspectable first.
When a plan adds friction without real visibility
- Single-step requests where a plan adds a review step with nothing to actually review.
- Latency-sensitive interactions where users want an immediate answer, not a proposal to approve first.
- Highly exploratory tasks where the right steps only emerge as the agent learns from early results.
States
Design the plan lifecycle, not only a todo list that appears after work has already started.
Goal received
The user states a complex goal. The agent acknowledges scope before proposing steps.
Planning
The agent decomposes the goal into an ordered list. Nothing consequential runs yet.
Proposed
The full plan is visible: numbered steps, scope title, and a clear path to start or edit.
Editing
The person adjusts, reorders, or removes steps. Execution will follow the edited plan.
Running
Steps execute one at a time. Current step and completed count stay visible in the same view.
Complete
All planned steps finish. Outcome is summarized; the executed plan remains inspectable.
Key UX elements
The parts that must be present for plan-then-execute to feel trustworthy.
Anchor the plan to the user ask.
Show the original goal near the plan so people can verify the breakdown matches what they wanted.
List ordered steps with clear labels.
Numbered, scannable steps beat a paragraph of intent. Each line should name one concrete action.
Pause before execution starts.
The plan stays editable or approvable until the user explicitly starts the run.
Make run explicit and primary.
One clear CTA ("Run plan", "Start") commits to the visible sequence. Do not auto-run without consent.
Check steps off in place.
The same list updates as work proceeds: active step, done count, no silent deviation from the plan.
Close with what finished.
Summarize results when the plan completes. Keep the step history available for audit.
Anti-patterns to avoid
Showing a plan once and then silently deviating from it during execution with no updated view.
Plans so granular they bury the real decision points under dozens of trivial sub-steps.
No way to edit or reject individual steps, only accept-all or cancel-all.
Re-planning from scratch on every minor failure instead of adjusting the remaining steps.
How products use it
| Product | Implementation |
|---|---|
| AutoGPT | Generates a task list from a goal and executes items sequentially with visible state. |
| CrewAI | Assigns planned sub-tasks across role-based agents with a defined execution order. |
| LangChain (plan-and-execute agents) | Separates a planner step from an executor loop that carries out each planned action. |
| Cursor Agent | Drafts a todo-style plan for multi-file tasks before making edits. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Plan & Execute" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is the Plan & Execute pattern in AI agents?
Plan & Execute means the agent first produces a visible, ordered breakdown of a goal into steps, then works through those steps one at a time, updating status as it goes. It separates "what will happen" from "doing it" so users can review intent before commitment.
Why show the plan instead of just running the task?
Showing the plan lets users catch a wrong approach before any side effects occur, and it gives a legible progress model during long-running tasks. It also makes failures easier to diagnose since users can see which step broke.
Should users be able to edit the plan before execution?
Yes, for anything consequential. Letting users reorder, remove, or edit individual steps before execution turns the plan into a real checkpoint rather than a formality, and reduces wasted runs on the wrong approach.