AI agent infinite loop in Python: how to detect and stop it

Why Python AI agents loop: the four root causes

1. Empty or unhelpful tool results

The most common cause. Your tool returns [], "", None, or a dict like {"error": "not found"}. The LLM receives this as a valid tool response, interprets it as “I need to try again differently,” generates a new tool call with rephrased arguments, and gets the same unhelpful result. The loop continues until the framework’s iteration limit is hit. With default limits of 10–25 iterations and LLM calls at $0.01–$0.10 each, a single looping agent invocation costs $0.10–$2.50 before it terminates.

2. Silent exception masking

Many agent frameworks catch exceptions thrown by tools and convert them to error strings that get fed back to the LLM as a “tool result.” LangChain’s AgentExecutor does this; so does AutoGen’s function calling layer. A ConnectionError, TimeoutError, or even a KeyError in your tool code becomes a string like "Error: connection refused" in the agent’s message history. The LLM reads this as a retryable failure and generates another call. If the underlying service is down, every retry produces the same error string, and the loop runs to the iteration limit.

3. LLM prompt drift in long context windows

As the conversation history grows (each tool call appending input and output to the messages list), later LLM calls have larger contexts. At high context sizes, the model’s attention to the original instruction degrades and it may start generating tool calls that are less relevant to the original task — essentially exploring rather than solving. This produces a “semantic loop” where the tool calls are all different (so fingerprinting by exact args doesn’t catch them) but they’re all equally unhelpful. Detecting this requires context-size monitoring, not just call fingerprinting.

4. Multi-agent routing loops

In multi-agent architectures (AutoGen group chats, LangGraph multi-node graphs, CrewAI crews), a coordinator agent routes tasks to specialist agents. If a specialist fails and returns a fallback, the coordinator may route the same task to a different specialist or back to the same one. This creates a cross-agent loop that is invisible to single-agent loop detection: each individual agent executes its steps correctly, but the system as a whole cycles on the same unresolvable task.

Writing a minimal loop detector without a library

If you want to understand the mechanism before adding a dependency, here is the core fingerprinting algorithm that RunGuard implements under the hood:

from collections import deque
import hashlib, json

class SimpleLoopDetector:
    def __init__(self, window: int = 10, threshold: int = 2):
        self.window = deque(maxlen=window)
        self.threshold = threshold

    def _fingerprint(self, tool_name, args, result) -> str:
        payload = json.dumps(
            {"tool": tool_name, "args": args, "result": result},
            sort_keys=True, default=str
        )
        return hashlib.sha256(payload.encode()).hexdigest()[:16]

    def record(self, tool_name: str, args: dict, result) -> None:
        fp = self._fingerprint(tool_name, args, result)
        self.window.append(fp)
        count = list(self.window).count(fp)
        if count >= self.threshold:
            raise RuntimeError(
                f"Loop detected: {tool_name}({args}) returned same result {count}x"
            )

# Use it in any agent run loop
detector = SimpleLoopDetector(window=10, threshold=2)
# call detector.record(tool_name, args, result) after each tool call

This is the core mechanism. RunGuard adds: async compatibility, Slack/PagerDuty alerting, budget tracking, context-size monitoring, cross-tool sequence detection, structured error payloads for your monitoring system, and pre-built integrations for LangChain, LangGraph, AutoGen, PydanticAI, Phidata, and Haystack.