Configure

Configure is the middle commitment layer: change how a Loop runs without forking it. It opens as a sheet over the detail view and writes a per-Loop config overlay — the Loop's structure is untouched.

What you can tune

The sheet has four groups, all scoped to the checks and limits the Loop already declares:

• Verification checks — enable or disable each declared check, and for a generic command check, set the project command it runs (a test suite, a linter). Disabling a command check disables its command field. A gate that judges (an agent-judge acceptance review) cannot be removed here — that is structure.
• Human approval gate — a single switch to require, or drop, a human approval before the Loop finishes.
• Re-attempt strategy — failed-only (the default; retry only what failed) or full-body (re-run the whole body). This is where re-attempt granularity is chosen, not on the run form.
• Model defaults — the worker model used by run-agent actions that omit params.model, and the judge model used by agent-judge criteria that omit model. Empty values leave provider defaults in control.
• Stop limits — the same six numeric limits as the run form's Advanced panel, each clamped at its daemon ceiling. Configure sets the per-Loop default; the run form can still override per run.

Reset to defaults restores the definition defaults and failed-only. Save persists the overlay.

What needs a fork

Configure never changes structure. These belong to the visual editor or a definition edit:

• node order or DAG structure;
• node kinds;
• input declarations;
• the contract's terminal states or shape;
• the goal or definition-of-done.

How it stores and merges

Configure writes a separate per-Loop config store keyed (workspace_id, loop_name) — distinct from the definition, which stays filesystem-as-truth. It is read and written through GET/PUT /loops/:name/config, agh loop configure, and agh__loop_configure.

The effective config a run actually uses is a four-layer merge, each layer bounded by the compile-time ceilings:

1. the definition's own defaults,
2. [loops.defaults.*] in config.toml,
3. this per-Loop configure overlay,
4. any per-run overrides from the run form.

GET /loops/:name/config returns the stored per-Loop override as config and the daemon-resolved first three layers as effective_config. A missing override is config: null; it is not a missing Loop and does not prevent clients from reading the effective values.

Loop run-agent workers use the Loop action runtime. They do not read [[tasks.run.task_runtime_rules]]; that table remains scoped to normal task worker profile routing. The Loop runtime resolves the model into the ACP session bind request, then the provider adapter decides what an empty model means.

From an agent

Configure is fully agent-manageable — the same overlay, written structurally:

See the agh loop CLI and the Loops API.