How are you guys stopping agents from silent loops/stampedes? Standard step_counters feel like garbage

OSS Product Help LangGraph
, ,
1

I’ve been looking at multi-agent failure states, and it seems like everyone is relying on basic Python step_counters or LLM prompt-engineering (“do not repeat yourself”) to prevent agents from falling into infinite tool-calling loops or stampeding APIs.

Coming from a low-level systems/C++ background, handling loop-prevention at the application layer feels insane. It adds latency, and when a timeout triggers, it just leaves the state half-executed.

Has anyone tried intercepting tool calls deterministically via a dedicated proxy or trajectory ledger? E.g., a lightweight interceptor that hard-kills the process the exact microsecond an identical state or argument repeats?

Curious what the actual production solution is, or if everyone is just accepting the latency and hoping the prompt holds?

2

Deterministic interception is the right instinct, but hard-killing on the first repeat recreates the half-executed state you’re trying to avoid. Gate before execution with an idempotency-keyed dedup ledger, then return either the cached result or a structured refusal as the tool observation.

Add orchestrator-side budgets or tick caps, and the loop dies by starvation while state stays intact. Identical calls aren’t automatically bugs either, since retries, polling, and pagination can all repeat legitimately.

We hit this building MeshKore and put the gate before subagent dispatch, returning a structured refusal instead of killing in-flight work. So yes, move this outside the model, just don’t make process termination the primitive.