“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 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 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 decided over evidence — the artifact, the iteration log, the satisfied promise — not over 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
…