plan_and_execute is the third way a plan runs: the LLM planner authors a plan on the fly for a novel multi-step task, and the same pipeline executes it — same template language, same control steps, same finish modes. It exists so that improvised work still gets plan-shaped execution: typed dataflow between steps instead of the agent eyeballing intermediate results, and a visible artifact you can inspect afterwards.
plan__* tools), so it’s callable from chat, from a plan step, or directly. In chat, the router reaches for it when a task is multi-step and no authored plan matches.
What the planner sees
Theplanner-role model drafts against:
- The full tool catalog — every tool’s description and input schema. Descriptions and exemplars are routing signals here too: they steer which tools the planner picks.
- Output shapes — a declared output schema when one exists (MCP-provided, a
tool_overridesentry, or a user tool’soutput_schema), otherwise the shape cache’s observed shape, marked as empirical. The cache is read fresh at every planning attempt, so a shape observed earlier in the same run is already available to the next plan. - Your context — the
[user]config section, same as the chat agent.
{{E0}}) or to stop and continue planning after real results exist — cold caches degrade, they don’t break.
What the planner is instructed to do
The planner has the full step vocabulary — exit gates, decide, map/reduce, andplan__* composition — plus standing instructions that shape its drafts:
- Exit gracefully rather than fabricate. When data comes up empty, draft an
exitwith an honest message instead of inventing results. - Gate check-shaped plans. Validations and assertions end in explicit gated exits, not solver prose.
- Infer per item, not per list. Inference over a list becomes a
mapbody callingbuiltin__inferwith{{item}}, and when named models are configured, their descriptions steer each call to the smallest adequate model.
Replanning
Planner-authored plans are drafts, so defects trigger a replan instead of a hard failure: the error — including, for bad data references, a digest of the keys that actually exist — feeds back to the planner, which revises the plan. Executed steps are preserved and never re-run; only the broken tail is replaced. After the configured attempts ([settings].planning_attempts, default 2), it degrades to an honest error summary.
EmptyData never triggers a replan — a search that found nothing is an answer, not a defect, and replanning can’t conjure data. The full policy, including why your plans never replan, is in Errors & replanning.
Cost
A chat turn throughplan_and_execute is 4+ inference calls: the agent (deciding to plan), the planner, the solver, and the agent again (reading the report) — plus one planner call per replan. The plan’s steps themselves are still zero-inference. When the workflow is worth keeping, freeze it: an authored plan runs the same steps for 1 call (solver) or 0 (output/silent), and never replans. See the full cost table.
Drafting without executing
The same planner also powers draft-only planning: the workbench’sworkbench__draft_plan produces a plan for you to review instead of executing it.
A draft is built in stages: the planner first sketches an outline (2–8 one-sentence stages plus the solver’s brief), then generates the real steps one inference at a time — each step sees the outline and every previously accepted step, is statically validated before acceptance, and is retried up to 3 times with the validation problems injected as feedback. A draft that comes back is therefore statically valid; if a step exhausts its retries, the valid prefix is kept so you can finish it with the editing tools instead of redrafting.
The planner drafting in the workbench: two steps accepted, the third being drafted, the outline's last stage still pending.