# Module 3 — The Executor Role

> The Executor doesn't ask questions. It builds.

---

## What Is the Executor?

In a multi-agent AI system, the **Executor** is the role responsible for taking a defined task and completing it — writing code, calling APIs, modifying files, running commands, sending requests.

The Executor acts. It does not plan. It does not review. It executes the instructions it receives and reports back with results.

---

## The Executor's Responsibilities

- Receive a clearly scoped task from the Planner
- Execute the task using available tools (file system, APIs, shell)
- Return the output: code, file contents, API response, error log
- Flag blockers — but not make decisions about them

---

## What the Executor Is NOT

| Not the Executor's job | Who does it |
|------------------------|-------------|
| Deciding *what* to build | Planner |
| Researching options | Researcher |
| Checking quality | Reviewer |
| Managing the project | Planner |

The Executor has a narrow, powerful mandate: **do the thing**.

---

## Best Models for Execution

| Model | Why |
|-------|-----|
| Claude Sonnet 4.5 | Best agentic capability, tool use, follows instructions precisely |
| GPT-4.1 | Fast, reliable, excellent at structured output |
| Claude Code | Purpose-built terminal executor — reads, writes, runs |

**Avoid Opus for execution.** It overthinks. Execution needs speed and precision, not deliberation.

---

## Best Tools for Execution

| Tool | Use case |
|------|----------|
| Claude Code | Autonomous file + terminal execution |
| Cursor (Composer) | Multi-file code changes |
| VS Code + Copilot | Single-file edits and completions |
| API direct call | Programmatic execution in pipelines |

---

## Writing an Executor Prompt

The Executor needs:
1. **Clear input** — what files, data, or context does it have?
2. **Clear output** — what should it produce?
3. **Clear constraints** — what must it not do?

**Example (good):**
```
You are an Executor. Your task:
- Input: the file `api/users.php`
- Output: add rate limiting (max 10 req/min per IP) using a token bucket approach
- Constraints: do not change the function signatures or the response format
- Return: the modified file only
```

**Example (bad):**
```
Add rate limiting to the API
```

---

## Executor Failure Modes

| Failure | Cause | Fix |
|---------|-------|-----|
| Hallucinated output | Unclear constraints | Add explicit output format |
| Scope creep | Task too broad | Break into smaller tasks |
| Silent errors | No error reporting | Require the executor to log blockers |
| Over-engineering | No constraints | Add "keep it simple" and length limits |

---

## Executor in Practice

When using **Claude Code** as an Executor:

```bash
claude "Modify /var/www/myapp/api/users.php to add rate limiting (10 req/min per IP). 
Do not change function signatures. Return the modified file."
```

When using **Cursor Composer** as an Executor:
- Open Composer (Cmd+I)
- Describe the task precisely
- Review the diff before accepting
- Commit immediately

---

## Checkpoint

Before moving on, you should be able to:

- [ ] Describe what the Executor role is responsible for
- [ ] Write a well-scoped Executor prompt
- [ ] Choose the right tool for a given execution task
- [ ] Identify when a task is too broad for an Executor

---

*Next: [Module 4 — The Planner Role](planner.md)*