LangChain’s Plan-and-Execute Agents post (13 February 2024) pairs a planner that writes a multi-step plan with executors that each take one step and call tools; a re-planning prompt then decides whether to answer or plan again. Its case against a ReAct agent: faster runs, since the large model is not consulted after every action, and cheaper sub-tasks on smaller models. The idea traces to Plan-and-Solve prompting (ACL 2023).
A plan is a proposed route, not permission for an executor to keep going after the world has changed.
What does the planner produce?
Steps, each with an intended outcome, the inputs it needs, and a condition that says when it is done. The plan should be visible state, not prose in a prompt, so it can be inspected before anything runs and resumed after an interruption. The planner owns the sequence; the executor owns the evidence for each step. An orchestrator-worker pattern splits work the same way for parallel tasks, and a supervisor agent routes dynamically when the next worker depends on what came back.
How does the executor stay bounded, and when does it re-plan?
The executor gets one step, the tools for it, and the output it must return. It does not redefine the goal or skip ahead. It returns a result, its evidence, and a status (completed, blocked, needs approval), so a bad result is an execution problem and a wrong step a planning problem. Re-plan from observed state when a prerequisite fails or a tool returns something unexpected, never from the model’s confidence. The smallest useful re-plan is often one changed step, not a new plan. Store the plan and step evidence with durable execution so a retry does not repeat an action, and return control through an explicit agent handoff.
How do we use the planner-executor pattern at Soba Labs?
Most of our agent work runs plan first, execute second, and we check the plan before any executor acts on it:
- A second agent reviews every plan before a person does. On one client sprint, a spec drafted by a single agent included a capability the client’s API did not have and a task to build a field that already existed; a read-only verifier with the real docs, schemas and code now checks each plan first.
- The done condition must be runnable. Seven of nine tickets on one engagement named a test gate nobody could run, so we now run each named gate once on unmodified code before accepting it.
- Planner output is checked, not trusted. The planning agent behind our blog proposes three scored topics and writes nothing, and each glossary link it suggests must return 200 on a live request before use.
- The executor has a circuit breaker: when the same fix fails about three times, it marks the task blocked and moves on.
What an executor really did is read from its agent trajectory.
When is the pattern the wrong choice?
Planning adds a model call, more state, and a plan that can go stale. It pays on jobs with dependent stages, approval gates, expensive actions, or an audit requirement. A short task with an uncertain path suits a ReAct loop better. When the steps never change, code the workflow instead: as we argue in Deep agents in production, a workflow you can draw on a whiteboard should be encoded as that drawing.