“Let the agent run until it’s done.” Tempting — and rightly so: a lot of work has the nature of iterating toward “done” rather than a single pass. But without governance, a loop is the fastest route to an endless run, a burned budget, or an agent that defines “done” for itself.
This case study describes how we deployed loops in practice, what exactly a loop must have contracted up front — and how operational experience became a formal amendment to the methodology.
What a loop means to us
A loop is an execution mode (execution_mode: loop) in which an agent iterates over the same
intent until it meets the completion promise, exhausts its budget, or starts
stagnating. It is not “the agent just keeps running” — it is a unit of
delegated work with four mandatory elements:
completion_promise— a binary, machine-testable promise. “All 17 tests green”: yes. “Significantly improve quality”: no. What cannot be tested cannot be entrusted to a loop.max_iterationsand a budget — hard caps (iterations, tokens, time). “Infinity” is not a value; exceeding a cap means stop and escalate, never a silent continuation.- An independent evaluator — promise fulfilment is never judged by whoever did the work. Executors systematically overrate their own work; that is not a character flaw, it is statistics.
- A trace of every iteration — the loop emits an event into the audit record. Stagnation (N iterations without progress) automatically leads to a Suspend and a Drift Signal.
Human control does not move into every iteration — it moves to the the Crystallization of the intent before the start and to the Validation Gate after the promise is met. In between, the human stays out of the way.
A live run
In July 2026 we verified the mode end to end on a live development server: an agent received an intent with a machine-checkable completion promise, iterated inside a controlled loop, met the promise in the first iteration, and wrote every step into the governance record. The gate ruled on evidence — the artefact, the iteration log, the satisfied promise — not on storytelling.
Just as valuable was what the run revealed around itself: the infrastructure dependencies a loop needs (a live working environment with the right identity), and the necessity of cleaning up after headless runs — these too are governance lessons, not details.
What did not work
- Early attempts showed the classic failure mode: a promise phrased so it could not be machine-evaluated. The remedy was not “trying harder” but a rule: an untestable promise = the intent cannot be approved for launch.
- It became clear that the evaluator must be mandatory from medium risk levels upward — for trivial loops calibration is enough, for anything more serious an independent judgement is a necessity.
From practice into the methodology
The operational experience with loops crystallized into a formal amendment to the methodology (v0.95): the loop as a recognized execution mode with a mandatory runtime contract, protection of acceptance criteria against modification by the executor (the cheapest path to a green test is deleting the test — which is why that is forbidden and audited), and a machine pre-gate that filters the formalities away from the human Curator while leaving the decision with them.
That is GALDUR in a nutshell: the methodology changes through amendments grounded in practice, not through proclamations.
What to take away
- A loop without a machine-testable promise is not autonomy — it is a gamble.
- Budgets and caps are not distrust of the agent; they are the conditions under which trust can be extended at all.
- Independent evaluation is not bureaucracy; it is the only defence against executor self-assessment.
- Human control belongs at the beginning (Crystallization) and the end (the gate) — not in every turn of the loop.
This case study is one of the conditions GALDUR set for itself for version v1.0 (“at least 3 case studies”). The methodology is open — documentation, templates, community.
Comments
…