Planner-Executor Pattern

The planner-executor pattern, also called plan-then-execute, is an agentic design that separates reasoning from action. A planner component first formulates a complete multi-step plan for a complex goal; a distinct executor then carries out those steps one by one, invoking tools or sub-agents and reporting results. This explicit decoupling of planning from doing is the pattern's defining trait — and the source of both its benefits and its costs. It is the difference between a technician who writes the diagnostic procedure on the whiteboard before picking up a probe, and one who improvises at the bench.

Why separate the roles

Forcing the model to commit to a plan before acting makes its intentions inspectable. The plan is an artifact: you can log it, validate it against policy, estimate its cost, or require sign-off before any step runs. That property makes the pattern a natural fit for a human-in-the-loop approval gate — the human reviews five declared steps rather than supervising fifty improvised ones, which is a far better use of scarce attention. Separation also keeps long tasks coherent: the executor follows an agreed roadmap instead of re-deciding strategy at every turn, which curbs the drift and goal-forgetting that plague long agent sessions. And the roles can be staffed differently — a strong (expensive) model plans while a lighter, faster model executes each mechanical step, a meaningful economy when you are paying for every token or running on your own GPUs.

Contrast with reactive loops

A purely reactive agent — the ReAct style — interleaves thinking and acting at each step, adapting continuously to whatever the last observation revealed. That flexibility is genuinely valuable when the task is exploratory and the next step is unknowable in advance, but it wanders, and each detour consumes context and tokens. Plan-then-execute trades some adaptivity for structure and predictability. The failure mode is obvious: reality diverges from the plan — a tool errors, an assumption breaks — and a naive executor marches on regardless. Mature implementations therefore add a re-planning step: when execution results contradict the plan's assumptions, control returns to the planner, which revises the remaining steps. The costs are equally real — planning is an extra model call, re-planning adds cycles, and for simple tasks the ceremony is pure overhead. Use the pattern where auditability and coherence pay for themselves.

A grounded example: an agent tasked with "update firmware across the fleet" first emits a plan — inventory machines and current versions, verify the image checksum, flash one canary unit, confirm it returns to full hashrate, then roll out in batches with a halt condition. You approve the plan, and the executor works the list, returning to the planner only if the canary misbehaves. Contrast the reactive version, which starts flashing and reasons about verification when something looks odd. Same model, same tools — but only one of them produced a procedure you could read before it touched your machines.

Where it sits in the toolbox

Planner-executor is a common building block inside a multi-agent system, where a planner agent supervises one or more executor agents, and it relies on tool use for every real-world action. It composes naturally with agent memory (the plan and its outcomes become part of the record) and with any agentic workflow that must be reviewable after the fact. For a sovereign operator running agents against real infrastructure — miners, wallets, servers — the pattern's real gift is that the plan is a checkpoint you control: nothing touches your machines until a declared, inspectable sequence of steps has passed whatever gate you set. D-Central documents these patterns for operators running agents on their own hardware, where "the agent did something surprising" is not an acceptable incident report.