Interactive engineering lab

Stuck agent loops: step budgets versus call and progress detectors

Stuck agent loops: step budgets versus call and progress detectors. Count loops caught, steps wasted and working runs stopped early.

By Sandeep Belgavi · Published 2026-11-01

Synthetic fixtures; deterministic local model. No production system is contacted.

Experiment inputs

Complete-run results

Decision trace

    What this experiment demonstrates

    A returns agent at Belgavi's Book Store makes one tool call per step. The lab generates forty synthetic runs with a fixed seed. About half are healthy: they make progress every few steps and finish within 15 steps. Some poll a job status 3 to 9 times with identical arguments and results, then finish. Twelve are stuck: an exact repeat of one call, an A-B oscillation between two calls, or a paraphrase loop whose arguments change every step while the result does not. Stuck runs never finish on their own.

    The model is a deterministic simulation of fingerprints and counters. It does not call a model or any tool.

    Run controlled comparisons

    Start with the defaults: only a step budget of 30. All 12 loops run to the budget and 319 steps are spent inside loops.

    Now change one thing at a time. Stop on the same tool and arguments 3 times in 8 steps: 10 loops are caught and 95 loop steps remain, because the 2 paraphrase loops change their arguments. Stop on the same call or the same result without progress: all 12 are caught after about 4 loop steps each, 48 in total. Untick the polling allow-list with that detector: 7 working runs are stopped while they poll. Stop after 8 steps without progress instead: all loops are caught, later, with 91 loop steps. Lower the step budget to 10 with no detector: 18 working runs are cut off.

    Inspect the trace and keep evidence

    The table lists up to ten runs, problems first: the run, its shape, the steps it took, what ended it and how many steps it spent inside a loop. Start trace, Next step, Show all and the slider control how much of the decision trace is visible; the metrics always describe the whole run. Reset restores the defaults and Export JSON downloads the inputs, metrics and trace.

    Limits and production translation

    Real runs have noisier results, timestamps that defeat naive fingerprints, and tasks where progress is hard to define. The model knows exactly which steps made progress and which tool polls. What carries over: a step budget catches every loop but late, argument fingerprints miss paraphrase loops, result and progress signals catch them, and polling tools need an exemption with their own bound or they look like loops.

    Views are my own and do not represent any employer, past or present.