Planner-worker, in practice

The planner-worker pattern: one model call ("planner") decides the steps, then a second loop of calls ("worker") executes each step. The split is useful because planning and executing benefit from different prompts, different models, and different review surfaces.

When the split is worth it

• The task naturally decomposes into a handful of steps that can each be evaluated independently.
• Different steps want different tool surfaces — the planner might only need read tools, the worker only needs write tools.
• You want to inspect the plan before the worker runs it — useful for high-stakes actions.

When to keep it monolithic

For one-shot triage, single-action tasks, or when the steps depend tightly on each other's intermediate state. The overhead of a planner pass is not free — latency, cost, and a place for the system to bifurcate when the planner and worker disagree.

Log every hand-off

The single most useful piece of observability for a multi-step system is a log of every hand-off: planner produced this plan, worker received it, worker emitted these tool calls, worker returned this result. When something goes sideways, the gap between what the planner wanted and what the worker did is where you'll find the bug.