Workflow Loop Detection and Circuit Breaking in LLM Agents

Workflow loops in an LLM agent fail at the reasoning layer, not the infrastructure. The agent re-plans and retries inside its own cognition, so every circuit breaker at the API boundary is bypassed. To detect and break these loops, you need instrumentation at the trace level, and to prevent them, the harness has to own termination decisions.

Why infrastructure circuit breakers cannot stop reasoning loops

A developer running a nightly document-summarization pipeline watched it enter a retry loop at 11 PM and make thousands of identical failing tool calls for eight hours. The bill was $437. Nothing in the infrastructure stack caught it, because the infrastructure stack was looking at the wrong layer. Circuit breakers in distributed systems are built to detect retry storms at the API boundary: a call fails, the breaker opens, and subsequent calls are rejected until the downstream service recovers. That model assumes the retry decision lives in client code, where a circuit breaker can observe it. An LLM agent does not retry at that layer. It calls a tool, receives a timeout or error, and then re-plans. It decides internally that the prior approach failed and issues a new call with slightly different parameters. The retry happened inside the model's cognition, and the infrastructure sees a fresh request.

One developer's observation captures the gap precisely: "timeout per API call were working but timeouts!= circuit breaker. The agent saw 'timeout' as 'try a different approach' and kept running." The API timeout fired correctly. The circuit breaker did its job at the boundary. Neither mattered, because the agent interpreted the failure as a signal to continue under a new plan rather than to stop. The breaker never opens, because from its perspective no single endpoint is being hammered.

Multi-tool orchestration sharpens the problem considerably. Each of these is a place where a reasoning loop can form, and each operates above the level where infrastructure circuit breakers can see anything. The more tools an agent coordinates, the more opportunities it has to interpret a failure as a prompt to try a variant, and the less visible each retry becomes.

Where loop failures actually originate in the agent stack

Loop failures do not distribute randomly across an agent system. They cluster in specific, nameable layers of the harness: prompt specification, termination logic, tool schema, and inter-agent handoffs. The MAST taxonomy, presented by Cemri et al. at NeurIPS 2025 Datasets and Benchmarks, analyzed execution traces across seven multi-agent frameworks and found that Specification and System Design issues account for the largest share of all failures. These include task misinterpretation, ambiguous roles, poor decomposition, and missing termination conditions. Workflow loops fit squarely within Specification Issues. The structural root cause is a termination condition that is either missing entirely or delegated to the model.

That termination-condition problem has an empirical dimension as well. Wang et al. (2026) evaluated whether deployed LLMs can reliably report the task-progress signals that agent runtimes use for continue-or-stop decisions. Their finding is stark: almost every tested model is reliable at some task stages and unreliable at others. Models lose accuracy once work is under way, then recover only after the task is done. The model's own stop signal is therefore an unreliable gate at precisely the moments when a stop decision matters most. Delegating the continue-or-stop decision to a model-generated signal, which is the majority pattern across surveyed frameworks, is itself a structural failure mode rather than a configuration choice.

The same study identifies another loop-generating pressure point. When state-mutating write operations are in play, race conditions and state inconsistency introduce failure modes that stack on top of the reasoning ones. An agent that writes to a shared resource under parallel execution can produce inconsistent state, see that inconsistency as a task failure, and re-plan into another attempt. Moda, for instance, ingests execution traces and attributes loop failures to the specific harness layer responsible, turning a vague "loop detected" into a concrete diagnosis of what to fix.

Why model-owned termination signals cannot be trusted as the sole stop gate

The most common termination pattern in production frameworks today is to let the model declare its own completion. Wang et al. A concrete example from the paper makes the point sharply. In a τ²-bench telecom episode, the measured network speed was 27.5 Mbps against a requirement of at least 200 Mbps. The task was clearly unfinished. The model called done() anyway, and the runtime stopped, leaving the goal unmet.

Newer model generations do not eliminate this failure mode. They shift it. The newest models close the mid-task accuracy drop but grow conservative at the finish line, so the class of error changes while the structural dependency on model self-assessment remains. The problem cannot be patched with better instructions alone. It requires the harness to own the stop decision independently.

Bhardwaj et al. (2026) make the structural argument formally. In the frameworks that dominate current deployments, a step ends when the agent's own output says it has finished. The orchestrator marks the step complete, and every downstream guarantee rests on a self-assessment by the party least able to be objective about it. A scheduler-theoretic survey found that a large majority of open-source agent projects still use a variant of the unstructured agent loop. Their proposed fix is a bounded-loop harness with an independent gate the worker cannot write to. Replay validation against historical execution traces can establish whether a termination condition is reliable in practice, and Moda applies this approach to catch cases where the model declares completion while the task remains unfinished, before those gaps propagate into loops in production.

What detecting a reasoning loop actually requires at the trace level

Outcome-level signals tell an engineer that an execution failed. Root-cause attribution turns that binary signal into diagnostic feedback by identifying the first divergence from a correct execution and assigning fault to the responsible component, whether model, harness, environment, or grader. Doing that requires instrumentation at the span level. In the standard 2026 observability architecture, every LLM call, tool call, retrieval, and handoff is an OpenTelemetry span, and the trace tree shows the full agent flow. That trace tree is the substrate that makes loop detection possible. The loop-specific signals are all span-level: repeated tool calls with structurally similar arguments across non-adjacent steps, context window contents that carry a prior failure into a new reasoning step, inter-agent handoffs that re-present an already-rejected subtask.

The distinction between observability and circuit breaking matters here. AgentDebugX, published July 2026 as arXiv:2607.18754, demonstrates the required architecture as a closed debugging loop. Detect identifies step-level errors, Attribute locates their root causes, Recover proposes ranked fixes, and Rerun regenerates the trajectory around the failure point. A September 2026 paper, "Root-Cause Attribution Is a Search Problem: Continual Search for Long-Horizon Agent Failures," reframes the debugging task as iterative search over diagnostic evidence rather than reasoning over the whole trace at once, a pattern validated on the MegaRCA-Mix dataset.

The state of automated attribution remains weak even with these advances. On the Who&When benchmark, the strongest method reaches 28.8% strict agent-and-exact-step accuracy, with the strongest single-pass baseline scoring noticeably lower. Trace-level instrumentation helps, but you still need human review for hard attribution cases.

Three circuit-breaking mechanisms and where each one operates

Effective circuit breaking for reasoning loops requires three complementary mechanisms at different layers: a step-count ceiling, a token budget, and an independent termination gate. None is sufficient alone. They are a blunt instrument.

Step-count ceilings catch what wall-clock timeouts miss by capping the maximum number of LLM calls or tool invocations per workflow run. A ceiling of around 25 steps is a useful starting default for most agentic workflows. Token budgets address a related failure mode that step counts miss. An agent can stay under a step limit and still consume a large context window at each step. Moda treats those surfaced errors as harness problems to diagnose rather than infrastructure events to tolerate.

The third mechanism is the bounded-loop harness that Bhardwaj et al. (2026) describe: a worker, an independent gate the worker cannot write to, and a declared budget. The gate's independence is enforced as a structural property of the harness, not a convention. That independence is what prevents self-attestation, where a check passes because it asks the party whose claim it is supposed to verify. Their audit of a 69-loop catalogue found a large number of gates in shipped, reviewed code that were either vacuous, satisfied by the absence of the thing they check, or self-attesting, with the worker supplying the value the check applies to. Dify (2026) documents a runtime-owned hard cap as a backstop: "the loop terminates when either the termination condition is met, the maximum count is reached, or an Exit Loop node executes." Under parallel execution with state-mutating writes, Xu et al. The intervention layer must account for concurrent tool execution, not just sequential loops.

What harness engineering must own to prevent loops from forming in the first place

Most reasoning loops are preventable before they start if the harness explicitly owns termination conditions, tool schema integrity, and context lineage, rather than delegating any of these to the model. Termination conditions must live in harness code. The independent gate that Bhardwaj et al. establish as a structural requirement is a design constraint, not a runtime patch. Context lineage is equally a harness responsibility. In production environments with schema drift or stale sources, the failure surfaces at task completion rather than at input ingestion, so lineage tracking is a structural obligation rather than a model capability.

Prompt specification is the fourth lever. Xu et al. (2026) observe that as task complexity escalates, the decision space shifts from simple tool selection to coupled decisions like failure recovery and re-planning. GEPA (Agrawal et al., 2026) shows that prompts can be evolved systematically by reflecting on execution trajectories and mutating prompts accordingly, outperforming reinforcement learning while using a fraction of the rollouts. Prompt improvement becomes a repeatable engineering process rather than hand-tuning. The 25-step default for maximum LLM calls or tool invocations per workflow run is the operational floor under all of this: a backstop that catches loops before they get expensive, regardless of which upstream failure produced them.

Validating harness changes against production traces before shipping

A harness change that fixes one loop failure mode without regression testing against production traces is just as likely to introduce a new one. The principle is simple: never deploy a harness change without regression testing against golden tasks drawn from real failure modes, including loop detection, wrong tool choice, and unsafe actions. If evolution fixes one failure mode while breaking another, it is net-negative. Golden tasks should be tiered into smoke, core, and torture sets, and replay should use recorded tool outputs with sandboxed side effects. That is the difference between stable agent testing and flaky theater where synthetic inputs never exercise the conditions that produced the original loop.

Replay exposes a failure class that synthetic evaluations miss: a loop that forms because a specific combination of prior tool outputs fills the context window in a way that triggers re-planning. Only a trace from the original failure captures that combination. Chronicle (arXiv:2609.20625, 2026) is a cut-point replay system built for exactly this purpose. It copies prompts, agent state, and tool arguments from production traces, applies redaction at record time before any record is written, and preserves the structure that tests assert on while removing sensitive values. That redaction-at-record-time property solves the practical blocker of using production traces in a test harness.

The workflow from broken trace to verified fix should be repeatable, not a manual incident response. Moda ingests production traces, attributes failures to the specific harness layer responsible, generates concrete reviewable improvements, and validates them against historical traces before recommending what to ship. The closing insight from Bhardwaj et al. (2026) reframes the whole argument: verification layers are precisely the components whose failures are invisible. When a verifier wrongly accepts, the system reports success and nothing complains. A single agent can burn through $700 in one night from retry loops and reasoning-layer retries. Automated gate testing, not just human review, is therefore a structural requirement for harness reliability, because the component most likely to fail silently is the one checking whether everything else failed.