Planning Work Without Losing the Loop

OpenManus's planning flow addresses a coordination problem that the ordinary agent loop leaves open: how should several tool-mediated tasks be ordered, assigned, and visibly tracked? This chapter follows PlanningFlow from plan creation through executor routing and completion, so you can see what structure it adds to OpenManus—and where a plan records progress without proving that the requested result is correct.

A plan coordinates the loop; it does not replace it

PlanningFlow is an outer flow around agents, not a second kind of intelligence that bypasses them. Its plan is a stateful record: an ID, a title, ordered steps, a status for each step, and optional notes. The planning tool can create, update, list, retrieve, activate, mark, and delete those records. The flow uses the record to decide which work should be handed to an agent next, while the agent still performs ordinary thinking, tool calls, observations, and termination inside its own lifecycle.

The first plan is normally proposed through an LLM request that exposes the planning tool. The planning prompt asks for concise, actionable milestones rather than an exhaustive procedure. If the response contains a usable planning call, the flow injects its active plan identifier and creates the plan. If no usable call appears, it creates a fallback with three broad stages: analyze the request, execute the task, and verify the results. This fallback is valuable because the flow still has a structure when the model does not produce the expected planning action. It is not evidence that the fallback's verification step will independently verify anything; it is only a named milestone for the executor to perform.

Once a plan exists, the flow looks for the first step whose status is not completed. It marks that step as in progress and prepares a prompt containing the current plan status and the text of the selected step. The executor receives an instruction to perform only that current step with its available tools and to summarize what it accomplished. In this arrangement, the plan supplies sequence and visibility while the agent supplies execution. The boundary keeps planning from becoming a list that is never connected to actual work.

The lifecycle can be expressed as a set of transitions:

stateDiagram-v2 [*] --> NO_PLAN NO_PLAN --> PLAN_CREATED: planning call succeeds NO_PLAN --> FALLBACK_PLAN: no usable planning call PLAN_CREATED --> STEP_SELECTED: find first active step FALLBACK_PLAN --> STEP_SELECTED: find first active step STEP_SELECTED --> IN_PROGRESS: mark step active IN_PROGRESS --> EXECUTOR_RUN: pass status and step to agent EXECUTOR_RUN --> COMPLETED: executor returns normally EXECUTOR_RUN --> ERROR_REPORTED: executor error is returned ERROR_REPORTED --> STEP_SELECTED: active step remains for next loop COMPLETED --> STEP_SELECTED: more active steps COMPLETED --> FINAL_SUMMARY: no active steps FINAL_SUMMARY --> DONE: summary returned or fallback used

The states are useful because they separate a plan's transitions from the agent's internal transitions.