video youtu.be Watch ↗

Loop Engineering, Illustrated: Triggers, Skills, Verification, Memory

TL;DR

Austin Marchese repackages the viral "stop prompting, start writing loops" thesis (Boris Cherny, creator of Claude Code; Peter Steinberg) into a concrete, buildable anatomy. A loop is a prompt that re-runs until a goal is verified; loop engineering is designing the system that prompts the agent instead of prompting it yourself. Build one only when a four-condition gate passes — the task repeats, has a clear definition of done, you can afford to be token-wasteful, and the loop has the tools to both act and verify. A successful loop has four building blocks: a trigger (/loop locally, /schedule in the cloud, or a custom orchestration skill); execution skills that are already battle-tested (never loop on unproven skills — this is the video's load-bearing rule); a goal paired with a verification (you can't have a goal you can't check — for abstract/non-technical work you bridge to verifiable by having a review skill emit approved/not-approved or a 1–10 score, ideally from an independent agent); and output + memory (persist lessons-learned to a markdown file — "the agent forgets, the repo doesn't"). Ship new loops in training mode (pause-for-approval at every step until trusted) and keep human checkpoints at the high-leverage decisions. Almost nothing here is new to the graph — it independently corroborates Loop Engineering and Agent Loop — but it sharpens two practices worth naming: Skill-Driven Loop Development and Loop Training Mode.

Concepts introduced

Skill-Driven Loop Development — new. Never loop on unproven steps; compose loops from already-battle-tested execution skills, split from a single orchestration skill; skills carry the verification that makes abstract goals checkable.
Loop Training Mode — new. Graduated per-loop autonomy: pause-for-approval on a new loop's first runs, relax once trusted; keep human checkpoints at high-leverage decisions.
Loop Engineering — corroborated + gated: the four-condition test and building-block anatomy sharpen the existing role-shift concept.
Agent Loop — refined: the four-block anatomy, the "bridge abstract → verifiable" move, and the persist-memory rule.
LLM-as-Judge — corroborated: use an independent agent/model to judge loop output.
Agent Supervision — corroborated: graduated oversight + checkpoint-the-pivotal-decisions.

Held, not dropped

Trigger tooling (/loop local vs /schedule cloud vs custom orchestration skill). Claude-product-specific mechanics; captured in the walkthrough, not promoted to a concept — spin out only if a "loop trigger surfaces" concept becomes worth its own page.
Persistent loop-memory file ("the agent forgets, the repo doesn't"). Captured as a claim on Agent Loop and loosely tied to Evergreen vs Volatile Context / Decision Log; genuinely rich enough to spin into its own agent-memory-file concept on demand.
The creator-economy scaffolding (5-day email series, giveaway, "anti-slop agreement, subscribe") — marketing, not content; noted and dropped from the knowledge graph deliberately.

Key claims

Loop engineering = designing the system that prompts the agent instead of prompting it yourself. principle → Loop Engineering — independently restated (Boris Cherny, Peter Steinberg named); the durable idea is the role shift, not the label.
A loop earns its keep only when four conditions all hold: repeats, clear definition of done, can afford token waste, and has tools to act and verify. (best practice) → Loop Engineering — context: deciding whether a candidate should be a loop at all; a one-time or uncheckable task stays a prompt. Sharpens Agentic Simplicity's "most tasks don't need a loop."
Don't build a loop without battle-tested skills behind it. (best practice) → Skill-Driven Loop Development — context: automating real repeated work; a loop inherits the reliability of its (pre-validated) parts.
A goal is meaningless without a paired verification; for abstract goals you manufacture a checkable signal (a review skill emitting approved/not-approved or a score). principle → Agent Loop, Skill-Driven Loop Development — the acceptance check is the load-bearing reason to loop.
Route verification to a different agent or model for a less-biased verdict. (best practice) → LLM-as-Judge — context: in-loop checking, where self-grading is biased. (Marchese offers a 1–10 score as interchangeable with binary; the graph's judge discipline prefers binary pass/fail + critique — a mild tension, see below.)
Persist loop memory to a plain file — every run restarts from scratch otherwise ("the agent forgets, the repo doesn't"). (best practice) → Agent Loop — context: repeatedly-run loops; corroborated by Addy Osmani and Anthropic's "write notes to a markdown file" guidance.
Promote a loop from supervised to autonomous only once verified — run it in training mode first. (best practice / principle) → Loop Training Mode — autonomy is graduated, not granted at authoring time.
Keep human verification checkpoints at the pivotal decisions of a non-measurable loop. (best practice) → Agent Supervision, Loop Training Mode — the "AI as intern" rule.

Why this corroborates (and where it adds)

This is an independent third-party walkthrough converging on the graph's existing loop spine, so the dominant stance is corroborates: Loop Engineering already recorded the "stop prompting, design loops" thesis and the Boris Cherny quote; Marchese re-derives it and adds Peter Steinberg as a second named builder — N sources now agree, no concept duplicated. It also builds_on / refines in three places worth logging: (1) a concrete four-condition gate for loop candidacy and a four-block anatomy (trigger / execution skills / goal+verification / output+memory) that give Agent Loop and Loop Engineering a buildable shape; (2) two genuinely nameable practices spun out as new concepts — Skill-Driven Loop Development and Loop Training Mode; (3) corroboration for LLM-as-Judge (independent-agent verification) and Agentic Simplicity (don't loop unless it pays; don't burn tokens on unearned autonomy).

One mild tension. Marchese presents "approved/not-approved or a 1–10 score" as interchangeable verification outputs. The graph's LLM-as-Judge holds that binary pass/fail + a written critique beats numeric scales (sharper, less inter-rater noise). Not a contradiction of the loop thesis — both agree you need a concrete verdict — but the form of the verdict is where the durable judge discipline and this video's casual advice diverge; prefer the binary.

Illustrated walkthrough

The video is a talking-head explainer (Austin Marchese, NY cap, home studio) interleaved with animated title-card slides and short B-roll clips of the people being quoted. Its natural altitude is the through-line + the block structure carried on the slides, not the transcript.

t=0:04 — the hook. A tinted still of Boris Cherny with the pull-quote "I don't prompt Claude anymore. My job is to write loops." (labelled "Creator"). The framing: when the people who build the tools say stop prompting and start building loops, listen — and "it's actually really simple; most people just overcomplicate it."
t=1:00 — the source clip. B-roll of Boris on stage (a16z-style event) delivering the quote in context: "I have loops that are running… they're the ones that are prompting Claude… my job is to write loops." The distinction lands here: instead of prompting Claude 100 times, design loops that accomplish clear goals. (The video also cites Peter Steinberg, "creator of Open Claude" — likely an open-source coding agent — as saying the same thing.)
t=1:31 — when to loop (four-condition test). Presenter over B-roll walks the gate: (1) does the task repeat? one-time → just prompt; (2) is there a clear definition of done? (his COO-of-a-$25M-startup framing: quantify "done"); (3) can you afford to be wasteful? loops self-prompt until complete, so they burn tokens; (4) does the loop have the tools to act and verify (e.g. can it check a website is live)? Yes to all four ⇒ a loop candidate.
t=2:34 — the roadmap slide. "STOP PROMPTING CLAUDE. — PART 1: What a loop actually is and when to use them / PART 2: The 4 things every [successful loop needs]." Confirms the three-part structure on screen.
t=3:03 — Block 1: the trigger. Three simplest triggers: /loop (runs at an interval on your local machine — stops if you close the laptop), /schedule (runs in the cloud on any cadence), and a custom loop orchestration skill ("how I run all of my loops") — a single /check-weather-loop-style skill that kicks off the whole loop with goal, completion, and verification baked in.
t=4:01 — Block 2: execution skills. The rule stated plainly: "you don't build a loop without battle-tested skills behind it." Execution skills are the specialized jobs the orchestration calls; they encode how you want a task done (the /analyze-workout example: without it the loop says "it's raining, cancel your run"; with it, "you love running in the rain"). This is Skill-Driven Loop Development.
t=5:14 — Block 3: goal + verification. "Every loop needs two things tied together: a goal and a verification… you can't have a goal unless you can verify it was complete." Technical example: "launch to this domain, loads in <2s" verified by hitting the domain, checking content, timing load, and a /engineer-review skill approving. Non-technical: bridge abstract → verifiable — a /draft-emails loop verified by /email-review + /writing-voice
- /fact-checker skills, each emitting approved/not-approved or a score. Pro tip: have a different agent/model (sub-agents, or a Codex plugin) judge, for a less-biased opinion (LLM-as-Judge).
t=8:18 — Block 4: output + memory. Money slide: a headshot of Addy Osmani ("Software Engineer and Leader at Google Cloud AI") beside an Anthropic-style docs excerpt on agent memory — "an agent improves when it can record lessons from previous runs… provide a place to write notes… a one-line summary at the top… record corrections… don't save what the repo can figure out… update an existing note rather than creating a duplicate." The line quoted: "the agent forgets, the repo doesn't." (The transcript's "Adadi Asmani" is a mis-hearing of Addy Osmani — recovered by reading the slide.) Without recorded memory every run starts from scratch, re-hits the same failures, and wastes tokens.
t=9:16 — Part 3: build your first loop. Slide: "DO THIS INSTEAD (LOOP ENGINEERING) — PART 2: The 4 things every SUCCESSFUL loop needs / PART 3: How you [build your first loop]." Advice: start with the smallest thing you've already proved works, run it through the four-condition test, then build the orchestration skill.
t=10:17 — loop training mode. The guardrail: the first few runs, the loop pauses at every step for approval ("quick check before I burn the tokens") until you trust it, then you disable it. Purpose: verify behaviour and avoid burning tokens on a wrong loop (Loop Training Mode). Later (~t=11:14) the "AI is like an intern" analogy makes the companion point — for less-quantifiable goals, put human checkpoints at the pivotal decisions (a party's date/venue/theme) where a wrong turn ruins everything downstream.

Visual coverage. Confidence is ok (93/93 frames kept, 0% dedup, 0% grid-floor); the largest un-illustrated stretch is ~34 s. Coverage is good enough to trust the through-line above, but note the sampler misses text-on-solid-background changes, so absence of a frame in a gap is not evidence a slide didn't change — several on-screen "here's a prompt" cards (the copy loops that are the video's real lead-magnet payload) are shown only briefly and were not individually captured.