Plan-and-Execute: plan, act, adjust
Plan-and-Execute separates planning, step execution and plan revision after results.
What you will learn
- Explain: a workflow has explicit structure
- Apply the idea in an example: Plan-and-Execute: plan, act, adjust
- Recognize limitations and verify the exercise outcome
Plan-and-Execute separates planning, step execution and plan revision after results. New information can change the plan.
These steps refer to features identified in the application code. This material has not been validated on a live instance; check the documentation and the options in your version.
How it works, step by step
A workflow has explicit structure
A node is a stage, an edge is a transition, and state carries results between stages. A workflow has an application-defined path, although the model may choose some branches. Agentic systems include both workflows and dynamically acting agents. Nymrio offers ReAct, Reflection, Sequential, Orchestrator, Router, Parallel and Plan-and-Execute. Each changes coordination; it does not automatically make a model an expert. More agents mean more calls and contracts between roles. Start with the simplest solution that passes your tests.
Context is the workbench
Context includes instructions, the current request, relevant history, retrieved documents and tool results. The context window has limited capacity; reserve room for the response too. More text does not automatically improve accuracy. Irrelevant information and contradictions can hide important evidence. Summarize history carefully and preserve the origin of facts. State describes the current run, a checkpoint saves a resumable point, and persistent memory retains information across runs. These are different mechanisms managed by the application.
Errors need explicit paths
A timeout differs from a permission error. Retry only transient errors, with bounded attempts and increasing delays. An operation with side effects may execute before its response is lost; retrying without an idempotency key can duplicate the effect. Streaming shows progress but does not guarantee completion. Checkpoints may allow failed stages to resume within runtime limits. Store the run identifier, stage, duration and error while removing secrets from logs. Measure slow paths as well as averages.
Detailed lab
Observations change the plan
The planner produces concrete steps rather than a vague list: identify SKU; find part; find adapter; synthesize. The executor handles the current step using allowed tools. The replanner removes completed work, updates what remains and decides whether the goal is satisfied.
For LX-240, the catalog provides P-12 and then A-7. With SKU “LX”, the executor cannot safely choose the product; the plan needs identifier clarification. Compare the original plan with actual stages in Playground. Producing a plan is not task success.
The visual map
Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. On smaller screens, scroll horizontally to follow the entire diagram.
A complete example
Planner: identify product, check compatibility, check delivery. The executor discovers the product model is missing. The replanner requests clarification rather than proceeding with an assumed model.
planner: LunaPlanner
executor: LunaExecutor
replanner: LunaReplanner
max_iterations: 3
Try it yourself
- Configure exactly planner, executor and replanner and trace a missing-information case.
- Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
- Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
- Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
- Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.
An explained solution
The remaining plan reflects completed steps; execution ends on completion or reaching a limit. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.
When it helps and what can go wrong
Parallel’s planner distributes tasks; it is not the complete Plan-and-Execute pattern. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.
Check your understanding
Is multi-agent an eighth template?
No. It is an architectural category that can use several existing templates.
Is a checkpoint permanent user memory?
No. Saving a run does not imply retaining preferences across conversations.
What outcome should this exercise produce?
The remaining plan reflects completed steps; execution ends on completion or reaching a limit.
Words to remember
- Nod: A stage in an execution graph.
- Checkpoint: Saved state used to resume an execution.
- Idempotency: Controlled repetition without duplicating an effect.
Sources and your next step
To prepare: W07 — Parallel: several perspectives at once