Why Your AI Agent Keeps Looping and How to Stop It
You've built the agent. The tools are wired up. The prompt looks solid. You run it on a test task and watch it call the same search tool four times in a row, rewrite the same plan it already rejected, and then either crash with a token limit error or produce an answer that ignores everything it just retrieved.
This is the looping problem. And it's not a bug in your code. It's a design failure in how the agent reasons, how it manages state, and how it decides when it's done.
The frustrating part is that it works fine on simple tasks. The failure only shows up when the task is genuinely complex — which is exactly when you need the agent to work.
This article is about why loops form, what they look like in production, and the specific architectural decisions that stop them. Not theoretically. In systems that actually ship.
Why Agents Loop in the First Place
The root cause is almost never infinite recursion in the traditional programming sense. It's something more subtle: the agent lacks a reliable mechanism to recognize that it's not making progress.
LLM-based agents operate in a reasoning loop. They observe the current state, decide on an action, execute the action, observe the result, and repeat. This loop is intentional and necessary. The problem is that nothing in the base architecture guarantees the loop terminates.
Three specific failure patterns account for the majority of real-world loops:
Pattern 1: Goal ambiguity. The agent doesn't have a precise enough representation of what "done" looks like. It takes an action, the result is partially useful, and the agent can't determine whether that partial result satisfies the goal or whether more action is needed. So it acts again. And again.
Pattern 2: Tool output misinterpretation. The agent calls a tool, receives output it doesn't know how to use, and instead of escalating or stopping, it calls the same tool with a slightly different input hoping for a better result. This is especially common with search tools returning ambiguous results and API tools returning unexpected schemas.
Pattern 3: Memory-less replanning. The agent generates a plan, takes the first action, and then — because the context window management is poor or the state representation is incomplete — re-reads the original task, forgets what it already did, and generates the same plan again from scratch.
Each of these produces a different loop signature, requires a different fix, and fails in a different way in production.
The Step Counter Fix That Doesn't Actually Work
The first thing most developers do when they notice looping is add a maximum step count. If the agent hasn't finished in 20 steps, terminate.
This stops the loop. It does not fix the agent.
A step counter is a circuit breaker, not a solution. It limits damage, but an agent that hits its step limit on 30% of complex tasks has failed on 30% of complex tasks. The user experience is a timeout error instead of an infinite loop — which is marginally better but still broken.
The scenario where this matters: A research agent deployed in an investment banking workflow is tasked with compiling a due diligence summary on a target company. The task genuinely requires 15–20 tool calls — searching for recent filings, pulling financial metrics, checking news, retrieving competitor data. A step limit of 20 works most of the time. But on complex targets, the agent burns 8 steps in a search loop on a subsidiary structure before even starting the financial analysis. It hits the limit, returns an incomplete report, and the analyst who receives it doesn't know it's partial.
The step counter made the agent behave correctly in testing and incorrectly in the specific scenarios that matter most.
What you actually need is not a step limit — it's progress detection.
Progress Detection: The Missing Piece
Progress detection asks a fundamentally different question than step counting. Instead of "how many steps have been taken?" it asks "is the agent closer to the goal than it was before the last action?"
This requires the agent to maintain a structured representation of what it knows, what it still needs to know, and how the most recent action changed that state.
In practice, this means augmenting the agent's state object with:
- A completed sub-goals list — what has been successfully retrieved or resolved
- A remaining sub-goals list — what still needs to happen before the task is complete
- A last-action result summary — a structured representation of what the most recent tool call actually produced
- A progress delta field — did the last action reduce the number of remaining sub-goals?
When the progress delta is zero for two or more consecutive steps — the agent took an action and the remaining sub-goals list didn't change — the agent is looping. Not by definition of step count, but by definition of actual progress.
This pattern is more complex to implement than a step counter. It also works.
Example state representation:
{
"completed_goals": ["find_financials", "check_news"],
"remaining_goals": ["compile_summary"],
"last_action": "search_web",
"last_action_result": "Retrieved Q3 earnings report",
"progress_delta": 1,
"loop_count": 0
}
When progress_delta equals 0 for two consecutive steps, trigger escalation rather than another tool call.
The Tool Calling Loop: A Specific and Common Problem
Tool calling loops deserve their own treatment because they're the most common loop type in production agentic systems.
The scenario: A customer service agent is tasked with resolving a billing dispute. It needs to retrieve the customer's invoice history. It calls the get_invoice_history tool. The tool returns a paginated response with next_page_token in the metadata. The agent doesn't know what to do with a paginated result — its instructions don't cover pagination. So it calls get_invoice_history again, hoping for a complete result. Gets the same first page. Calls again. Loops indefinitely.
This is not an LLM reasoning failure. It's a tool specification failure.
Every tool in an agentic system needs:
1. A precise output schema the agent is trained or prompted to understand — not just the happy-path schema, but the error schemas, pagination schemas, and partial-result schemas. If the agent can receive a next_page_token, the agent needs to know what it means and what to do with it.
2. Explicit handling instructions for every non-success response code. What should the agent do if the tool returns a 429 rate limit? A 404? A timeout? An empty result set? If the handling instructions are missing, the agent defaults to retrying — which produces loops.
3. A "no useful result" exit path. If a search tool returns results that don't help with the current sub-goal after two attempts, the agent needs a documented path: escalate to a different tool, rephrase the query using a specific strategy, or mark the sub-goal as unresolvable and continue.
Without these three elements, tool calling loops are architectural inevitabilities, not edge case bugs.
Memory Architecture and Why It Determines Loop Frequency
Most agent looping problems that aren't immediately obvious tool specification failures are actually memory architecture failures. The agent re-does work because it doesn't remember doing it the first time.
This happens in three distinct ways:
Working Memory Overflow
LLM context windows are long but finite. On complex multi-step tasks, early observations and completed actions scroll out of the context window as new content is added. The agent effectively forgets what it already did.
The fix is external working memory — a structured scratchpad maintained outside the LLM context that records completed steps, retrieved facts, and current state. At each step, a compressed summary of this scratchpad is injected into the prompt rather than the full conversation history. The agent always has access to "what has been done" without it consuming the entire context window.
Episodic Memory Contamination
In multi-session or multi-user agent deployments, episodic memory from previous tasks can contaminate the current task. The agent starts a new task, retrieves a memory that's superficially similar to the current task, and begins executing the plan it used last time — which may be completely wrong for the current context.
The fix is strict memory scoping — episodic memories are tagged with task identifiers, user identifiers, and domain tags. Retrieval from episodic memory requires matching on multiple dimensions, not just semantic similarity.
No Completion State Persistence
The agent completes a sub-goal. If the process crashes and restarts — or if the agent is invoked again on the same task — there's no record that the sub-goal was already completed. The agent starts from scratch.
The fix is checkpoint persistence — completed sub-goals are written to durable storage (a database, not just in-memory state) with timestamps. On any invocation, the agent's first action is to check the checkpoint store and resume from where it left off.
Prompt Architecture: How Instruction Design Creates or Prevents Loops
The agent's system prompt is the primary controller of its reasoning behaviour. Most loop-prone agents have system prompts that are either too vague about termination or actively incentivize continued action when stopping would be the right choice.
The vagueness problem:
A system prompt that says "research the topic thoroughly and provide a comprehensive answer" has no termination signal. "Thoroughly" and "comprehensive" are subjective. The agent will keep retrieving and synthesizing because the instructions provide no signal for when enough is enough.
Compare to: "Research the topic and provide an answer. You are done when you have retrieved at least three distinct sources that directly address the query, or when you have made five retrieval attempts and must work with what you have. Do not continue researching after the termination condition is met."
The second prompt has an explicit termination condition.
The action-bias problem:
LLMs trained with RLHF tend to be action-biased — they're rewarded for producing output, not for determining that no output is needed. In an agentic context, this translates to a tendency to keep taking actions rather than determining that the current state is sufficient.
Counteracting this requires explicitly rewarding stopping in the system prompt: "If the information you have retrieved is sufficient to answer the question, stop and answer immediately. Do not retrieve additional information unless the current information is genuinely insufficient. Taking fewer, more precise actions is better than taking many redundant actions."
The re-evaluation trap:
Some agents are prompted to "verify" or "double-check" their answers. Without tight constraints on what constitutes successful verification, the agent enters a loop where it verifies, finds something marginally improvable, revises, reverifies, and never terminates.
The fix: verification should be a single pass with a binary outcome — the answer passes verification criteria or it doesn't. Verification criteria should be explicit, not subjective. "Does the answer contain a specific figure, a source citation, and a date?" is verifiable. "Is the answer thorough and well-reasoned?" is not.
Orchestration Layer Patterns That Prevent Loops Architecturally
Individual agent design matters, but some loop prevention needs to happen at the orchestration layer.
The Supervisor Pattern
Rather than one agent running a multi-step task end-to-end, a supervisor agent coordinates multiple sub-agents, each responsible for a narrow, well-defined sub-task.
A research task becomes: Supervisor → [Search Agent retrieves sources] + [Analysis Agent extracts key facts] + [Synthesis Agent generates report]. Each sub-agent runs once, completes its bounded task, and returns a structured result. Loops are contained within sub-agents that have simple enough scopes to terminate reliably.
What goes right: Complex tasks complete reliably. Loops are isolated and easier to debug.
What goes wrong: Supervisor design is hard. If the decomposition is wrong — a sub-task is too vague or the information flow between sub-agents is poorly specified — you just moved the loop from one agent to another.
The Plan-Then-Execute Pattern
Instead of interleaving planning and execution (reason, act, reason, act), the agent produces a complete plan first, then executes each step without replanning.
The planning phase generates a structured, numbered list of specific actions with explicit expected outputs for each step. The execution phase follows the plan strictly — it doesn't generate new plans, it only executes steps and records results.
This eliminates memory-less replanning loops almost entirely. The agent doesn't re-derive the plan because it has the plan in its state.
What goes right: Eliminates the most common loop type in straightforward tasks. Execution is predictable and auditable.
What goes wrong: Rigid on dynamic tasks. If step 3 depends on the result of step 2 in a way that wasn't fully predictable during planning, the static plan may be wrong and the agent will execute it anyway.
The Interrupt-and-Escalate Pattern
Rather than running to completion autonomously, the agent runs in bounded segments with human-in-the-loop checkpoints. After a defined number of steps or when progress detection signals a potential loop, execution pauses and a human is asked to confirm, redirect, or terminate.
This isn't admitting defeat — it's the right architecture for high-stakes, high-complexity tasks where autonomous operation is not yet reliable enough to run without oversight.
What goes right: Prevents runaway costs, catches loops before they waste significant compute, maintains human oversight on decisions that matter.
What goes wrong: Adds friction to the user experience. Only appropriate when the cost of a wrong autonomous decision exceeds the cost of a human checkpoint delay.
Detecting Loops at Runtime: Observability You Actually Need
Building loop prevention into the architecture is the right approach. Building observability that detects when loops are happening anyway is equally important.
Action repetition detection: Hash each tool call (tool name + parameters). If the same hash appears twice within the current task execution, flag it. Three identical tool calls in one task is definitionally a loop. This is cheap to implement and catches the majority of tool calling loops automatically.
Time-per-step tracking: LLM inference takes roughly constant time per token. If a step is taking significantly longer than average, the agent is either processing an unexpectedly large context (which may indicate memory management problems) or is stuck in a sub-loop the outer loop can't see.
Sub-goal completion rate: Track what percentage of agent runs complete all planned sub-goals vs. hitting step limits vs. erroring. If the sub-goal completion rate drops below a threshold, the agent has a systematic loop problem somewhere in its task distribution — even if individual runs look fine.
Cost-per-task alerting: Token cost is a direct proxy for loop severity. A task that normally costs $0.08 in tokens costing $0.80 is running 10x more steps than expected. Cost anomaly detection on a per-task-type basis catches expensive loops before they accumulate.
The Honest Reality: Some Loops Are in the Model, Not the Architecture
After addressing tool specification, memory architecture, prompt design, and orchestration patterns, there will still be tasks on which a given model reliably loops.
Some reasoning patterns — particularly those requiring tracking many interdependent constraints across a long task horizon — exceed the reliable capability of current models on certain task types. No architectural fix resolves a fundamental capability gap.
The honest diagnostic when loops persist after architectural fixes:
1. Is the task actually within the model's reliable capability range? Test with GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro on the same task. If all three loop, the task structure is the problem, not the model. Decompose it differently.
2. Is the task complexity growing faster than the architecture scales? A task that works at 5-step depth may loop at 15-step depth. Know your system's reliable operating envelope.
3. Is the loop actually a feature masquerading as a bug? Some task types genuinely benefit from iterative refinement — writing, analysis, optimization. The question is whether the iteration is converging. A loop that produces incrementally better outputs and terminates on a quality threshold is working correctly. A loop that produces identical outputs and terminates on a step limit is broken.
Closing: Loops Are a Symptom of Incomplete Agentic System Design
Fixing agent loops isn't a debugging task. It's an architectural task that touches state management, tool specification, prompt engineering, orchestration patterns, memory design, and observability simultaneously.
Understanding why loops form leads naturally into deeper questions that every serious agentic systems builder eventually faces: How do you design evaluation frameworks that catch loop-prone tasks before production deployment? How do you architect multi-agent systems where loops in one agent don't cascade into the entire pipeline? How do you balance agent autonomy with human oversight in high-stakes workflows where a runaway agent has real financial or operational consequences?
These questions connect to a broader set of skills — agentic system architecture, LLM evaluation methodology, production ML observability, and the orchestration patterns that separate demos from deployable systems. None of them can be answered by reading about them. They require building real systems, watching them fail in specific ways, and iterating with enough domain knowledge to understand why each failure is happening.
At Meritshot, the AI Engineering program is built around exactly this kind of hands-on system design — working through agent architectures that fail in real ways, instrumenting observability layers, running live debugging sessions on broken pipelines, and building the intuition that only comes from seeing a production deployment go wrong and knowing precisely how to fix it.
The agent that loops is telling you something about your architecture. The practitioner who can hear that signal is the one who builds systems that work.
