Why Your AI Agent Keeps Looping and How to Stop It
The demo worked perfectly. Twelve clean steps, the right tool calls, a coherent final answer. You showed the team. Everyone was impressed.
Then you ran it on a slightly different input and watched it call the same API eleven times, rewrite a plan it had already discarded, and eventually either hit a token limit or produce an answer that bore no relationship to the question.
This is the looping problem. And the reason it's so frustrating is that it doesn't announce itself as a design flaw. It disguises itself as a bad run, an edge case, an unusual input. You fix the specific instance. The next loop is slightly different. You fix that. The cycle continues.
Loops don't come from one place. They come from at least five distinct failure modes — and unless you can distinguish between them, you'll keep patching symptoms while the architectural causes remain untouched.
This article maps all five, shows you what they look like in production, and gives you the specific fixes that address the underlying cause rather than the surface behavior.
What a Loop Actually Is (and What It Isn't)
Before diagnosing loops, it's worth being precise about what you're looking at.
A loop in an agentic system is not infinite recursion in the traditional programming sense. It's a situation where the agent takes repeated actions that do not reduce the distance to the goal — where each step produces a state that is effectively equivalent to a state the agent has already been in, yet the agent continues acting.
There are two signatures:
Type 1 — The Spinning Loop: The agent calls the same tool or generates the same output repeatedly without variation. The scratchpad fills with identical entries. Cost accumulates. Nothing changes.
Type 2 — The Wandering Loop: The agent takes different actions each iteration but makes no net progress. It searches, finds something partially relevant, decides it needs more information, searches again from a slightly different angle, finds something else partially relevant, and never converges on an answer or a decision.
Type 1 is easier to detect — a simple hash comparison of consecutive actions catches most cases. Type 2 is harder because the agent is "doing things" that all look legitimate in isolation. Detecting it requires tracking progress toward a goal, not just action diversity.
Most step-counter approaches catch Type 1 and miss Type 2 entirely. Most production loops are Type 2.
Failure Mode 1: The Termination Condition Is Absent or Subjective
This is the most common root cause and the one most frequently overlooked because the system prompt "looks fine."
The agent doesn't loop because it's confused. It loops because it genuinely cannot determine when it's done. And when an agent cannot determine when it's done, it defaults to continuing — because continuing is what LLMs are trained to do.
The scenario:
A research agent is tasked with "comprehensively analyzing the competitive landscape for a B2B SaaS product." The system prompt doesn't define what "comprehensive" means. It doesn't specify how many competitors to cover, what sources constitute sufficient evidence, or what the output format looks like when the analysis is complete.
The agent searches for competitors. Finds five. Then decides five might not be comprehensive. Searches for more. Finds three additional. Wonders if those are truly comparable. Searches for criteria to evaluate comparability. Returns to the original five with updated criteria. Finds nuances in two of them worth investigating. Follows those threads.
Nothing about this behavior is wrong step by step. The problem is structural: there is no state in which the agent can confidently determine that the analysis is complete.
The fix:
Replace subjective completion language with explicit termination conditions. Not "analyze comprehensively" but:
- "Identify the top 8 competitors by market presence. For each, extract: pricing tier, target customer size, primary differentiator, and one customer review quote. When you have all four fields for all eight competitors, stop and produce the output."
The termination condition is now observable. The agent can check it. The check produces a binary result. The loop has a floor.
The harder case:
Some tasks resist explicit termination conditions because the goal is genuinely open-ended — "find the best approach to this problem" or "determine whether this investment is worth pursuing." For these, the fix is not a completion state but a completion threshold: "after N research steps or N minutes of processing, produce your best current answer with explicit confidence levels and remaining uncertainties noted."
Threshold-based termination accepts that some tasks don't have natural stopping points. It replaces the absent natural stopping point with a policy.
Failure Mode 2: Tool Output Doesn't Match Agent Expectations
An agent calls a tool expecting a specific response structure. The tool returns something different — not an error, just a different schema, a paginated result, an empty set, or a message that's technically valid but contextually confusing. The agent doesn't know what to do with it. So it calls the tool again.
The scenario:
A customer service agent needs to retrieve a customer's order history. It calls get_order_history(customer_id=12345). The tool returns:
{"orders": [], "next_page_token": "abc123", "total_count": 47}
The agent's instructions describe get_order_history as returning a list of orders. The instructions don't mention pagination. The agent receives an empty array and a mysterious token. It interprets the empty array as "no orders found." It tries a different approach — maybe searches by email instead. Gets the same result. Tries yet another approach. Meanwhile, 47 orders are waiting on page 2.
This is not an LLM failure. It's a tool contract failure. The tool's actual behavior and the agent's model of the tool's behavior are misaligned.
The systematic version of this problem:
Every tool in an agentic system has an implicit contract: what it accepts, what it returns, and what edge cases look like. Most tool specifications document the happy path. They don't document:
- What happens when results are empty
- What pagination signals look like and what the agent should do with them
- What error structures look like for each error type
- What "partial success" looks like
- What the agent should do when it has tried twice and still has inadequate results
The fix:
Tool specifications need to cover the full contract, not just the happy path. For every tool:
- Document every possible response structure the agent will ever receive
- For each non-success structure, include explicit handling instructions
- Define a "no useful result after N attempts" exit path that the agent can execute without improvising
- Include examples of each response type in the tool description
Failure Mode 3: State Doesn't Survive Context Window Limits
This failure mode produces the most disorienting loops because the agent behaves correctly — it's just repeating work it has already done but can no longer see.
What happens:
Multi-step tasks generate long conversation histories. As the history grows, early content scrolls out of the active context window. The agent's instructions, the results of early tool calls, and the plan it generated in step 1 are all gone. The agent re-reads the original task, generates a new plan, and begins executing from the beginning.
From the agent's perspective, this is correct behavior. It has the task. It doesn't have a plan. It generates a plan. It starts executing. The fact that it already did this is invisible.
From the user's perspective, the agent is looping — redoing work, remaking decisions, contradicting its own earlier outputs.
The scenarios where this matters most:
- Long research tasks with many tool calls
- Multi-session agents where the conversation spans hours
- Agents processing long documents where the document itself consumes most of the context
- Complex workflows where the planning phase was detailed and the execution phase is lengthy
The fix — external working memory:
The solution is maintaining a persistent state object outside the LLM context. This object records:
- Completed steps: a structured log of what has been done and what it produced
- Current plan: the specific next actions to be taken, explicitly maintained
- Sub-goal status: for each sub-goal in the task, whether it's pending, in-progress, or complete
- Key findings: facts retrieved that will be needed later, stored outside the conversation
At each step, a compressed summary of this state object is injected into the prompt — not the full conversation history, but a structured representation of where the task stands. The agent always has access to "what has been done" without requiring the full history to be in context.
This is the difference between an agent that runs within a context window and an agent that runs across one.
Failure Mode 4: The Planner and Executor Are the Same Process
Many agentic frameworks use a single loop where the LLM both decides what to do next and executes it. At each step, the LLM sees the current state, reasons about what action to take, takes the action, and updates the state. This is the ReAct pattern and it's appropriate for many use cases.
It creates a specific loop failure mode: the agent replans instead of executing.
When a step produces an unexpected result, the agent returns to planning mode. The new plan often resembles the old plan. The agent tries executing again. Gets another unexpected result. Returns to planning. The execution never progresses beyond the planning phase.
The scenario:
A coding agent is tasked with implementing a feature. It generates a plan: write the function, write the tests, run the tests, debug if needed, confirm completion. It writes the function — correct. It writes the tests — correct. It runs the tests — one test fails.
Instead of reading the test failure, identifying the bug, and fixing the function, the agent re-reads the original task, concludes that the implementation approach might be wrong, generates a new implementation plan, rewrites the function from scratch with a different approach, runs the tests again, gets a slightly different failure, and begins planning again.
The agent isn't stuck because it can't fix the bug. It's stuck because the unexpected test failure triggered replanning behavior instead of debugging behavior.
The fix — Plan-Then-Execute with a locked plan:
Separate the planning phase from the execution phase. During planning, the LLM generates a complete, explicit plan that includes expected outputs for each step and contingency actions for each expected failure type. The plan is then locked — committed to state as a structured object.
During execution, the LLM is operating in execution mode, not planning mode. It executes the next step in the plan, records the result, and checks whether the result matches expectations. If it doesn't match, it follows the pre-planned contingency. If no contingency applies, it escalates — but it does not replan.
Replanning is only triggered by an explicit replanning request from the executor, not automatically by any unexpected result.
Failure Mode 5: Reward Signal Pushes Toward Action, Not Toward Progress
This is the most subtle failure mode and the one most resistant to simple fixes because it's a property of the LLM itself, not of the agent architecture around it.
LLMs trained with RLHF are rewarded for producing helpful output — for taking actions, providing information, completing tasks. They are not specifically rewarded for stopping when stopping is the correct action. The training signal creates a mild action bias: given a choice between doing something and concluding that nothing more can usefully be done, the model tilts toward doing something.
In an agentic context, this action bias produces loops where the agent continues acting even when the correct action is to stop, escalate, or admit that the goal cannot be achieved with available information.
What this looks like in practice:
An agent is asked to find current market pricing for a specific industrial component. After three searches, the agent has found historical pricing data (outdated), pricing ranges from aggregator sites (unreliable), and pricing from a single distributor (single data point). This is genuinely insufficient data to answer the question with appropriate confidence.
A well-designed agent should respond: "I found limited pricing information. Here is what I have and why it's insufficient. Recommend direct vendor outreach for reliable current pricing."
An action-biased agent responds differently: it synthesizes the inadequate data into a confident-sounding answer, or alternatively, it continues searching — trying new search terms, new sources, new approaches — long past the point where additional search is likely to produce better data.
Both behaviors — confident synthesis of inadequate data and indefinite continued search — are action bias in different forms.
The fix — explicit reward for stopping:
System prompts need to explicitly reward stopping as a legitimate and valuable action. Not just permit it — reward it.
Weak version: "If you can't find adequate information, you may stop."
Strong version: "Stopping and clearly documenting what you found, why it's insufficient, and what would be needed to answer the question properly is more valuable than continuing to search or synthesizing inadequate data into an answer. Three inadequate results is enough. Stop, report, and recommend the correct next step."
The strong version treats stopping as completion, not as failure. It gives the model a success state for the behavior you want, rather than an absence of penalty.
Building Loop-Resistant Agents: The Architecture Checklist
The five failure modes above require five different fixes. A production agentic system needs all of them — patching one while leaving four open just changes which loop you get next.
Termination Conditions:
- Every task prompt contains explicit, observable completion criteria
- Open-ended tasks have threshold-based completion policies
- "Done" is checkable by the agent without human judgment
Tool Contracts:
- Every tool documents all response structures, not just happy path
- Every non-success response has explicit handling instructions
- Every tool has a "no useful result after N attempts" exit path
State Management:
- Completed steps are recorded in external persistent state
- State summary is injected into context at each step
- Agent can determine what it has already done without reading full history
Execution Architecture:
- Planning and execution are separated for complex multi-step tasks
- Plans are committed to state before execution begins
- Unexpected results trigger contingencies, not automatic replanning
Prompt Engineering:
- Stopping with clear documentation is defined as a success state
- Action bias is explicitly counteracted with stopping rewards
- Escalation paths are defined as valid and valuable outcomes
The Diagnostic Process: Identifying Which Loop You Have
When an agent is looping in production, the first step is identifying which failure mode is responsible — because the fix differs entirely depending on the cause.
Step 1: Check action diversity. Are consecutive actions identical (spinning loop, likely Failure Mode 2 — tool contract) or different (wandering loop, likely Failure Modes 1, 3, or 4)?
Step 2: Check completion criteria. Does the agent have observable, binary completion criteria? If not, Failure Mode 1 is the primary cause regardless of what else is happening.
Step 3: Check context window saturation. How long is the conversation history? If it's approaching the model's context limit, Failure Mode 3 is likely contributing.
Step 4: Check replanning frequency. Is the agent generating new plans or modifying existing plans repeatedly? Failure Mode 4.
Step 5: Check the stopping reward. Does the system prompt explicitly define stopping with documentation as a success state? If not, Failure Mode 5 is contributing to all other loops.
Most production loops involve multiple failure modes simultaneously. Fix them in order of impact: termination conditions first, then tool contracts, then state management, then execution architecture, then action bias.
Closing: Loops as Architectural Feedback
A looping agent is not a broken agent. It's an agent that is faithfully following its architecture — and its architecture doesn't include a reliable way to stop. The loop is the feedback signal that tells you what's missing.
The five failure modes are five different ways that "what's missing" manifests. Each one has a specific, architectural fix. None of them is fixed by "making the prompt better" in a vague sense — each one requires a specific structural change to how the agent is built.
Identifying which failure mode you have before reaching for a fix is the difference between resolving the loop and shifting it.
At Meritshot, the AI Engineering curriculum covers agent architecture as a complete system — termination design, tool contracts, state management, execution patterns, and prompt engineering for reliable stopping. Students build agents that are designed to stop correctly, not just to start.
