Planner-executor splits: when to separate them

A single model doing both planning and execution feels elegant on day one. By month three, the trace logs tell a different story: the planner part of the prompt drifts under tool-call context, and the executor part starts hallucinating steps that were never planned. Splitting the two is rarely the first instinct. It is often the right one.

What the split actually buys you

A dedicated planner runs on a clean context — just the user request and the available tool schemas — and produces a plan it cannot pollute with execution detail. A dedicated executor receives one step at a time, runs it, and reports back. Each component gets a smaller, sharper prompt. Each one is independently swappable: a cheap executor with an expensive planner is a real cost lever, and you cannot pull it without the split.

Where the split costs you

Latency. Two model calls per step, sometimes three when the planner needs to revise. For interactive use cases under two seconds, the split is often too expensive. The honest answer is to keep the joint loop for short tasks and split only when the task horizon exceeds five steps or when you’ve already seen the joint loop drift in production.

The planner-executor split is not architectural purity. It is a response to a specific failure mode that single-model loops exhibit at scale.