Run the agent

The brief is written; the Author runs it. Hand the implementation prompt to a Claude Author and run it in task order — keeping the tree compiling after each step.

A5.8.1 assembled the five parts of the brief for a real rung. This dive runs the second stage of the workshop: the implementation prompt, executed in the order it fixes, with a human watching the gate that closes each step. The Portal's web bootstrap f6.1.llms.md opens its prompt with one locked instruction — “Build in this order, keeping the umbrella compiling after each step” — and then lays out seven steps. Advance the figure on the right through them and read the compile state each step leaves behind.

Run in task order Supervise the gates On the Portal References

Run the prompt in task order · step through the seven steps

Step 1 of 7 — T1 Foundation (satisfies —). Tree state after this step: compiling. In task order each step builds on a compiling tree — the foundation is laid before the endpoint stands on it.

Run in task order

The implementation prompt is the brief made runnable: it runs the agent stories F6.1-AS1 through F6.1-AS4 in the task-DAG order T1 → T2 → … → T7. The order is not a preference; it is a dependency order. The endpoint (T2) precedes the supervision wiring (T3), which precedes the router (T4), which the controller (T5) dispatches through. Build it in this order and the umbrella compiles after every step, so the Author never holds a half-assembled tree.

The Portal's web bootstrap fixes that order in one line at the top of its prompt:

# f6.1.llms.md — the comprehensive implementation prompt
“Build in this order, keeping the umbrella compiling after each step:”

  1) Foundation   (T1)        deps + PortalWeb entrypoint + Telemetry + endpoint config
  2) Endpoint     (T2 → R1)   the plug stack + the LiveView socket
  3) Supervision  (T3 → R2)   PortalWeb.Application [Telemetry, Endpoint]; DROP the Bandit child
  4) Router       (T4 → R3,R6) the :browser pipeline + /courses/:user_id + GET /health
  5) Controller   (T5 → R4,R8) index/2 over Portal.courses_of/1 only
  6) View         (T6 → R5)    CourseHTML + index.html.heex from assigns
  7) Verify       (T7 → R7,R8) compile clean · /health 200 · the invariant grep empty · self-heal

Each step names the task it lands and the requirements it satisfies. Run them top to bottom and stop at the gate. The hero figure walks the seven steps; every one of them leaves the tree compiling, because the order was chosen so that nothing is built before the thing it depends on exists.

The principle

Run the implementation prompt in the task-DAG order, keeping the tree compiling after each step. The order is a dependency order; out of it, a step builds on something that does not exist yet.

On the Portal

f6.1.llms.md's prompt opens “Build in this order, keeping the umbrella compiling after each step,” then runs Foundation → Endpoint → Supervision → Router → Controller → View → Verify — the T1–T7 DAG.

The request path the ordered run assembles — endpoint to router to controller to the facade — is the same one the companion course builds, step by step, in Phoenix · the request path.

Supervise the gates

Running the agent is not setting a prompt loose and reading the final report. Each step closes on a gate: the compile is clean, and the step's per-story Acceptance gate passes. A human supervisor watches those gates between steps. When a step's gate fails, the supervisor intervenes before the next step, rather than building on a broken one. This is the same stage-gate discipline the Portal's F6 ship prompts use — a Director in the loop between stages, with a bounded remediate loop on a finding before the human takes over.

Toggle the figure below between a run where every step passes its gate and one where step 5 — the controller — fails. With every gate passing, the build advances through all seven steps. With step 5 failing, the build reaches step 5 and stops; the view is never built on a controller that does not pass.

Supervise the per-step gates · toggle a failing step

Every step's gate passes — the build advances through all 7 steps. Each step compiles and closes its Acceptance gate, so the next step builds on a verified one.

Running the agent is following the prompt's order and watching its gates — the build never advances on a broken step.

On the Portal

On the Portal's web bootstrap, the order and the gates are both written down. The prompt runs F6.1-AS1–F6.1-AS4 over T1 through T7, and each agent story carries the gate that closes it:

# f6.1.llms.md — Agent stories, each closing on a runnable gate (the supervisor watches these)
#
  AS1  boot:       mix compile clean · app boots · GET /health 200 · tree order store → engine → endpoint
  AS2  render:     a known user renders their courses · no enrollments → empty state · templates use assigns only
  AS3  boundary:   grep -rE "Portal\.Engine|Repo|GenServer\.call" apps/portal_web/lib/ returns nothing
  AS4  fail soft:  killing the endpoint restarts it · an injected %Portal.Error{} renders 422, never 500

The Author runs the steps; the supervisor reads the gates. When AS3's grep is non-empty, or AS1's /health is not 200, the supervisor stops the run at that step. Nothing downstream is built on a step that has not closed its gate — the failure is caught where it happened, not three steps later.

The principle

The agent supplies the speed of implementation; the human owns the order it runs in and the gate that closes each step. Supervision watches the gate, not the keystrokes.

On the Portal

f6.1.llms.md's prompt runs Foundation → … → Verify, the umbrella compiling after each; the F6 ship prompts gate each stage, with the Director in the loop and a bounded remediate loop on a finding before the human takes over.

A5.8.1 wrote the brief; this dive runs it in order and watches each gate — the next dive verifies the increment the run produced.

Recap — the run is an order and a set of gates

Running the agent has two disciplines, applied together. Task order: the prompt runs the agent stories in the task-DAG order, so the tree compiles after every step and nothing is built before what it depends on. Supervision: each step closes on a gate, and the human intervenes before the next step on any gate that fails, never building on a broken one. The agent runs the prompt; the human owns the order and the gates. The increment the run produces is verified in the next dive, against the Definition of Done — not the agent's report.

Next in A5.8: Verify the increment — review the run's output against the Definition of Done and the liveness check; an increment is done when it is provably done.

References

Primary sources for running a coding agent on an explicit, well-structured task and for the build-order and verification discipline a prompt fixes, and where the rung this run builds is defined in the companion course.

Sources

Anthropic — Building effective agents — why a coding agent runs an explicit, well-structured task rather than an open-ended goal.
Anthropic — Claude Code best practices — running a coding agent in steps, with a check at each, instead of one undifferentiated pass.
Hunt, A. & Thomas, D. — The Pragmatic Programmer — build in small, verifiable steps and gate each one, so a defect is caught where it is introduced.

Related in this course

A5.8 · Workshop — the workshop hub: brief, run, verify.
A5.5 · The implementation prompt — the prompt this run executes.
A5.6.2 · Supervising — the supervision practice this run applies.
A5.3.2 · The task DAG — the build order this run follows.
Companion · Functional Programming — the course that builds the Portal's engine and web layer.
Companion · Phoenix request lifecycle — the real rung whose prompt this run executes.