# Module 4 — The Planner Role

> The Planner sees the destination. Everyone else sees the next step.

---

## What Is the Planner?

The **Planner** is the strategic role in a multi-agent system. It takes a high-level goal — "build a login system", "analyze this dataset", "draft a proposal" — and breaks it into a sequence of concrete, scoped tasks that other roles can execute.

The Planner doesn't build. It *designs the build*.

---

## The Planner's Responsibilities

- Understand the goal and constraints
- Break the goal into discrete, actionable tasks
- Assign tasks to the right roles (Executor, Researcher, Reviewer)
- Sequence tasks correctly (what depends on what)
- Adapt the plan when blockers are reported

---

## What the Planner Is NOT

| Not the Planner's job | Who does it |
|-----------------------|-------------|
| Writing the code | Executor |
| Finding information | Researcher |
| Checking quality | Reviewer |
| Doing everything itself | That's not a system, that's chaos |

---

## Best Models for Planning

| Model | Why |
|-------|-----|
| Claude Opus 4 | Deepest reasoning, best at decomposing ambiguous goals |
| Claude Sonnet 4.5 | Faster, cheaper, still excellent for structured planning |
| GPT-4.1 | Good at structured output (task lists, JSON plans) |

**Use Opus when:** the goal is complex, ambiguous, or high-stakes.  
**Use Sonnet when:** the goal is clear and you need speed.

---

## What a Good Plan Looks Like

A good plan from the Planner contains:

1. **Goal statement** — one sentence
2. **Assumptions** — what is known, what is assumed
3. **Task list** — ordered, each with role + input + output
4. **Dependencies** — what must complete before what
5. **Open questions** — what needs human input before proceeding

**Example plan:**

```
Goal: Add user authentication to the existing PHP app

Assumptions:
- Database is MySQL, already connected
- Sessions are available (PHP)
- No OAuth required — email + password only

Tasks:
1. [Researcher] Find existing user table schema → output: schema summary
2. [Executor] Create login.php and register.php → input: schema, output: working auth pages
3. [Executor] Add session middleware to all protected pages → input: file list
4. [Reviewer] Review all auth pages for security issues → output: findings list
5. [Executor] Fix findings from review → input: findings list

Open questions:
- Should passwords be reset-able? (needs human answer before task 2)
```

---

## Writing a Planner Prompt

```
You are a Planner. Your goal:
[describe the high-level goal]

Constraints:
[list what must/must not happen]

Produce:
- A numbered task list
- Each task must specify: role (Executor/Researcher/Reviewer), input, expected output
- Flag any open questions before the task list
```

---

## Planner in Practice

In a single-person workflow, *you* often play Planner + Executor. The discipline still applies:

1. **Write the plan first** before you start prompting
2. **One task = one prompt** — don't ask an Executor to do two things at once
3. **Review the plan** before you start executing — is the sequence right?
4. **Update the plan** when reality diverges from it

The plan is a living document, not a contract.

---

## Planner Failure Modes

| Failure | Cause | Fix |
|---------|-------|-----|
| Tasks too vague | Planner didn't define inputs/outputs | Add explicit I/O to every task |
| Wrong sequence | Dependencies not mapped | Draw the dependency graph first |
| Scope creep | Goal wasn't constrained | Add explicit "out of scope" section |
| Plan ignored | Too complex to follow | Simplify — max 7 tasks per plan |

---

## Checkpoint

Before moving on, you should be able to:

- [ ] Write a goal statement in one sentence
- [ ] Break a goal into 3–7 discrete tasks
- [ ] Assign each task to the right role
- [ ] Identify the dependencies between tasks
- [ ] List open questions before execution begins

---

*Next: [Module 5 — The Researcher Role](researcher.md)*