Session context: The 2026-04-27 Trello Agents session was a live design walkthrough of a 6-agent PRD pipeline. The review-bounce loop emerged as a critical design moment — and the termination condition question surfaced as the non-obvious first-class requirement it actually is.
Core Idea
An autonomous loop without a termination condition is not a feature — it’s a bug waiting to compound. The loop runs. Output feeds into the next step. If quality doesn’t clear, the loop bounces back. Without a defined stop condition, the loop spins until something fails catastrophically: infinite recursion, compounding errors that drift further from the target on each pass, or silent runaway compute.
The fix sounds obvious in retrospect: design the termination condition first. Before you write the loop, define what “done” means. This forces clarity on the success criterion before the execution machinery exists — and it’s exactly the same discipline that makes tests-first programming work.
Three termination types, all of which real loops should carry as fallbacks:
- Quality threshold — output scores ≥ N on the rubric. The happy path. The loop exits when the work is good enough.
- Iteration counter — max N attempts. The guardrail. If quality doesn’t clear in N passes, surface for human review rather than continuing to burn compute on a failing approach.
- External state — a card moves to the Done column, a flag is set in the structured object, an external signal fires. The escape hatch for loops that can’t self-assess.
In the Trello pipeline, the review agent wrote an iteration count into the card metadata. If the count hit the cap without clearing quality, the card moved to a human review lane instead of bouncing back. That metadata field — humble as it is — was load-bearing. Without it, the loop had no exit.
Practical Application
Before building any autonomous loop, answer these three questions in writing:
- What does success look like? (Define the rubric. The quality gate agent needs to evaluate against something specific, not “is this good?”)
- How many passes is enough? (Set the counter. 3 is a reasonable default. Fewer for simple tasks; more for complex iterative refinement.)
- What happens when neither condition fires? (Define the fallback. Usually: escalate to human, write an error state to the structured object, stop the loop.)
Write these answers before you write the agent prompt. A loop whose termination conditions aren’t designed is an agent whose completion criteria aren’t known — and you can’t build a quality gate for criteria you haven’t specified.
Evolution Across Sessions
The Quality Gate Pattern insight established that self-evaluation should live at every handoff. This insight goes upstream: the termination condition must be designed before the pipeline, not discovered through it. The gate is only as useful as the exit logic attached to it. Termination conditions are the accountability layer that makes autonomous loops safe to run without supervision.