Plan-and-Execute Versus Stepwise Control

Plan-and-execute separates a planning phase from execution. Stepwise control does something else. It chooses one action from the current state, then looks again.

That design has a canonical implementation. ReAct, published in 2023, interleaves reasoning traces with actions. Each action is chosen from the state the environment has just reported back. The traces are not decoration. In the authors' phrase, they exist to “induce, track, and update action plans as well as handle exceptions”.

The measured result was large. “On two interactive decision making benchmarks (ALFWorld and WebShop), ReAct outperforms imitation and reinforcement learning methods by an absolute success rate of 34% and 10% respectively, while being prompted with only one or two in-context examples.” Thirty-four absolute points, from one or two examples. That is what it is worth to re-read the world before every move.

Hybrid systems keep a coarse plan while revising near-term actions as observations arrive.

The appropriate horizon depends on environment stability, coordination needs, action cost, and feedback speed. A plan is a revisable artifact. It is not an instruction with unlimited authority.

Beginning on 27 July 2012, Knight Capital Americas deployed new Retail Liquidity Program code into SMARS in stages. As the SEC later put it, “During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers.” The plan had been valid at the start. It was valid on seven targets at the end.

The eighth server still held retired “Power Peg” code. Its cumulative-share-counting function had been moved in 2005 and never retested. So when the programme went live on 1 August 2012, the repurposed flag activated it. For 212 incoming parent orders the system sent millions of child orders. That came to 4 million executions in 154 stocks, more than 397 million shares in approximately 45 minutes. It left an approximately $3.5 billion net long position in 80 stocks and an approximately $3.15 billion net short position in 74 stocks. The loss was $460 million.

The SEC's order of 16 October 2013 found that Knight had no written procedures requiring a second technician to review the deployment. It imposed a $12 million penalty.

No step of the sequence errored. The precondition that made the sequence meaningful — that all eight servers were carrying the new code — was never written down anywhere it could be rechecked.

How far ahead the system commits is what separates a full upfront plan from stepwise control, and a hierarchical hybrid takes some of each. That claim has been measured directly rather than argued.

LLM-Planner ran the same planner twice on ALFRED in 2023. Once emitting one fixed high-level plan up front. Once re-planning whenever the agent fails to execute an action or a fixed number of timesteps has passed. On the test-unseen split with goal instruction only, static planning scored 11.58 success rate and 18.47 goal-condition. Grounded re-planning scored 13.41 and 22.89. The authors write: “Lastly, we see a considerable improvement from grounded re-planning over static planning, especially in the goal instruction only setting, where it improves 1.83% SR in the unseen test split.”

The paper's failure analysis makes the same contrast at higher absolute numbers. That run used the valid-unseen split in the step-by-step-instruction setting, with an oracle low-level controller substituted in. The gap widens to 42.68 versus 47.32 success rate, and 66.54 versus 78.56 goal-condition. Give the plan a way to notice that the world moved and it converts a chunk of failures into completions. That holds even when the low-level execution is perfect.

Compare the three designs on one question. Once execution has started, can the runtime still state which plan assumptions remain valid? A design that cannot answer that will keep executing a plan long after the ground it was built on has moved.

A coarse objective map holds the destination while the near-term step does the work. A validity check decides whether the map still describes the ground. The replan trigger and the commit boundary need separate owners and separate tests.

SayCan, from 2022, is that architecture built and scored. A learned affordance value function rates what is currently possible before each plan step is committed. So the language model's proposal and the question "can this actually be done here, now" stay separate components. Separate components get separate numbers. Across 101 real-world instructions: “In the mock kitchen, SayCan achieved a planning success rate of 84% and an execution rate of 74%.” Ten points of the plans that were right were not carried out.

Moved to a real office kitchen, the two scores came apart further. Planning fell 3 points to 81%. Execution fell 14 points to 60%.

That divergence is the argument for the separation. A single blended score would have shown one number sliding and hidden which half of the system the new environment had broken.

Pick the horizon for one workflow deliberately, and write down the assumption that would invalidate it. Writing it down is what makes the danger visible. You now know in advance which fact has to stay true for the plan to be worth following. "All eight servers carry the new code" is one sentence. Unwritten, it cost $460 million. It also leaves behind what a reviewer needs: a named assumption that can be rechecked against the world while the plan is still running.

The last step of this sequence compares a full plan against a purely stepwise baseline before selecting a hybrid. That is not a rhetorical suggestion. It is what LLM-Planner did: one planner, both modes, the same split, 11.58 against 13.41. Run your own version of that A/B before you decide. The size of the gap in your environment is the only thing that tells you how much replanning machinery is worth building.

Plans should be inspected like code: versioned, tied to assumptions, and invalidated when their preconditions no longer hold. The rule to carry out of this lesson is that plans become dangerous when they outlive their assumptions. A plan that is reused gets its preconditions rechecked before it runs again.

The PlanBench numbers say precisely where that recheck has to be external rather than delegated to the model. Plan reuse is the easy case, where the new instance needs only a prefix of the example plan. In the same Blocksworld evaluation, GPT-4 was correct there in 392 of 600 instances, 65.3%. On replanning after an announced unexpected state change, 289 of 600, 48.1%, against InstructGPT-3's 40 of 600, 6.6%. On plan verification, 352 of 600, 58.6%. On reasoning about the state resulting from executing an action sequence, only 191 of 600, 31.8%.

Read that last figure against the others. The weakest skill of all is working out where the world ends up after the actions run. That is the exact skill a reused plan silently depends on. The authors' own summary is blunt: “Overall, the performance of these LLMs on our benchmark shows that, as of right now, LLMs are pretty ineffective in reasoning about actions and change.”

When the horizon itself is in question, pick the one whose assumptions you can still verify mid-run. And put the verification somewhere other than inside the thing being verified.