Concept Contrast Fable

Planner and executor: one draws the roadmap, one presses the accelerator

Conclusion first:The most classic pairing in Agent architecture is also the two roles most easily compressed into a single module. The planner breaks user intent into a sequence of subtasks, decides what to do first and what next, chooses which tools to use, and estimates resources; the executor actually calls APIs, reads and writes files, and handles returned results. When planning logic is embedded in execution code, debugging reveals that you can neither find planning errors nor fix execution bugs.

The most classic pairing in Agent architecture is also the two roles most easily compressed into a single module. The planner breaks user intent into a sequence of subtasks, decides what to do first and what next, chooses which tools to use, and estimates resources; the executor actually calls APIs, reads and writes files, and handles returned results. When planning logic is embedded in execution code, debugging reveals that you can neither find planning errors nor fix execution bugs.

Fable

Two workstations on a construction site that should not be merged

On the construction team of a high-rise building in the south of the city, two roles had always been held by the same person. Every day after arriving at the site, the construction coordinator first went through the day's work sequence against the drawings—which formwork to remove first, what time the rebar would arrive, and on which floor concrete pouring would begin. After arranging that, he used the walkie-talkie to call each crew in to work. One person both sequenced the work and dispatched the crews, and after two years no one thought there was a problem.

In the third year, they took on a curved curtain wall office building. The process dependencies were far more complex than the previous box-shaped buildings—every glass panel of the curtain wall had a different size, and if the installation order was wrong, it had to be removed and redone. The construction worker still arranged the process and scheduled it himself, and as a result, halfway through installing the fourth-floor curtain wall, they discovered that the positioning brackets on the third floor had not been removed, and the entire schedule was stuck.

Only afterward, looking through the construction log, did they discover the problem. When the construction worker arranged the process that morning, he omitted the prerequisite step "remove the temporary support on the third floor," but when scheduling the crew he jumped directly to "install the fourth-floor curtain wall." Because he both arranged and executed it himself, with no second pair of eyes on the process checklist, the error went straight from planning into the site.

The chief engineer split process layout and on-site scheduling into two roles. A new position called process planner was created, specifically to compare the overall schedule and floor plans and produce a daily list of prerequisites. The construction supervisor was only responsible for dispatching crews after receiving the list, checking completion, and reporting anomalies. The two sat in the same office, but signed off on two different forms.

In the first week after the split, production efficiency actually dropped. Construction workers were often idle because some prerequisite on the checklist was not met, and the crew waited to work. But starting in the second week, the number of unexpected stoppages plummeted—previously formwork was removed too early and caused rework, but now the planner marked the minimum curing time in advance, and the construction workers followed the table.

At the progress meeting, the chief engineer drew a division-of-labor chart: the planner manages "which things to do, in what order, and which prerequisites must be met" — this is planning and reasoning. The construction worker manages "who to call to do it, whether it's done, and whether there are problems when done" — this is execution and feedback. The two roles pass information through a work order checklist.

When the building was topped out, the total construction period was eleven days ahead of schedule. The most critical improvement was not in speed, but in being able to pinpoint any delay at a glance: was it a planning omission, or was the site not executing according to plan? When the two were mixed together before, these two types of errors masked each other, and the accountability meeting turned into a guessing game.

Planner

In an Agent system, the module responsible for decomposing user intent into a sequence of subtasks, selecting tools and strategies, and scheduling execution order.

Executor

The module in an Agent system responsible for actually invoking tools, executing subtasks, handling returned results, and reporting status.

Story Mapping

The process planner lists prerequisites: a planner that breaks down tasks, sets order and checks dependencies
The foreman dispatches crews and checks completion: the executor, which calls tools, runs subtasks and reports results
One person holding two roles causes missed prerequisite steps: planning logic and execution logic are mixed together, with no isolation for errors
The two signed forms pass information to each other: the planner outputs a sequence of subtasks, and the executor executes in order and feeds back status

Applying it to an Agent project

When designing an agent architecture, do not write planning logic as if-else inside execution code. The planner module independently outputs a subtask plan, and the executor module executes according to the plan and returns the result of each step. The two types of modules each have their own logs, evaluations, and independent error handling. If planning goes wrong, you can trace back whether the plan was reasonable; if execution goes wrong, you can inspect the parameters and return values of a single call. The first week after splitting them may be more troublesome, but debugging costs afterward will drop off a cliff.

Planner Executor