IAL-Scan: Analyzer for Infinite Agentic Loops

• The paper introduces IAL-Scan, which abstracts heterogeneous agent code into a unified Agent IR to uncover infinite loops in LLM agent projects.
• It builds an Agentic Loop Dependence Graph (ALDG) to capture both explicit and implicit feedback paths that lead to high cost and unbounded state growth.
• Empirical evaluation across over 6,500 repositories shows 91.9% precision in detecting failures, emphasizing the need for effective bounds in agent-driven systems.

Searching arXiv for the IAL-Scan paper and closely related agent-analysis work. IAL-Scan is a static analyzer designed to uncover Infinite Agentic Loops (IALs) in real-world LLM agent projects before deployment. Introduced in "When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents" (Hou et al., 2 Jul 2026), it abstracts heterogeneous agent code into a framework-independent Agent IR, builds an Agentic Loop Dependence Graph (ALDG) to recover both explicit and framework-induced feedback paths, and checks whether these paths can repeatedly reach costly or state-growing operations without an effective stopping bound. The target failure mode is structural: an agentic feedback path repeatedly triggers model calls, tool invocations, agent executions, or workflow transitions without an effective termination condition.

1. Problem domain and failure model

IAL-Scan is organized around the notion of an Infinite Agentic Loop. An IAL is not an ordinary programming loop. Ordinary loops are syntactic and typically have clear iteration variables and bounds. IALs can be implicit, spanning framework APIs, routers, tool dispatchers, and reentry paths. Their continuation can be controlled by model output or external responses, and termination may depend on fragile conditions or be attached to scopes that do not cover the repeated path (Hou et al., 2 Jul 2026).

The paper characterizes IALs as arising from the interplay of agent logic, framework semantics, runtime observations, and termination mechanisms. The corresponding consequences are cost exhaustion, model denial of service, context growth, and repeated external side effects. In operational terms, a single request can be amplified into long running model and tool execution, causing API credit depletion, resource occupation, prompt inflation, and repeated writes or external API calls.

The feedback paths of interest include repeated model calls, tool calls, workflow transitions, and agent handoffs or reentry. This framing is important because it relocates the problem from syntactic control flow to agent-runtime semantics. A plausible implication is that conventional loop checks are insufficient when repetition is induced by graph transitions, tool registries, delegation APIs, or framework-default execution behavior.

2. Agent IR and the execution abstraction

IAL-Scan abstracts diverse agent code into a framework-independent Agent IR that captures repeated execution, costly invocations, state growth, and bounds in a uniform form (Hou et al., 2 Jul 2026). The Agent IR schema includes typed facts and relations. The fact types are ExecutionUnit, Controller, Invocation, StateUpdate, Bound, and ExitRecord. Their common fields are id, kind, location, and attrs. The relations are owns(unit, fact), calls(invocation, callee), updates(state_update, target), guards(controller, variable), exits(exit_record, controller), constrains(bound, target), transitions(source, target), dispatches(invocation, target), and aliases(name, target).

Program fact extraction begins from Python source parsed into ASTs. The analysis indexes modules, imports, decorators, object construction, factories, and project-defined agent callables. It performs lightweight name and attribute resolution for imports, local assignments, object fields, and factory returns, but it does not perform whole-program points-to analysis. Local control and data facts are then extracted, including loops, recursive calls, call expressions, state updates, conditional exits, and retry paths. These source-level facts are translated into Agent IR: loops become Controller, runtime calls become Invocation, loop-carried state changes become StateUpdate, caps and budgets become Bound, and local exits become ExitRecord.

Framework behavior modeling extends this abstraction to implicit execution. Construction identifies agents, tools, workflows, graph nodes, and runtime scopes. Invocation modeling derives implicit execution relations such as tool dispatch via tool registries and @tool, workflow transitions via add_edge, add_conditional_edges, and tools_condition, and multi-agent handoffs via Agent.as_tool(...), Runner.run(...), and delegation APIs. Configuration modeling attaches limits such as max_turns, max_iterations, recursion_limit, max_retry, and budgets to the corresponding runtime scope or repeated path. Unresolved targets are preserved as attributes without precise transfer relations.

3. Agentic Loop Dependence Graph and boundedness analysis

The central reasoning structure is the Agentic Loop Dependence Graph. The ALDG is defined as a directed attributed graph

$G_A = (V_A, E_A, a),$

where $V_A$ are vertices, $E_A$ are typed edges, and $a$ assigns attributes to nodes and edges such as source locations, guard conditions, and framework bindings (Hou et al., 2 Jul 2026).

Node construction retains Agent IR facts relevant to loops: controller facts $C$, invocations marked high_cost, state updates marked state_growth, and execution units. For each retained fact $r$, IAL-Scan creates a node $v_r \in V_A$, assigns a node kind, and carries over fields and attributes. Edge construction derives typed edges from Agent IR relations, including CONTROL_FLOW, CALL, WORKFLOW_TRANSITION, TOOL_DISPATCH, LOOP_BACK, RECURSION, AGENT_REENTRY, EXCEPTION_RETRY, CONDITIONAL_TRUE, and CONDITIONAL_FALSE. The resulting graph recovers both explicit loops and framework-induced feedback paths.

For a controller node $c$, the analysis summarizes feedback, cost, growth, exits, and bounds. In the notation given in the paper,

$$\mathrm{Feedback}(c) = \{\, \mathrm{kind}(e) \mid e \in \mathrm{cycle}(c),\ e.\mathrm{feedback} \,\} \cup \{\, \mathrm{guard\_source}(c) \,\},$$

$$\mathrm{Cost}(c) = \{\, \mathrm{kind}(i) \mid i \in \mathrm{body}(c),\ i.\mathrm{high\_cost} \,\},$$

$V_A$0

$V_A$1

and

$V_A$2

Cycle detection is performed over the edge kinds

$V_A$3

IAL-Scan builds the cycle subgraph, computes SCCs, and keeps candidates that are reachable from an agent entry and contain at least one feedback path that reaches an agentic action, a costly invocation, or a growing state update. Cost and state growth are modeled with weights $V_A$4 and $V_A$5 over nodes. A cycle is cost-repeating if it contains a costly operation on a feedback path, and state-repeating if it contains a state-growing operation on a feedback path.

Boundedness is formalized through coverage and effectiveness. A bound covers a candidate when it constrains the controlling controller, its owner scope, or dominates the repeated path’s runtime scope. An effective bound must have a natural-number value, be enabled, and apply to continuation. The paper defines

$V_A$6

and the IAL predicate

$V_A$7

Exits depending on model, tool, or external state are treated as non-deterministic and do not by themselves satisfy $V_A$8.

4. Static analysis pipeline and framework-induced feedback

The static analysis pipeline parses repositories and indexes Python projects, normalizes code and framework behavior into Agent IR, constructs the ALDG, detects cycles and feedback paths via SCCs, checks bound coverage for each candidate, and optionally applies LLM-assisted pruning over bounded slices; the LLM acts as a negative filter only (Hou et al., 2 Jul 2026). The supported framework families are LangChain, LangGraph, CrewAI, AutoGen, LlamaIndex, OpenAI Agents SDK, Google ADK, and Semantic Kernel.

Framework semantics are treated as first-class sources of feedback. Workflow transitions are recovered from APIs such as add_edge, add_conditional_edges, and tools_condition. Tool dispatch is recovered by matching tool registrations and tool_calls. Planner/executor and retry policies are turned into EXCEPTION_RETRY, LOOP_BACK, or RECURSION edges. Agent handoffs through Agent.as_tool(...), Runner.run(...), and delegation APIs introduce AGENT_REENTRY edges. This is the mechanism by which implicit repetition becomes statically visible.

The paper gives several representative patterns. In the Moonshot wrapper motivating example, the outer loop continues while finish_reason ∈ {None, "tool_calls"}; on "$web_search&quot;</code> tool calls, both the model message and <code>ToolMessage</code> are appended to <code>messages</code>, and the model is re-invoked with enlarged history. The ALDG captures <code>LLM_CALL → STATE_APPEND → LOOP_BACK</code> with a model-controlled exit, and no <code>max_tool_calls</code>, <code>max_iterations</code>, or <code>timeout</code> bound applies. In the LiteRAG planner example, nested <code>while not success</code> loops surround <code>self.LLM.invoke(...)</code>; parser failures are swallowed, rejected plans reset <code>success</code> to <code>False</code>, and no retry cap, timeout, or budget covers the feedback path. In the NVIDIA AI Virtual Assistant example, a <code>while True</code> loop binds tools and invokes or streams the model; empty or malformed output causes a corrective prompt to be appended and the model to be retried, creating repeated model calls and message growth without a cap.</p> <p>The implementation complexity is near-linear in graph size. ALDG construction is $V_A$9, SCC detection over the cycle subgraph runs in $E_A$0, and bound coverage checks are proportional to the number of bounds and candidate paths. The paper describes overall IAL detection as near-linear in graph size, with modest overhead for framework matching and pruning.

5. Empirical evaluation and observed failure patterns

IAL-Scan was evaluated on 6,549 real-world Python LLM agent repositories, totaling 246,748 Python files and 33.41M LOC (Hou et al., 2 Jul 2026). It reported 74 potential findings, among which manual review confirmed 68 IAL failures across 47 projects, achieving 91.9% precision. The implementation is in Python; optional LLM-assisted pruning uses gpt-5.5; the reported environment was Ubuntu 24.04.3 LTS with 2×AMD EPYC 9554, 6×NVIDIA A100 80GB. Average per-project analysis time was 31.2s, and average token usage for pruning was 4.2K.

The confirmed failures were distributed across frameworks as follows: LangGraph 33.8%, AutoGen AgentChat 32.4%, LlamaIndex 8.8%, LangChain AgentExecutor 7.4%, CrewAI 5.9%, OpenAI Agents SDK 5.9%, Google ADK 4.4%, and Semantic Kernel 1.5%. The failure patterns were retry feedback without bound at 25.0%, tool-call iteration without bound at 23.5%, multi-agent chat without turn bound at 20.6%, workflow loop without effective bound at 13.2%, message reentry without bound at 10.3%, and runner, delegation, or evaluator feedback at 7.4%.

The reported impacts were API cost exhaustion in 95.6% of confirmed cases, model denial of service in 95.6%, context window exhaustion in 27.9%, and external tool rate-limit exhaustion in 7.4%. Root causes were missing strong bound in 100.0% of confirmed failures, tool-controlled retry in 41.2%, model-controlled termination in 38.2%, missing exit in 33.8%, workflow cycle without verified bound in 30.9%, state growth amplifier in 27.9%, and agent tool reentry in 25.0%. These figures make clear that the dominant issue is not merely the presence of a cycle, but the absence of an effective bound on a costly or state-growing feedback path.

Ablation results further specify the role of each analysis component. On a 264-project subset with 340 static candidates, removing framework modeling increased static candidates from 340 to 910 and alerts from 74 to 276, reduced true-positive coverage from 68 to 61, and raised time from 31.2s to 92.3s. Removing the agentic gate caused the largest candidate increase, from 340 to 1,453, and raised token usage from 4.2K to 40.4K. Removing bound coverage lowered true-positive coverage to 60 and increased false positives. Without LLM pruning, all 340 static candidates were reported, retaining the true positives but with high false positives.

Baseline comparisons also indicate the role of agent-specific abstraction. A pure LLM API baseline covered 23 of 68 true positives, produced 183 alerts, and used more than four times as many tokens as IAL-Scan. A general coding assistant covered 50 of 68 true positives, but generated many extra alerts, hit timeouts in 75 projects, and incurred average cost of 141.9K tokens per project and 116.0s per project.

6. Limitations, positioning, and operational guidance

IAL-Scan is subject to the usual constraints of static approximation. Over-approximations may yield false positives, and sensitive bounds and dynamic conditions can be hard to resolve statically (Hou et al., 2 Jul 2026). The reported false positives numbered 6 and arose from subtle bound configurations difficult to resolve statically, including bounds outside loop body, framework defaults such as max_iterations=3 and max_tool_calls=2, async timeouts, and bounded two-turn exchanges. The reported false negatives numbered 7 and were mainly due to unrecognized bounds in LangGraph cycles, handwritten tool-call loops, framework-adjacent orchestration loops, and multi-agent conversations missing explicit turn or termination bounds. Static candidate discovery was deterministic at 340 candidates across runs, while variability arose from LLM pruning.

In relation to prior analysis tooling, the paper states that traditional static analyzers such as CodeQL and Semgrep do not model agent-specific execution semantics such as tool dispatch, framework transitions, and agent reentry. It also positions agent-aware analyses including AgentProof, Agent Audit, AgentRaft, AgentSCOPE, and AgentBOM as studying workflow topology, tool effects, privilege and data flows, and auditability, but not whether repeated feedback paths are effectively bounded. The distinctive contributions claimed for IAL-Scan are a framework-independent Agent IR, an ALDG that recovers both explicit loops and framework-induced feedback paths, and bound coverage analysis for costly or state-growing repeated paths.

The operational guidance given in the paper is direct. Iterative agent behaviors should carry explicit bounds such as max_turns, max_iterations, max_retry, max_tool_calls, timeout, and budgets. Model-controlled termination should not be relied upon without a backup bound. Decreasing measures or progress guards should be added so that iterations have a variant that decreases per step. External tools should be rate limited and protected by capped retriers and circuit breakers. Message history and memory growth should be pruned or summarized. Multi-agent turns should be capped, and supervisors should propagate bounds to delegates and evaluators. Most importantly, bounds should be placed on the feedback path itself: they must constrain the controller or the runtime scope that dominates the repeated path, not merely an inner call or a nested agent.

IAL-Scan therefore defines a specialized form of agent-aware static analysis: it treats LLM applications as executions over controllers, invocations, state updates, and framework-induced transitions, and it interprets safety partly as a boundedness property over reachable feedback paths. This suggests a broader shift in analysis for agentic systems: the decisive unit is not the syntactic loop, but the semantically effective feedback path that can continue to consume cost, accumulate state, or trigger side effects without an effective stopping mechanism.