dsh-loop-guard

The most insidious waste in a multi-agent workflow is rarely a single failed call; it is the same tool call executed over and over, returning the exact same result each time. The agent spins in place, burning steps and tokens without producing any new information. dsh-loop-guard targets precisely this kind of stuck loop: the one that looks like progress but is, in fact, pure idle repetition.

The core design decision is result awareness. A repeat only counts when the tool name, canonically key-sorted arguments, and result content are all identical. That means polling a job whose status is advancing, re-reading a file after an edit, or retrying a flaky command that eventually behaves differently will never trigger the guard. Legitimate repeats are whitelisted for free, with no tool-name configuration required. On top of this foundation the guard works in two stages: the soft stage (default threshold of 4 consecutive identical calls) injects a plugin-sourced notice after the tool result, telling the model that its calls are identical, that the next one will be denied at the hard threshold, and that it should act on what it already knows. The hard stage (default threshold of 8) is a monotonic tool guard that denies the next identical call and returns corrective feedback; the chain stays frozen while denials repeat, so the guard remains engaged until the model changes its action.

dsh-loop-guard is complementary to, not a replacement for, the official repeat-tool-reminder in the base bundle. The reminder fires on argument-identical repeats and is advisory only by design; this plugin additionally requires result identity and is the only one of the two that can actually terminate a loop. Running both together is recommended: the reminder nudges early, and the guard enforces when the loop is provably sterile. This plugin is a good fit for developers running multi-agent pipelines, multi-harness LLM gateways, or any workflow where an agent can get into the no-error, no-progress spiral.