Task DAG and Task State Machine: The Skeleton of Plan-and-Execute

From the Dongfang Yiteng execution agent (case by Bo Liang)

Definition

Plan-and-execute is an action pattern that first lays out and fixes the several steps a business process has to take, then schedules execution by dependency, instead of deciding one step at a time. The two core data structures that carry this plan are the task DAG and the task state machine. The task DAG is a directed acyclic graph that organizes task nodes by dependency, fixing the ordering constraints between steps; the task state machine maintains each node's own state and drives the whole graph forward.

How it works

What this structure solves is taking execution order out of the model's on-the-spot judgment and fixing it on the task graph. Letting the LLM work out the correct step order on its own inside a ReAct loop amounts to handing deterministic control flow to a probabilistic model. Plan-and-execute pulls this order out of the narrative context and lays it down as edges in the graph and node states, scheduled by the program through the state machine, so the model no longer re-decides the ordering at every step.

What it guards against is ReAct skipping or missing steps on a process with strict dependencies. Dongfang Yiteng hit this failure while validating fast setup of payroll groups in the mock stage: this scenario has to snapshot the enterprise's existing payroll-group data first, confirm the snapshot is built before importing the matched template, and roll back from the snapshot if the import fails — a sequence that cannot be reordered and that has strict progressive dependencies. The first idea was natural: describe each API as a tool, describe in the skill how each scenario should be orchestrated, feed "call this step first, then that step" to the agent as narrative context, and expect it to work out the correct order on its own inside ReAct. In testing it did not work: once the skill orchestration was given to the model as narrative context, it sometimes ran correctly and sometimes clearly skipped or missed a step, leaving the task not matching expectations. The root cause is again the uncertainty of the LLM — handing execution order to a probabilistic model for on-the-spot judgment cannot guarantee it is right every time.

So the team identified one more missing action pattern: plan-and-execute. ReAct's core control structure is essentially a chained loop with an exit boundary; once you understand the concept the data structure is easy to write. Plan-and-execute has to lay out and manage the scheduling and dependencies of several consecutive tasks, which means maintaining more complex task-planning and scheduling state, and its implementation complexity is an order of magnitude higher than ReAct's. Its core components are the task DAG, the planner, the executor, the verifier, and the task state machine together with the mechanism that dynamically maintains task-graph state. The most demanding part is the task state machine model: each node has its own state, and the precondition for a downstream node to be scheduled and started is that all of its upstream dependencies are complete and the node itself is ready; the whole scheduling semantics is driven by this state machine.

The two action patterns need not be an either-or choice. Control flows between the Orchestrator and the specific action pattern: when ReAct runs to a step where the path becomes clear and can be planned into several parallel or sequential tasks, it hands control back to the Orchestrator and switches into plan-and-execute, alternating between the two by how clear the task is. Once the state machine is in place, human-review blocking and resumption of key tasks also gain a ready-made structure to ride on; the node state itself can express "paused, awaiting approval," with no need to design a separate mechanism for it.

When you need it

When your agent has to deliver a business process whose steps have strict ordering dependencies, where the wrong order means delivery fails, and ReAct's step-by-step free decision can no longer hold down skipped or missed steps. How this plan maintains task-scheduling state and keeps it separate from narrative and mechanical parameters is what the separation of powers in the unified session state plane answers; key tasks blocking for human review and resuming the execution flow after approval rely on this state machine, see HITL block and resume.

This is an ADPS blue-book concept. Back to Concepts or the pattern matrix.