1. Your Tool Descriptions Are Lying to the Model
This is the most common culprit I see in production ReAct agents, and it’s almost always invisible until you look at the raw traces. If your search_web tool description says “searches the internet for information” but the tool actually scrapes a single internal knowledge base, the model will keep calling it hoping to get the broader result it expected. The loop isn’t a reasoning failure — it’s a contract violation.
Fix this by writing tool descriptions that describe what the tool actually returns, not what you wish it returned. Include failure modes. If the tool returns empty results for out-of-scope queries, say that explicitly. I’ve seen GPT-4o stop looping on a stubborn research agent just by adding: “Returns empty string if no results found. Do not retry more than once.”
2. The Observation Isn’t Feeding Back Into Context Correctly
In frameworks like LangChain and LlamaIndex, the ReAct loop depends on the model seeing its previous thought, action, and observation in each subsequent prompt. When that chain breaks — due to truncation, a serialization bug, or a misconfigured memory buffer — the model re-derives the same action because it genuinely doesn’t know it already tried.
Run a quick sanity check: print the full prompt being sent to the LLM at each step. I’ve debugged loops that turned out to be a max_tokens setting silently cutting off the observation field, leaving the model with an incomplete picture every single turn. Tools like LangSmith and Weights & Biases Weave make this much easier by capturing the full message history per step without manual logging.
3. You Don’t Have a Termination Condition the Model Can Reach
ReAct agents terminate when the model decides to emit a Final Answer. But if your system prompt is too aggressive about thoroughness — phrases like “always verify with multiple sources” or “ensure complete accuracy before responding” — the model will keep searching because it never feels confident enough to stop.
The fix is explicit permission to be done. Add something like: “Once you have sufficient information to answer the user’s question, stop and provide your final answer. One to two tool calls is usually enough.” We’ve seen this single prompt change cut average tool call counts by 40% on internal question-answering agents without measurably hurting answer quality.
4. Tool Errors Are Being Swallowed Silently
When a tool throws an exception and your agent framework catches it and returns a generic "Error occurred" observation, the model has no idea what went wrong. So it tries again. And again. I’ve watched agents loop 20 times on a broken API endpoint because each failed call returned the same opaque error string, giving the model no signal to change strategy.
Surface the actual error type in the observation. “Tool failed: HTTP 429 Rate Limit Exceeded. Retry after 60 seconds.” is actionable. “Error occurred” is not. Better yet, include error handling logic in your tool wrapper that returns structured guidance: what failed, why, and what the model should do instead. Anthropic’s tool use documentation has good examples of this pattern for Claude-based agents.
5. The Model Is Stuck in a Subgoal It Can’t Complete
This one is subtle. The agent has committed to a plan — say, finding the CEO’s email address — and every step it takes confirms that the information doesn’t exist publicly. But the original goal was never updated. The model keeps trying variations because abandoning a subgoal feels like failing.
This is where goal hierarchies matter. If you’re building with CrewAI or AutoGen, structure tasks so that subgoal failure has a defined escalation path: either report the failure and move on, or ask the user for clarification. For single-agent setups, I add an explicit instruction: “If you cannot complete a subtask after two attempts, state what you found and why you could not proceed, then move to the next step.” It gives the model a graceful exit.
6. You’re Not Setting a Hard Iteration Cap (Or It’s Too High)
Every ReAct agent needs a hard stop. LangChain’s AgentExecutor has a max_iterations parameter that defaults to 15. Fifteen. For most tasks, that’s way too many — and it means a looping agent burns tokens and API budget for a long time before you even know something is wrong.
Set your iteration cap based on the actual complexity of your task. A customer support agent resolving common queries shouldn’t need more than 5 iterations. A research agent pulling data from multiple sources might need 10. Log every agent run with its iteration count and look at the distribution. If your p95 is hitting 8 out of a cap of 15, your cap might be masking deeper issues. We set caps low, watch for truncations, and tune up deliberately — not the other way around.
7. The Prompt Doesn’t Define What ‘Done’ Looks Like
Vague task definitions produce looping agents. “Help the user with their question” has no finish line. “Answer the user’s question about product pricing using the pricing tool, then stop” does. The more precisely you define the output format and the conditions for task completion in your system prompt, the less ambiguity the model has to resolve through repeated action.
Before debugging the code, debug the prompt. Write out exactly what a successful run looks like, then check whether your system prompt communicates that clearly to the model. Most looping issues I’ve fixed in the last year started with a prompt change, not a code change.
