4 Planner and Executor: Split Long Agent Tasks into Controllable Loops

Goal and State keep the agent aligned. But long tasks still need execution structure.

That is why a practical harness usually separates the Planner from the Executor.

The Planner decides what should happen next. The Executor performs the current step and reports what happened.

1. The Basic Loop

A simple agent loop looks like this:

Goal
-> Planner
-> Task
-> Executor
-> Tool
-> Observation
-> State Update
-> Re-plan

This loop is more stable than asking one model call to do everything at once.

The planner can keep the route visible. The executor can focus on the immediate action.

2. What the Planner Produces

A planner should not only produce vague steps. It should produce executable task objects.

For example:

{
  "task_id": "research-official-docs",
  "input": "Find official documentation for the model",
  "action": "search and read sources",
  "expected_output": "short source summary with links",
  "acceptance": ["official source included", "no unsupported claims"]
}

This makes each step testable.

A weak plan says:

Research the topic.

A stronger plan says:

Collect official sources, extract the release date, capabilities, limitations, and pricing notes, then save a source summary.

3. What the Executor Should and Should Not Do

The Executor should focus on the current task.

It can:

• call tools
• read files
• edit code
• write a section
• run tests
• return observations

It should not casually change the main goal.

If the executor discovers that the original plan is wrong, it should report the observation and ask the planner or harness to re-plan.

This boundary keeps the workflow controllable.

4. Tool Outputs Become Observations

Tool outputs are not automatically state. They are raw observations.

For example, a build log may contain hundreds of lines. The state should not store all of them. It should store the useful result:

{
  "observation": "Build failed because app/en/[category]/[order]/page.tsx has a type mismatch in metadata.",
  "next_action": "Fix the metadata type and run build again."
}

The harness turns noisy tool output into concise state.

5. When to Re-plan

Re-planning is needed when:

• a blocker appears
• a tool result disproves the current assumption
• the user changes the requirement
• a step fails acceptance criteria
• a better route becomes obvious

Good re-planning preserves the goal and adjusts the path.

Bad re-planning changes the goal without permission.

6. Practice: Design a Six-Step Plan

Pick a real task, such as writing a tool review article, and design six task objects.

Each task should include:

• input
• action
• expected output
• acceptance criteria

If every task can be handed to an executor independently, the plan is strong enough.

7. Lesson Summary

Planner and Executor separation turns a long task into a controlled loop.

The Planner maintains the route. The Executor handles the current step. Observations update State. The harness re-plans when reality changes.

This is one of the core patterns behind reliable coding agents, research agents, and writing agents.