Planner/executor pattern

Overview

• A planner proposes steps; an executor performs permitted steps and reports results.
• Splitting the roles separates deciding from acting.
• The executor still enforces constraints rather than blindly following the plan.

Why this matters

Complex tasks may benefit from a visible plan, independent budgets, and controlled execution.

An everyday example

An architect creates a plan and licensed tradespeople perform approved work.

A technical example

Plan “look up policy, gather documents, draft claim”; executor exposes only those approved tool types.

How it works

1. Propose typed steps
2. Validate plan
3. Execute one step
4. Observe
5. Update remaining plan
6. Approve consequential actions.

Architecture and flow

Goal → planner → plan validator → executor → results → bounded replanning.

The insurance assistant example

Prepare a claim packet from several sources while keeping submission separate.

When to use it

Longer tasks with recognizable intermediate deliverables.

When to avoid it

Avoid two model roles for a one-tool lookup or allowing the plan to dictate authorization.

Interview answer

“Planner/executor separates task decomposition from controlled action. I validate every step and replan only when observations justify it.”

Benefits, trade-offs, and production considerations

• Plans can contain nonexistent tools or stale dependencies.
• Use typed step names, limited depth, and verified completion criteria; execution results should overrule unsupported planning assumptions.