What Is a Plan-and-Execute Agent?

🧩 The three parts, and where the replan sits

A working implementation has three components rather than the two the name mentions. There is a planner, which sees the task and produces a list. There is an executor, which takes one step at a time and holds no discretion over the order. And there is a replanner, which is handed the original plan, the steps already completed and their results, and returns either a revised remainder or the finished answer. Without the third component the pattern is a single guess made before any evidence exists, followed to the end regardless of what the evidence turns out to be.

What the executor receives per step matters as much as the plan does. A step is dispatched with its own instruction and whatever earlier results it declares a dependency on, rather than with the whole accumulated history, so the context each step runs in stays small and roughly constant across the run. In a step-at-a-time loop the opposite holds: the transcript grows with every action and observation, and the last decision of a long run is taken in the most crowded context that run will ever have.

An explicit list is also a data structure, and that yields several things an implicit trajectory does not. Steps that declare no dependency on one another can be dispatched together. A plan can be persisted, so a run interrupted at the fourth step resumes at the fifth instead of starting again. It can be compared against the plan an earlier run produced for the same task, which makes a change in behaviour visible as a difference between two documents. And it can be read by a person, or checked by a policy, before anything with an external effect has happened — the one review point this pattern has and a loop structurally cannot offer, since a loop has already acted by the time there is anything to review.

A variant pushes the separation further by writing the plan with placeholders: each step names a variable that a later step will substitute, so the entire plan is produced in one call before any tool has been touched, and the executor's work reduces to running calls and filling values in. It trades away the ability to shape a step around what an earlier step returned, in exchange for a plan that can be inspected in full while none of it has yet run.

The last row is where the trade actually sits. A loop reacts to whatever it has just seen and pays for that responsiveness on every step it takes; a plan pays once for a route and then owes a decision about when to redraw it. Neither is free, and choosing between them is mostly a question of how much of the task is knowable before any of it has been attempted.

🗃️ How the Registry classifies a planned multi-step execution task

Producing an ordered step list for a task and then running it is filed as data processing in this registry's classification. The classification is decided by the operation rather than by the tools the individual steps happen to call: a specification is decomposed into a structure, and that structure — not any message, artefact or transaction a later step may produce — is what the task itself delivers.

The Registry's canonical brief for this entry is filed as: Produce a written step list for a multi-step task before any step runs, then execute the list in order. Submitted for assessment it is classified as Data processing, and its wording is hashed once — to b9c483234513d4ce…, the first sixteen of sixty-four hexadecimal characters — with the wording itself never stored. The hash is what the derivation reads. That class's own page is /tasks/analysis.

Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.

❓ Questions about plan-and-execute

What is a plan-and-execute agent?

A plan-and-execute agent calls a planner once to produce the complete ordered step list for a task, then runs those steps through an executor that does not choose the order. Most implementations add a replanning step that revises the remainder of the list in the light of results already returned.

How does plan-and-execute differ from a reasoning-and-acting loop?

A loop interleaves deciding and doing: it chooses one action, observes the result, and only then chooses the next. Plan-and-execute writes the full list first and runs it, revisiting the list only at an explicit replanning step. The step list is the artefact one arrangement has and the other does not.

Why does the pattern use fewer expensive calls?

Because deciding is separated from doing. One planning call covers a route that a loop would decide across as many calls as there are steps, and each step is dispatched with its own instruction and declared inputs rather than the entire accumulated transcript. Whether that saving survives depends on how often the plan has to be redrawn.

What is replanning?

Replanning is the step that takes the original plan, the steps completed and their results, and returns either a revised remainder or the final answer. It is what stops a plan written in ignorance from being followed to the end in ignorance.

When is a plan a poor fit for a task?

When the shape of the task is discovered while doing it. If the number of steps depends on what an early step returns, a list written beforehand is a guess, and an executor that follows it without discretion will keep going after the guess has failed.