About This Catalog

This is the nineteenth volume in a catalog of the working vocabulary of agentic AI. The volumes before it have each fixed one axis of the design space and worked along it. The first cataloged what agents do --- the patterns by which LLM calls compose in time, sorted by the shape of the composition. The fourth cataloged what wakes them --- the events and triggers, sorted by the source of the signal. Both of those volumes brush against a third question without ever making it the subject: once an agent is running its loop, how is that loop invoked again, and who decides when it stops?

This volume takes that question as its spine. Every agentic run is the same loop underneath --- gather context, act, check the work, repeat if needed, respond --- and the volumes on shape and trigger have already dissected the loop’s internals and its wake-up signals. What they leave orthogonal is the invocation-and-autonomy axis: not the mechanics of a single iteration and not the connector that fires the first one, but the arrangement that governs whether there is a next iteration at all, and who holds the authority to end the run. Sorted along that axis, four loop-invocation types fall out --- turn-based, goal-gated, interval, and proactive/scheduled --- and they line up as a ladder. Control of the stop decision climbs from the human, to an evaluator model, to the clock, to the cloud. Each rung inherits the loop mechanics of the ones below it and changes only who ends the run. The four rungs plus their composition are the subject of this catalog.

Scope

Coverage:

The four loop-invocation types, presented as Fowler-style entries: the Turn-Based Loop (human holds the stop decision), the Goal-Gated Loop (an evaluator holds it), the Interval Loop (the clock holds it, locally), and the Proactive / Scheduled Loop (the cloud holds it, with no human in real time).
Loop Composition --- how the four primitives stack to build durable, long-running autonomy.
The autonomy-axis framing that orders the four rungs, plus the cost-and-quality and getting-started guidance for choosing and operating a rung.

Out of scope:

The loop mechanics themselves --- how a single iteration gathers context, calls tools, and checks its work. That is the subject of Volume 01 (Patterns of AI Agent Workflows); this volume treats the iteration as a given and catalogs only its invocation.
The trigger connectors --- the webhooks, message buses, file watchers, and cron plumbing that deliver the wake-up signal. Those are cataloged in Volume 04 (Events & Triggers); here the signal source matters only as far as it determines who holds the stop decision.
Product-by-product comparison of the tools that implement these loops. Volume 14 (The AI Agent Products Survey) surveys the market; this volume stays at the level of the pattern.

Chapter 1. The Autonomy Axis

Every agentic run is a loop. The model gathers the context it needs, takes an action, checks its own work against what the task asked for, repeats the cycle if the work is not yet done, and responds when it is. Strip away the framework, the tools, and the trigger, and this is what remains: gather context --- act --- check work --- repeat --- respond. The volumes on workflow shape have already taken this loop apart from the inside, naming the ways iterations chain, branch, and nest.

What varies across the series is not the loop’s shape but its governance. The interesting variable --- the one this volume isolates --- is who holds the stop decision and what invokes the next iteration. A run that a human approves turn by turn and a run that a scheduled cloud worker executes overnight can share an identical inner loop; what separates them is entirely a matter of who is authorized to say “stop, this is done” and what causes the loop to fire again. Fix that governance and you have fixed the character of the autonomy, regardless of what the loop does inside each turn.

Sorted by who holds the stop decision, the four loop-invocation types form a ladder, and control of the stop decision climbs it rung by rung: from the human, who approves each turn; to an evaluator model, which checks a condition every time the agent tries to stop; to the clock, which re-fires the loop on a local interval; to the cloud, which runs the routine on a schedule with no human present in real time. Each rung inherits the mechanics of the rungs below it --- the inner loop does not change --- and alters only who ends the run and what wakes it next. Reading the ladder from bottom to top is reading a progression in autonomy: the human hands off the stop decision first to a criterion, then to a timer, then to a durable scheduler, ceding a little more real-time control at each step in exchange for a little more unattended reach.

This axis is orthogonal to the two the series has already mapped. Volume 01 sorts agent behavior by the shape of the loop --- how iterations compose. Volume 04 sorts it by the trigger --- what signal wakes the loop. This volume sorts it by invocation and autonomy --- who ends the loop and what re-invokes it --- a question the shape and trigger axes only touch in passing. A single agent has a position on all three axes at once: it has a loop shape, a trigger source, and an invocation type, and the three can be chosen independently.

A word on why a nineteenth volume, since the series has learned to ask. Volume 17’s closing appendix argued that the catalog could reasonably have ended at seventeen, and it asked every volume added afterward to justify its place rather than assume one. This one earns its place by naming a concern that was latent all along. The stop-decision axis was implicit in Volume 01’s supervisory loops, in Volume 04’s schedule triggers, and in Volume 18’s plan-and-permission modes, but no volume made it the subject, because for most of the series’ life the tooling did not force the question --- loops were overwhelmingly turn-based and human-paced. As loop-invocation tooling matured --- goal-based runners that hand the stop decision to an evaluator, interval runners that hand it to a local clock, and scheduled cloud runners that hand it to a durable service --- the axis became a first-class engineering concern with distinct patterns, costs, and failure modes. This is precisely the case the series overview makes for a catalog designed to be revised: not that seventeen was wrong, but that the ground moved, and the vocabulary should move with it. Volume 17’s argument stands; this volume is the kind of addition it invited.

Chapter 2. The Four Loop Types

Turn-Based Loop

Classification Invocation type (the human holds the stop decision, per turn).

Intent

Run the agentic loop at human pace, with the user approving each turn before the next begins. Claude gathers context, acts, checks its work, repeats if the turn is not yet complete, and responds --- and the human decides whether to continue, redirect, or stop. The stop decision never leaves the person at the keyboard.

Motivating Problem

Many tasks are short, one-off, and consequential enough that the convenience of unattended running is not worth the cost of a wrong autonomous run. A misread instruction that a human would have caught in one glance can, if the loop is allowed to proceed on its own, produce a cascade of confident, wrong actions. For this class of work the human wants to stay in the loop --- to see each turn’s result and grant or withhold permission for the next --- because the marginal turn is cheap to supervise and expensive to get wrong.

How It Works

The loop is triggered by a user prompt. Claude runs one turn of the gather-act-check cycle, then either responds because it judges the task done, or pauses because it needs more context or the user’s go-ahead. The human reads the result and supplies the next prompt, an approval, or a correction, which invokes the next turn. The loop stops when the model judges the task complete or when the human stops supplying turns. Authority to end the run stays with the human throughout; nothing advances without a person’s input.

When to Use It

Reach for the Turn-Based Loop for short, one-off tasks where control matters and supervision is cheap relative to the risk of an unsupervised mistake. The main cost lever is the number of turns: a vague prompt buys extra turns as the model feels its way toward what you meant, so specific prompts and verification skills that let a turn check its own work before returning both cut the turn count and the spend. See Volume 01’s Human-in-the-Loop Checkpoint for the supervisory pattern this rung rests on, Volume 18’s plan mode for a way to review intent before any turn acts, and Volume 07 for the broader turn-based collaboration surface.

Sources

Volume 01 (Patterns of AI Agent Workflows), Human-in-the-Loop Checkpoint.
Volume 18 (Claude Code Configuration & Workflows), plan mode.
Volume 07 (The Human-in-the-Loop Catalog).

Example artifacts

A developer asks Claude to fix a single failing function. Claude reads the function, proposes an edit, and returns it; the developer approves, and Claude runs the test to confirm the fix. Each turn is small, visible, and gated by a human “go” --- the run advances one approved step at a time and ends when the developer is satisfied.

Goal-Gated Loop

Classification Invocation type (an evaluator holds the stop decision).

Intent

Hand the stop decision off from the human to an evaluator. Each time the agent tries to stop, an evaluator checks the run against a stated condition; if the condition is unmet, it sends the agent back to work; if it is met, the run ends. The human states the goal once and steps away from the per-turn approval.

Motivating Problem

Some tasks have a checkable definition of done that a human should not have to sit and babysit. “All tests pass.” “Lighthouse score at or above ninety.” “The lint report is empty.” These conditions are objective and mechanically verifiable, yet under a turn-based loop a person still has to watch each turn and judge whether the bar has been cleared. When the criterion can be evaluated without human judgment, the supervision is busywork --- and busywork the human will eventually stop doing carefully.

How It Works

The goal is expressed as a deterministic criterion: a test count that must reach green, a numeric score that must cross a threshold, an empty lint or type-check report. At every point where the agent would otherwise stop, the criterion is evaluated. If it holds, the run ends; if not, the failing state becomes the next prompt and the loop fires again. Because an evaluator that only stops on success can loop indefinitely against an unreachable goal, a turn cap is a required safety valve --- “stop after five tries” --- so the run terminates on either success or exhaustion, whichever comes first.

When to Use It

Use the Goal-Gated Loop when the definition of done is deterministic and the run is long enough that watching every turn is wasteful. It is the invocation-side twin of Volume 01’s Goal Setting and Monitoring pattern: where that pattern describes the supervisory loop from the inside, this rung describes handing the stop decision to it. It also draws on Volume 01’s Evaluator—Optimizer pattern and its account of autonomous-agent stop conditions. Keep the turn cap explicit; an evaluator without a ceiling is a way to spend a token budget on an impossible goal.

Sources

Volume 01 (Patterns of AI Agent Workflows), Goal Setting and Monitoring.
Volume 01, Evaluator—Optimizer and autonomous-agent stop conditions.

Example artifacts

A developer runs, in effect, “get Lighthouse to ninety or above, stop after five tries.” The agent makes a change, re-runs the audit, reads the score, and either stops because the bar is cleared or loops with the new numbers in hand --- up to five attempts. Running the same goal with no arguments reports the current turn count and token usage, so the human can see how much of the budget the pursuit has spent without approving a single turn.

Interval Loop

Classification Invocation type (the clock holds the stop decision, locally).

Intent

Re-run a prompt on a fixed local interval so the agent reacts to an external system that changes on its own. The clock, not a human and not an evaluator, invokes each iteration; the run continues as long as the local session is alive.

Motivating Problem

Some state you care about changes between runs with no signal you can subscribe to. A pull request accumulates review comments over the afternoon; a CI pipeline goes red sometime after you pushed. There is no webhook you have wired up and no push notification you can hang a trigger on --- the world simply drifts, and you would otherwise have to remember to check. Polling on a timer is the honest answer when there is no push signal to react to.

How It Works

A local runner re-fires the same prompt every N minutes. Each firing is a fresh run of the loop against the current state of the watched thing. Crucially, the runner lives in your local session --- it runs on your machine, and when you close the laptop it stops. There is no durable service keeping it alive. The one tuning knob that matters is the interval: match it to how often the watched thing actually changes, so you are not paying for runs that find nothing new nor missing changes because you polled too slowly.

When to Use It

Use the Interval Loop for local, session-bound polling of an external system that has no push signal. It is deliberately distinct from the next rung, the Proactive / Scheduled Loop: the Interval Loop is tied to your session and dies with it, whereas cloud cron persists with no session at all. If you need the watch to survive a closed laptop, you want the scheduled loop, not this one. For the trigger machinery underneath --- the temporal sources and schedule triggers that fire on time rather than on an external event --- see Volume 04.

Sources

Volume 04 (Events & Triggers), temporal sources and schedule triggers.

Example artifacts

While a pull request is in review, the developer sets a local runner to fire every five minutes: check my PR, address any new review comments, and fix failing CI. For the afternoon, with the laptop open, the agent keeps the branch current; when the developer closes the laptop, the watch simply ends.

Proactive / Scheduled Loop

Classification Invocation type (the cloud holds the stop decision; no human in real time).

Intent

Move the routine off your machine and into the cloud, where it persists without your session. A schedule or an external event invokes each run; the routine executes whether or not you are at your desk, and no human is present in real time to end it.

Motivating Problem

Some work is a recurring stream of routine tasks that should run regardless of your presence: triaging incoming bug reports, applying migrations, taking dependency upgrades. Tying that stream to a local session is fragile --- it stops the moment you close the laptop, and it competes with your interactive work for the same machine. Work that recurs on its own schedule wants an executor that recurs on its own too.

How It Works

The routine is cloud-persisted and durable: a schedule or an event triggers it, it runs to completion on infrastructure that outlives your session, and there is no human in the loop while it runs. Because these runs are unattended and recurring, the model choice matters more here than anywhere else on the ladder. Route the routine work to smaller, faster, cheaper models and reserve the most capable model for the genuine judgment calls. This model-tier routing --- matching the model to the difficulty of the turn rather than running everything on the flagship --- is a lever the rest of the series barely touches, and it belongs squarely on this rung, where the volume of unattended runs makes the per-run model cost the dominant term.

When to Use It

Use the Proactive / Scheduled Loop for recurring, unattended streams of routine work that should run on their own cadence. For the underlying schedule and cron triggers, and the durable-execution machinery that makes a long-running routine survive crashes and deploys, see Volume 04 (particularly its chapter on durable execution). For the products that package background and delegated execution as a hosted surface, see Volume 14.

Sources

Volume 04 (Events & Triggers), schedule/cron triggers and durable execution.
Volume 14 (The AI Agent Products Survey), background and delegated products.

Example artifacts

A team schedules an agent to run every hour and check the #project-feedback channel for new bug reports, opening a triaged issue for each. It runs on cloud infrastructure through the night and the weekend; no one has to keep a session open, and the routine tier of the work runs on a smaller model while anything needing real judgment is escalated.

Loop Composition

Classification Invocation type (stacking the primitives for long-running work).

Intent

Build long-running autonomy by composing the four primitives rather than choosing one. A schedule to wake the run, a goal to know when to stop, parallelism to explore, and standing permission to proceed unattended combine into a single durable operation that no one rung could deliver alone.

Motivating Problem

Real long-running work needs more than one rung at once. A schedule alone wakes the agent but cannot tell it when to stop; a goal alone knows when to stop but never wakes on its own; neither explores alternatives, and neither runs without someone granting permission at each step. An operation that is supposed to run overnight and be finished by morning has to answer all of those needs together --- when to wake, when to stop, how to explore, and how to proceed without asking.

How It Works

The primitives stack. A worked example: schedule the run to fire every hour (the Proactive / Scheduled Loop supplies the wake); gate it on a goal --- “don’t stop until every report is triaged, actioned, and answered” --- so an evaluator holds the stop decision (the Goal-Gated Loop supplies the ending); let it explore, spinning up N candidate fixes in parallel worktrees judged against each other by an adversarial evaluator (dynamic parallelism supplies the exploration); and run it in an auto mode that grants standing permission so it proceeds without pausing for approval (removing the per-turn human gate). Each rung contributes the one thing the others cannot, and together they make an operation that wakes itself, knows when it is done, explores before it commits, and never waits on a human.

When to Use It

Use composition for durable autonomous operations --- work that must run unattended for hours, wake on its own, and finish against a real definition of done. This is the invocation-side counterpart to Volume 01’s Appendix A on pattern composition, where a Goal Monitor is layered over an Autonomous Agent; here the same layering is expressed in terms of who wakes the loop and who ends it. For the parallel-worktree orchestration that supplies the exploration rung, see Volume 04’s treatment of Composio and worktree-based fan-out.

Sources

Volume 01 (Patterns of AI Agent Workflows), Appendix A, Pattern Composition (Goal Monitor over an Autonomous Agent).
Volume 04 (Events & Triggers), Composio parallel-worktree orchestration.

Example artifacts

The composed feedback-triage agent: scheduled hourly, gated on the goal that every report be triaged, actioned, and answered, exploring candidate fixes in parallel worktrees with an adversarial judge, and running in auto mode so it never pauses for permission. Set running in the evening, it works the queue through the night and presents a finished result --- and its turn and token counts --- in the morning.

Chapter 3. Cost & Quality

The four rungs share a small set of levers for keeping an autonomous loop both cheap and good, and each lever matters more the higher up the ladder you go, because the higher rungs run more often with less supervision.

The first lever is to keep deterministic work out of the reasoning loop. Anything with a fixed, mechanical procedure belongs in a script that the agent runs, not in tokens the model spends re-deriving the procedure every turn. A form that always fills the same way is cheaper as a small script the agent invokes than as a reasoning task repeated on every run; the model’s judgment is the expensive resource, and spending it on work a function could do is the most common avoidable cost.

The second lever is the interval. On the Interval and Scheduled loops, the polling cadence is a direct multiplier on spend: match it to how often the watched thing actually changes. A five-minute poll on state that turns over twice a day is paying for hundreds of empty runs; a daily poll on state that changes hourly misses most of what it was meant to catch. The cadence is a cost knob and a quality knob at once.

The third lever is model-tier routing, which comes into its own on the Proactive / Scheduled Loop. When a routine runs unattended and often, the per-run model cost dominates, so route the routine turns to smaller and faster models and reserve the capable model for the judgment calls. Running everything on the flagship model is the easy default and the expensive one.

The fourth lever is observability, without which the other three are guesswork. Usage reporting breaks spend down by the skills, subagents, and MCP tools a run invokes, which is what tells you where the tokens are actually going and which piece to move into a script or a cheaper model. The workflows view shows per-agent token usage in flight and lets you stop any agent that is running away, which is the backstop when a goal turns out to be unreachable or an interval was set too tight. Watch the run before you trust it unattended.

Chapter 4. Getting Started

The ladder is an adoption path, not a menu. You do not survey the four rungs and pick your favorite; you start where you are and climb one rung at a time as each hand-off earns your trust.

Begin with a single task where you are the bottleneck --- something you do by hand, repeatedly, that gates other work. Then ask which one piece of it you could hand off first. Usually it is one of three: the verification check that tells you the work is done, the goal definition that states the bar objectively, or the schedule that says when the work should happen. Hand off exactly that one piece and no more --- move a turn-based task to a goal the first time the definition of done is checkable, move a goal you keep re-running by hand to an interval, move an interval you keep alive by leaving the laptop open to a schedule.

Then run it and watch. Watch where it stalls --- a goal it cannot reach, an interval that finds nothing --- and where it over-reaches, taking actions you would not have approved. Each stall and each over-reach is a note on how to shape the harness: a tighter goal, a turn cap, a narrower prompt, standing permission granted only where it has earned it. Iterate the harness rather than the model. Climb the ladder as the hand-offs prove themselves, and stop climbing when the rung you are on does the job; the goal is not maximum autonomy but the least supervision the task can safely take.