16.3 The "planner-executor" vibe pattern

The core idea: separate planning from execution

The planner-executor pattern is a way to run tool-using workflows without letting the model “run wild.”

Instead of “model decides and executes continuously,” you split roles:

• Planner: proposes steps and tool calls (no execution)
• Executor: runs approved steps and returns results

Often the executor is your system code (not a model). This gives you control and auditability.

Why planner-executor is safer and more reliable

It prevents common tool-calling failures:

• Runaway loops: planner must stop and wait; executor enforces budgets
• Unsafe actions: write tools require explicit approval steps
• Messy reasoning: plan is a reviewable artifact
• Hidden assumptions: planner surfaces required inputs and unknowns

It also improves product UX: you can show users what will happen before it happens.

A practical flow (plan → approve → execute → answer)

1. Plan: model proposes a short plan and lists tool calls with args.
2. Approve: system (or user/human) approves plan or asks for changes.
3. Execute: system runs tools step-by-step with validation and budgets.
4. Answer: model produces the final response grounded in tool outputs.

For many apps, the plan step is optional for simple read-only flows. But for write tools, it’s essential.

Copy-paste prompts for planner-executor

Prompt A: planner only

You are the planner. Do not execute tools.

Goal:
[Describe what we want.]

Available tools:
- [list tools + one-line description]

Rules:
- Propose 3–7 steps max.
- For each step, specify which tool to call and the exact arguments.
- If any required input is missing, ask clarifying questions instead of guessing.
- Stop after the plan and wait for approval.

Prompt B: executor step (system-side rule)

Executor rule:
- Execute ONLY the next approved tool call.
- Validate arguments against the tool schema.
- Enforce budgets (max calls, max cost).
- Return the tool result (or error) in a structured envelope.

Prompt C: final answer grounded in tool outputs

Using ONLY the tool outputs below, produce the final user response.

Rules:
- If the tool outputs are insufficient, say what is missing.
- Do not invent facts not present in tool outputs.

Tool outputs:
```json
...
```

Budgets and stop conditions

Budgets are how you prevent runaway behavior. Common budgets:

• max tool calls per user request
• max total latency per request
• max tokens per request
• max “write tool” calls (often 0 without approval)

Stop conditions should be explicit:

• stop after N tool calls
• stop when required data is retrieved
• stop if the same error repeats

Human-in-the-loop review points

Places where humans should approve or review:

• before any write tool executes
• when the plan touches sensitive data
• when the model proposes actions outside expected scope
• when a tool returns an ambiguous or risky result

This is how you keep “agentic behavior” safe without losing speed.

Where to go next

• 16.4 Tool error handling
• 16.5 Preventing abuse and runaway loops