Watch for rising step counts, repeated tool errors, context-window saturation, and token burn that is far above the expected baseline for the task. Those are the earliest signs that the agent is looping or compensating for confusion. When those signals rise together, the session is no longer trustworthy enough to treat as routine automation.
What degradation looks like before the agent fully fails
A coding agent usually degrades first as inefficiency, not as a hard outage. The earliest pattern is a shift from “one task, a few steps” to “the same task, many more steps,” often paired with repeated retries, awkward tool calls, and wandering edits. That matters because the agent may still produce output while its internal confidence and control are eroding.
When teams watch this class of drift, they are looking for a change in behaviour relative to the task baseline, not a single bad turn. A healthy agent should usually settle on a compact path for a bounded coding job; when it starts thrashing, the issue is often confusion, lost context, or an unsafe attempt to compensate.
At that point, the useful question is not whether the code exists, but whether the session still deserves automation trust. The answer depends on whether the agent can still explain, plan, and execute without repeatedly re-deriving the same context.
Which signals matter most in production
The most practical signals are the ones that show the agent is burning effort without making progress: step count inflation, repeated tool errors, context-window saturation, and token use that is far above the normal range for the same class of task. Those signals often travel together, and the combination is more important than any one metric in isolation.
Step inflation usually means the agent is looping through the same reasoning or tool sequence. Repeated tool errors suggest the agent is misreading tool output, using the wrong arguments, or failing to adapt after a failed call. Context saturation shows that the model is pushing against its working memory and may be dropping earlier instructions or code state. Token burn is the clearest cost signal, but it is also a trust signal when it rises without a corresponding increase in useful progress.
A team should compare those signals against a task-specific baseline, because “normal” for a refactor is not the same as “normal” for a small patch. If the agent suddenly needs far more turns than similar jobs, that is often the first observable sign that the workflow has become unstable.
How to tell drift from an expensive but valid task
Not every long session is degradation. Some tasks are genuinely complex, especially when the codebase is large, the test surface is broad, or the requested change crosses multiple files. The distinction is whether extra work produces new information and progress, or whether the agent is merely revisiting the same dead ends.
A trustworthy session keeps moving toward a better model of the task: fewer contradictions, fewer repeated tool failures, and clearer alignment between requested change and executed steps. A degrading session tends to flatten out, with the same search patterns, the same broken assumptions, and little evidence that the agent is learning from prior failures.
That is why teams should track both output quality and process quality. If the code appears to improve but the agent’s path is getting noisier and more resource intensive, the session may still be successful today while becoming unsafe to rely on tomorrow.
Risk and Threat Considerations
When a coding agent starts looping or exhausting context, the immediate risk is not just wasted compute. Degradation can hide partial failures, make the agent more likely to miss constraints, and increase the chance that it will take unsafe shortcuts, especially in environments where tool access is broad.
Failure mechanism: As the working context fills up or the task becomes confused, the agent may replan poorly, repeat failed tool calls, or continue with incomplete state, which raises the odds of incorrect changes, missed safeguards, or unintended side effects.
Impact: Teams can see higher cost, slower delivery, and lower confidence in the session’s output, but the more serious consequence is that an apparently active agent can still produce changes that are no longer well grounded in the original task.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI08 — Cascading Failures | Looping and context loss can cascade into broader agent failure modes. |
| ASI02 — Tool Misuse | Repeated tool errors often indicate the agent is using tools incorrectly or out of sequence. | |
| ASI06 — Memory & Context Poisoning | Context saturation and confusion directly affect the agent's working state and memory. | |
| Recommendation — Detect rising retries and halt sessions before degraded agent behavior spreads into unsafe actions. Review tool-call failures and constrain tool use when the agent starts misfiring. Monitor context pressure and reset or segment sessions before state quality collapses. | ||
| NIST CSF 2.0 | DE.CM-01 — The organization monitors networks and systems to detect anomalous activity. | Production telemetry is needed to detect abnormal agent behavior and degradation. |
| RS.CO-02 — Incidents are reported consistent with criteria. | Degraded agent sessions need escalation criteria when they stop being trustworthy. | |
| Recommendation — Instrument agent telemetry so abnormal step growth and token burn are visible. Define escalation thresholds that trigger human review for unstable agent sessions. | ||
Practitioner Guidance
What to verify: Set a baseline for step count, tool-error rate, and token use by task type, then compare each live session to that baseline rather than using one global threshold. A sudden rise across all three signals is a stronger degradation indicator than any single metric.
Decision rule: If the agent crosses the baseline and cannot recover after one corrective retry, stop treating the session as routine automation and require human review before further changes are accepted. That is especially important when the agent has write access to production-adjacent code or deployment tooling.
Practitioner takeaway: The key judgment is not whether the agent is still producing output, but whether it is still progressing with enough efficiency and state coherence to deserve trust.
Related resources from NHI Mgmt Group
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams handle AI agent visibility?
- How should security teams monitor AI agent activity without disrupting developers?
- How do security teams know whether a coding agent is really in privacy mode?