Repeated backtracks, many failed subgoals, and a high count of tool calls with poor success rates are the main signs. A busy agent is progressing through a task, while a stuck agent keeps restarting or circling through the same actions. The practical test is whether the trace shows forward motion toward completion or a loop of abandoned sub-goals.
How to tell stalled behaviour from healthy progress in an AI agent
A busy agent still advances the task: it narrows options, resolves uncertainty, or completes substeps in a way that changes the state of work. A stuck agent is different because the trace stops converging. The practical signal is not activity volume alone, but whether repeated actions produce new information, a completed subgoal, or a credible path to completion.
Watch the shape of the execution trace. Repeated backtracks, abandoned branches, and the same tool call pattern without fresh evidence usually mean the agent is looping rather than progressing. A healthy trace may revisit earlier steps, but it should do so with clearer state, fewer open questions, or a completed intermediate result.
Tool count is only meaningful when paired with success rate and task movement. Many calls can be normal for a complex task, but if the agent keeps invoking tools and the outputs keep failing to close a subgoal, the agent is likely thrashing. The most useful test is whether each cycle reduces uncertainty or just repeats the same decision without learning.
What the loop pattern usually looks like in practice
Stuck behaviour often shows up as repeated retries against the same failure point, re-planning from scratch after every minor setback, or oscillating between two incompatible interpretations of the task. In a working run, the agent may branch, compare, and recover. In a stuck run, it keeps restarting because it cannot stabilise an assumption, locate the right tool path, or preserve context across steps.
Another common pattern is subgoal fragmentation. The agent creates many intermediate goals, but none survive long enough to become finished work. That is especially visible when the trace contains lots of partial attempts, repeated clarification of already-known facts, or a growing gap between effort and completed output.
For agent systems, this is not just a productivity issue. It is often a sign that the task framing, tool policy, memory, or permissions are misaligned with the work. A well-designed agent should have enough continuity to either complete the step or fail decisively, not drift indefinitely through low-value motion.
What a practitioner should check before calling it a failure
First verify whether the task itself is genuinely open-ended. Some agent workflows are exploratory by design, so repeated calls can be acceptable when they are narrowing the search space or validating hypotheses. The question is whether the agent can explain why the next action is different from the last one.
Then inspect the control boundary around the agent. If the same state is being retried because the agent lacks the authority, context, or tool access to finish the job, the problem is not just execution quality. In that case the loop is often a symptom of poor delegation design, weak task boundaries, or a missing stop condition.
If you want a broader control lens on autonomy, compare the run against AI Agent Authorisation Guide, which covers task-scoped access and per-action policy decisions. For a deeper view of how agent identity, delegation, and lifecycle affect whether actions stay bounded, see Agentic AI Identity Guide. When the trace itself is the problem, AI Agent Observability, Audit and Incident Response Guide is the most direct reference for signals, attribution, and escalation.
Risk and Threat Considerations
Stalled agents are risky because they can quietly consume time, budget, and rate limits while appearing active. In more serious cases, a looped agent keeps retrying the same unsafe action, repeatedly exposing credentials, or hammering a target system with failed calls that look like automation rather than abuse.
Failure mechanism: The agent cannot converge on a valid next step, so it repeats failed subgoals, replays tool calls, or restarts planning without preserving useful state. That failure mode is amplified when the agent has too much autonomy, weak stop conditions, or poor observability.
Impact: You get wasted compute, delayed task completion, and a larger blast radius if the loop includes destructive tools, privileged APIs, or external side effects. In security operations, the same pattern can also hide compromise, because a malicious or misconfigured agent may look merely “busy” while it is actually churning through unsafe actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI08 — Cascading Failures | Looping agent behaviour can cascade into repeated failed actions and unstable execution. |
| ASI10 — Rogue Agents | A stuck agent with uncontrolled retries can behave outside intended bounds. | |
| Recommendation — Add stop conditions and containment when repeated failures start cascading across agent steps. Detect and disable agents that continue acting without meaningful task progress. | ||
| NIST AI RMF | GOVERN — GOVERN | This is an AI operation quality and oversight problem that needs governance and monitoring. |
| MEASURE — MEASURE | Progress-vs-loop detection depends on measuring task movement and failure rates. | |
| MANAGE — MANAGE | Stuck agent behaviour requires operational response, not just observation. | |
| Recommendation — Define escalation and oversight rules for agents that stop converging on task completion. Track repeated failures, backtracks, and completion rates to distinguish progress from looping. Apply escalation and response procedures when agent traces show persistent non-convergence. | ||
Practitioner Guidance
What to verify: Confirm that the agent can show forward motion in the trace, not just activity volume. A useful threshold is whether each retry produces new information, closes a subgoal, or changes the state of the task in a measurable way.
Decision rule: If the agent repeats the same call sequence after the same failure condition, treat it as stuck and intervene. If it is still producing new evidence, narrowing the search, or finishing partial goals, it is probably busy rather than broken.
What practitioners underestimate: A loop can be a control failure even when the output eventually arrives. If the agent only succeeds after many abandoned branches, the real issue is not task complexity alone, it is that the system lacks a clean convergence path.
Practitioner takeaway: Judge the agent by convergence, not by effort. A healthy run changes state; a stuck run cycles through motion without reducing uncertainty or finishing work.