Plan-and-Execute splits the agent into two roles: a planner that lays out the full task graph up front, and an executor that works through it step by step — with a replan trigger when reality disagrees.

Pure ReAct decides the next action one step at a time, which makes it reactive but myopic: nothing prevents the loop from wandering into work that a 30-second look-ahead would have ruled out. Plan-and-Execute spends tokens up front on a structured plan — an ordered list of steps with dependencies and success criteria — and then executes that plan mechanically. The planner benefits from seeing the whole problem at once; the executor benefits from a bounded, checkable contract.

The pattern earns its keep on three fronts. Parallelism: steps the planner marks as independent can run concurrently, something step-at-a-time loops structurally cannot do. Auditability: the plan is an artifact — reviewers diff the plan against what actually happened. Cost: plan tokens are cheap relative to the execution tokens they save by preventing wasted detours.

The Replanning Trigger

Plans rot on contact with reality. The design question is not whether to replan but when: after every step (expensive, thrash-prone), only on failure (risks compounding drift), or at checkpoints (the pragmatic middle). Mature systems replan when (a) a step fails after its retry budget, (b) an observation invalidates a downstream assumption, or (c) the executor discovers work outside the plan's scope — which is registered rather than silently absorbed. LangChain's plan-and-execute reference and BabyAGI-style task queues both formalize this as re-invoking the planner with completed-step receipts, so the new plan preserves progress instead of restarting.

The trade-off to respect: a rigid plan executed by a weak executor produces confident failure, while constant replanning degrades into ReAct with extra tokens. Treat the plan as a hypothesis under test — authoritative until falsified, never after.