Learn · intro

What is an AI loop?

The 30-second and the five-minute answer to what an AI loop is, and why the loop — not the model call — is the unit of value.

An AI loop is a control loop around a model: trigger → context → act → verify → escalate. A model call is a part; a loop is the working system — with state, permissions, stop conditions, and someone (or something) checking the result. This module is the conceptual front door to the rest of /learn. It assumes you can read code but have not yet shipped a loop you would trust unattended.

For agents: - A loop is the eight-step control cycle: trigger, context assembly, plan, act, observe, evaluate, reflect, repeat/stop/escalate. - Treat a single model call as a component, never the deliverable. - On this site, loops are declared as loop.yaml manifests validated against /spec. - The catalog of installable templates is /registry/index.json. - Before running a loop, confirm it declares stop conditions and a verifier that is not the producing agent.

The 30-second version

A loop is trigger → context → act → verify → escalate. Something starts it (a schedule, a webhook, a user goal, a CI failure). It gathers context, takes an action through tools, observes the result, evaluates whether the result is good, and then repeats, stops, or escalates to a human.

The single most useful reframe is that the loop — not the model call — is the unit of value. A raw model call is a component; a loop is the working system that keeps prompting, checking, and improving (docs/research/loop-landscape.md#executive-summary).

The eight steps in full

Across papers, products, and coding-agent practice, the same structure appears (docs/research/loop-landscape.md#1-1-the-common-shape):

  1. Trigger — user request, cron schedule, webhook, CI failure, new issue, stale content check, feed update.
  2. Context assembly — load docs, repo state, memory, tickets, web sources, APIs.
  3. Plan / decide — pick the next action or subtask.
  4. Act — call tools, edit files, open PRs, query APIs, run commands.
  5. Observe — capture command output, test results, web data, reviewer comments, errors.
  6. Evaluate / verify — compare output to explicit success criteria.
  7. Reflect / record state — write lessons, failures, next actions, or memory.
  8. Repeat, stop, or escalate — continue until done, blocked, unsafe, over budget, or timed out.

Walk one concrete example through all eight. Loopmaster's own link-audit loop fires on a daily schedule (step 1), reads the site's content directory and a snapshot of last run's links (step 2), decides which links to fetch (step 3), fetches them (step 4), records which returned 4xx/5xx or changed meaningfully (step 5), compares the broken set against the previous state file to dedupe (step 6), writes the diff to .loopmaster/state/ and a findings report (step 7), then either posts a self-contained repair task or stops — it never edits public docs without a human approving (steps 8). That last clause is the difference between "it ran" and "it ran safely," and it is the subject of module 5.

Workflow vs agent

Anthropic's distinction is useful here (docs/research/loop-landscape.md#1-2-workflow-vs-agent; anthropic-building-effective-agents):

  • Workflows orchestrate LLMs and tools through predefined code paths.
  • Agents let the model dynamically direct its own process and tool usage.

Most production systems blend both: a deterministic outer workflow gives boundaries, while inner agent steps adapt to the situation. Purity is not a goal. The deterministic outer loop is what makes the adaptive inner steps safe to run unattended — it is where stop conditions, budgets, and gates live.

Why loops need more than prompts

The practitioner frontier has moved from "write a better prompt" to "design the system that keeps prompting, checking, and improving" (docs/research/loop-landscape.md#1-3-why-loops-matter-now). A useful loop is less about clever prompting and more about:

  • state — durable memory of what was tried, what passed, what failed, what needs a human;
  • tool access — a bounded, declared set of actions, not an open shell;
  • isolated execution — a workspace the loop can mutate without collateral damage;
  • observability — every run emits what changed and why;
  • verification — an independent check that the result is actually good;
  • safety gates — explicit conditions that stop for a human;
  • maintenance cadence — a schedule for re-checking the loop itself as the world drifts.

These seven parts are the spine of the rest of this curriculum. Module 3 walks each to its loop.yaml field; module 4 deepens verification; module 5 deepens the gates. Addy Osmani calls the meta-practice of designing this whole system "loop engineering" (osmani-loop-engineering); the ReAct paper names the reason-then-act shape that step 3–5 follows (react-paper).

Where to go next

Further reading