Loops

A Loop is a named, reusable definition of goal-seeking, self-correcting, bounded work that the daemon owns, runs unattended, and always ends with one named outcome. It is the runtime's answer to "run this until it is actually done, and tell me honestly how it ended."

A Loop is not a script and not a chat session. What makes it a Loop is a contract — a goal, a way to verify the goal is met, and the conditions under which it stops — carried by every Loop, even one that finishes on its first pass.

The contract: goal → verify → stop

Every Loop answers four questions, and the daemon holds it to all four:

• What is the goal? The definition-of-done.
• How do we verify it? A verification gate — a project command, an agent judging against a rubric, or a human approval. Verification is project-agnostic.
• When does it stop? Structural stop limits: an attempt cap, a no-progress window, optional budgets, and a breadth ceiling.
• How does it end? Exactly one of six named terminal outcomes.

Iteration is simply what happens when verification says "not done." A single-pass linear body is still a Loop — one that finished on its first pass — and it still gains the contract, which is the value no plain task graph delivers.

Two nouns, nothing else

The workspace surfaces exactly two things under one Loops umbrella:

• Loops — the catalog of definitions, each with declared inputs, a goal, and last-run state.
• Runs — the executions, active and past, observed on the run page.

There is no third noun. Running a Loop means supplying its declared inputs, which produces a Run. There is no separate "work to run," no standing work-list to browse, and no "ready" state to manage.

A Loop is made of three parts

1. A contract — goal, verification, stop conditions, and the fixed set of named terminal outcomes.
2. A body — a static DAG of typed nodes the daemon runs to completion. Node classes are action, control, and source. The body's shape varies per Loop; not every Loop has tasks.
3. Typed declared inputs — the parameters a caller supplies to run it (string, number, boolean, file, agent, or ref).

The full data model lives in the DSL reference.

Loop vs. capability

A Loop and a capability are different artifacts, and Loops do not replace capabilities:

• A Loop is a deterministic runtime program the daemon owns and runs. It rides AGH's existing durable foundations — the work queue, sessions, automation, network, and memory — rather than adding a second execution engine.
• A capability is an interpretive network artifact — what an agent offers to peers over AGH Network. Capabilities stay interpretive; the network protocol does not carry Loop execution.

AGH Network remains, by design, not a workflow engine: envelopes do not carry loop execution. The Loop domain lives entirely in the runtime.

Arrive and use

The common path never touches a graph. Two first-party Loops come installed through the default-enrolled dev-cycle extension and run directly — supply a couple of inputs and go:

• software-delivery — executes already-authored tasks in dependency order, reviews results (agent-judge or human approval), remediates failures, and verifies against the project's own checks.
• reviews-watch — watches an open change; each time new review comments land, it fetches and remediates them, repeating until nothing is unresolved. CodeRabbit-backed runs require gh to be installed and authenticated.

If you disable dev-cycle, those Loops, their default agents, their provider tools, and the coderabbit_pr_review watch source leave the catalog together; enabling it restores the package.

Authoring, configuring, and forking are an opt-in power ceiling, never the entry toll.

Three ways to commit

In this section

Manage from any surface

Every Loop capability — author, configure, run, observe, approve, stop — is operable by an agent through structured non-UI surfaces. The agh loop CLI, the Loops HTTP API, and the agh__loop_* native tools all reach the same validators and writers as the web UI. Web-UI-only control would be incomplete by definition.