Module 3 · Planning, Context & Multi-agent Systems · scripted
The Planner–Executor
Spend the judgment once
The Explorer and the Scientist spend judgment at every fork, because their forks arrive one at a time, each shaped by the last. But a large class of problems has a different structure: the situation needs real intelligence to read — once — and then the work is repetitive, long-running, or high-volume. For those, the third archetype: use the mind to write the workflow, then run the workflow without the mind.
The move
The formulation principle said: hire the model to formulate
the PROBLEM, not to labor on it.
The Planner–Executor extends it one level up:
hire the model to formulate the PROCESS.
PLAN judgment, once: read the messy situation,
emit a concrete workflow — as an artifact.
EXECUTE no judgment: the workflow runs at code prices,
as many times as needed.
ESCALATE judgment returns ONLY on exception.Classification: this archetype is half in, half out of conversation. Planning is a short conversation — judgment on a small wall. Execution is not a conversation at all: the plan runs as code, and no wall exists between exceptions.
The nightly pipeline
The setting: a collaborator will deliver sensor exports every night for the season. Their format is idiosyncratic — header quirks, local units, a serial-number convention — exactly the messy reading an LLM is good at. But it needs that reading once:
You have the following tools available for use:
- inspect_files( samples )
- emit_plan( workflow )
Task: Here are three sample files from NTNU's export (attached). Set up our nightly ingestion for this feed.
⟨tool_use⟩
inspect_files(samples = ["export-0912.csv", …])⟨tool_result⟩
[3 files: semicolon-delimited; two header lines; timestamps in
local time, no zone; depths in fathoms; sensor ids like
"NTNU-B2/7"; occasional trailing summary row]I've read the quirks: double header, local timestamps, fathoms, a summary row to drop, and their id scheme maps to our "B2-07" form. Emitting the workflow.
⟨tool_use⟩
emit_plan(workflow = "[see plan below]")The plan — a workflow as an artifact
Study that artifact for a moment, because the artifact is the archetype. It is legible — a colleague can read it. It is approvable — the data steward can sign off on it before it ever runs, something no agent trajectory can offer. It is diffable — when it changes, the change is visible line by line. And from tonight on, it executes at code prices: no mind, no wall, no re-orientation — the plan runs the 99 quiet nights for the cost of electricity.
The plan is an artifact
An agent's decisions are spread through a transcript. A planner's decisions are gathered into a document. That single difference buys: review BEFORE execution, approval by humans, versioning, diffing, blame — the entire apparatus civilization has for documents, applied to behavior.
Judgment returns only on exception
Then, one night in November:
[exception, raised by the executor at 02:04] malformed_feed: stage 1 (validate) — expected 2 header lines, found 1; new column "qc_flag" present; delimiter now comma. Run halted; file quarantined as q-1104. Ingestion paused.
The feed's format has changed — this isn't a corrupt file, it's a new export version: single header, added qc_flag column, comma delimiter. I'll verify against the quarantined file, then re-plan, not patch tonight's run by hand.
⟨tool_use⟩
inspect_files(samples = ["q-1104"])⟨tool_result⟩
[confirms: 1 header, comma-delimited, qc_flag ∈ {0,1,2},
otherwise identical semantics]⟨tool_use⟩
emit_plan(workflow = "[v2: delimiter comma · 1 header ·
qc_flag: drop rows =2, keep flag otherwise · all else
unchanged]")Plan v2 emitted — the diff is three lines: delimiter, header count, and a qc_flag rule (rows flagged 2 are excluded, per their QC convention). Awaiting steward approval before resuming; q-1104 will re-ingest under v2.
Escalation is part of the design
The executor's stages RAISE with a reason — the instructive error, one level up. The reason becomes the planner's brief. handle the 99% at code prices summon judgment for the 1%, with the evidence attached and the RESULT of judgment is always a new plan, never a quiet, one-off intervention
Where it sits
How is this different from the pipeline we built two lessons ago? There, a human designer wrote the workflow at design time, for a task type. Here, the planner writes a workflow per situation — NTNU's feed gets its plan, the Bergen collaborator's completely different export gets its own — from the same planner. The Planner–Executor is the pipeline archetype with an agent as its architect:
The family, so far
The middle row's lesson generalizes: the more of the path you can fix — at design time, or per situation — the less agency you rent, and the cheaper, faster, and more legible each run.
One requirement makes the whole archetype possible, and it points directly at the next two lessons: the planner needs a plan language — rich enough to express real workflows (stages, conditions, rules), bounded enough that the steward can audit what any plan could possibly do. Designing that language is its own discipline, and it's where we go next.
- The steward must approve plan v2 at 08:00 with coffee in hand. What properties of the plan artifact make that a five-minute task instead of an act of faith?
- In Example 2, argue the other side: when WOULD a one-off intervention (fix tonight's file by hand, keep plan v1) be right? What does that choice cost the system's legibility?
Find the recurring process in your research life that you currently do by hand or re-explain to an agent every time. (1) Write the planner's brief: what it inspects, what a correct outcome is. (2) Write the plan artifact it should emit for one real instance — stages, rules, and every RAISE with its reason. (3) Write the exception you most expect, and the plan diff that answers it. (4) Decide who approves: what does your "data steward" need to see in the artifact to sign?