agentforce.cloud
VOL 19

The Agentic Loop & Autonomy Catalog

Volume 19 of the Agentic AI Series

Patterns
6
Updated
2026-10
Cluster
I

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, five loop-invocation types fall out --- turn-based, goal-gated, interval, local scheduled, and proactive/scheduled --- and they line up as a ladder. Control of the stop decision climbs from the human, to an evaluator model, to a clock inside your session, to a scheduler on your machine, to the cloud. Each rung inherits the loop mechanics of the ones below it and changes only who ends the run. The five rungs plus their composition are the subject of this catalog.

Scope

Coverage:

  • The five 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, inside your session), the Local Scheduled Loop (a scheduler on your machine holds it, with no session open), and the Proactive / Scheduled Loop (the cloud holds it, with no human in real time).
  • Loop Composition --- how the five primitives stack to build durable, long-running autonomy.
  • The autonomy-axis framing that orders the five 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 five 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 an interval inside your session; to a local scheduler, which starts fresh runs on your machine with no session open; 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 scheduler on your own machine, then to a durable cloud 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 Five Loop Types

Pattern · 1 of 6

Turn-Based Loop

Pattern page →

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.

Pattern · 2 of 6

Goal-Gated Loop

Pattern page →

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. This rung is how Volume 01’s Goal Setting and Monitoring pattern gets the stop decision: that pattern defines and tracks the objective, this one acts on it.

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 a condition the evaluator can confirm from evidence in the run: a test result the agent printed, a score it reported, an empty lint report it showed. Each time the agent would otherwise stop, the evaluator checks the condition. If it holds, the run ends; if not, the evaluator’s reason becomes guidance for the next turn and the loop fires again. In Claude Code, /goal works this way: it installs a session-scoped prompt-based Stop hook, and after each turn a small fast model reads the conversation and returns met, not yet met, or impossible. That evaluator runs no commands and reads no files, so it judges only what the agent has surfaced. For a strictly deterministic gate, use a Stop hook that runs the check as a script. Because an evaluator that only stops on success can loop against an unreachable goal, write a turn cap into the condition (“or stop after five tries”); the evaluator judges that clause from the conversation, so it is a written limit, not a hard counter. The run ends on success, on the turn-cap clause, or when the evaluator judges the goal impossible. Claude Code also ends a goal on an error the user has to fix, and pauses it when the agent makes no tool calls for several turns in a row.

When to Use It

Use the Goal-Gated Loop when the definition of done is checkable 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

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.

Pattern · 3 of 6

Interval Loop

Pattern page →

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. Where the watched system can push events or be streamed, prefer that: in Claude Code, Channels let CI push a failure into the running session, and the Monitor tool streams a background script’s output line by line, both cheaper than re-running a prompt on a timer.

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 the session exits or you close the laptop, it stops. In Claude Code, /loop works this way, with a one-minute minimum; backgrounding the session carries the loop into a background session that runs without a terminal, but the process still has to stay alive. Recurring /loop tasks also expire seven days after creation, which bounds a forgotten loop. Omit the interval and Claude picks each delay itself, between one minute and one hour, and can end the loop when the work is done. 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 two scheduled rungs above it: the Interval Loop is tied to your session and dies with it. If the watch should outlive the session but still needs your local files, use the Local Scheduled Loop; if it must survive a closed laptop, use the Proactive / Scheduled Loop. 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

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.

Pattern · 4 of 6

Local Scheduled Loop

Pattern page →

Classification Invocation type (a scheduler on your machine holds the stop decision; no session open).

Intent

Run a prompt on a schedule from a scheduler on your own machine, so the routine outlives any one session while keeping direct access to your local files and tools. Each firing starts a fresh session; no terminal has to stay open, but the machine has to be on.

Motivating Problem

The Interval Loop dies with its session, and the cloud rung runs against a fresh clone with only the connectors you configure. Some recurring work sits between the two: a morning review of the repository you are actively working in, a dependency check that needs local tools, a briefing that reads files that never leave the laptop. Keeping a session open all day to host a timer is fragile, and moving the job to the cloud loses the local state it exists to read.

How It Works

A local scheduler, not a running session, holds the schedule. In Claude Code this is a Desktop scheduled task: the Desktop app starts a new session at the time and frequency you choose, with the folder, permission mode, and model you picked for the task. Runs use the working directory as it is, uncommitted changes included, unless you give each run its own Git worktree. The task fires only while the app is open and the computer is awake. When the app starts or the machine wakes, Desktop runs one catch-up for the most recent run missed in the last seven days and drops the older ones. Each run stops when the session finishes its prompt; the scheduler decides only when the next one starts.

When to Use It

Use the Local Scheduled Loop for recurring work that needs local files or tools and should not depend on an open session. If the work must run while the machine is off, or should start on API calls or GitHub events, move it up to the Proactive / Scheduled Loop. If it only needs to run for an afternoon while you work, the Interval Loop is simpler. Plan for the catch-up rule: a daily task that missed six days runs once on wake, not six times.

Sources

Example artifacts

A developer sets up a Desktop task to run every weekday at 9am in the project folder: review yesterday’s changes, run the local test suite, and write a short report. It runs in its own worktree so it does not touch the branch in progress. On a morning the laptop stays shut until 10, Desktop runs the missed review once when it wakes.

Pattern · 5 of 6

Proactive / Scheduled Loop

Pattern page →

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. In Claude Code these are cloud scheduled tasks (formerly routines, in research preview): a schedule, an API call, or a GitHub event triggers them, the shortest schedule is one hour, and they run as full cloud sessions with no permission prompts. Each task has its own saved model, used on every run. 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.
  • Claude Code docs, Automate work with scheduled tasks: https://code.claude.com/docs/en/routines

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.

Pattern · 6 of 6

Loop Composition

Pattern page →

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

Intent

Build long-running autonomy by composing the primitives rather than choosing one. A schedule to wake the run, a goal to know when to stop, parallelism to explore, and 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 without a per-action approval gate: cloud scheduled tasks already run without permission prompts, and in a local session auto mode has a classifier model approve routine actions so the run does not pause for each one, while still blocking actions that go beyond the request. 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 Orchestrator.inc (formerly Composio Agent Orchestrator) and worktree-based fan-out.

Sources

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 as a cloud scheduled task, so it never pauses for a permission prompt. 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 five 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 both 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 five 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 session open to a local schedule, and a local schedule you keep alive by leaving the machine on to a cloud 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.

Search the catalog