A courts clerk's office runs an autonomous agent that reconciles case records against a docket system. During testing the agent occasionally enters a loop, repeatedly re-querying and re-checking without converging. Which control most directly bounds this behavior?

Controls that depend on the model noticing its own failure are the wrong class of control for non-convergence, because failing to notice is the failure. A court clerk's reconciliation agent stuck re-querying the docket needs a bound imposed from outside its own reasoning.

A hard cap on turns and on total tokens is structural. Bounding turns guarantees the run terminates whether or not the agent converges, bounding tokens guarantees the cost of not converging is finite, and hitting either limit is an observable signal that routes the case to human review. For records reconciliation in a court setting, a run that halts and reports incomplete is strictly better than one that spends unbounded budget.

Lowering temperature changes token sampling, not the agent's decision to keep taking actions, and a deterministic loop repeats just as reliably at low temperature; reducing max_tokens shortens each response while leaving the number of turns unbounded, so the loop simply runs cheaper per iteration and no less long; a PostToolUse warning about repeated calls is advisory, and while it may help the model break the pattern in ordinary cases it guarantees nothing about termination.

Exam caveat: a cap guarantees an exit but does not distinguish a loop from a job that is legitimately long, so set the limit against observed successful runs. Operational check: run the reconciliation with the cap in place, induce a loop, and confirm the run terminates at the limit and surfaces an incomplete status to the operator rather than failing silently.