Failure Modes in Agentic Loops

The concrete ways agentic loops break in production, and the anti-patterns the exam expects you to recognize and reject.

Agentic Architecture·Lesson 6 of 6·8 min

Agentic loops fail in a small number of recurring, well-understood ways. The exam tests whether you can spot these failure modes in a scenario description and identify the correct fix, so it's worth cataloguing them explicitly rather than treating "the agent got stuck" as one undifferentiated problem.

Loop control anti-patterns

The most fundamental failure mode is using the wrong signal to control the loop. As covered earlier, stop_reason is the only reliable way to know whether the model is done or wants another tool call. Three specific anti-patterns recur on the exam: parsing the assistant's natural-language text to infer intent instead of checking stop_reason; relying on an iteration cap as the primary way the loop ends, rather than as a safety net; and checking for the presence of text content as a proxy for completion instead of checking the actual stop_reason value. All three substitute a fuzzy, indirect heuristic for a direct, documented signal, and all three fail in scenarios that are easy to construct — truncated responses, mixed text-and-tool-call turns, or unusually-phrased completions.

Runaway loops and cost blowouts

Even with correct stop_reason handling, a loop can fail to converge — the model keeps calling tools without making progress, perhaps because a tool is returning an error it keeps retrying the same way, or because the task was underspecified and the model can't tell it's actually finished. This is exactly what the iteration cap safety net is for: a hard ceiling that terminates the loop and surfaces an error rather than letting it run (and bill) indefinitely. The distinction to hold onto is that the cap being hit is itself a signal something went wrong — it should never be silently treated as "task complete."

Context and state failures

Long-running agentic loops accumulate context. Every tool call and result gets appended to the conversation, and eventually this causes real problems: relevant early instructions get buried or fall out of the effective attention window, token costs climb, and latency per turn increases as the context grows. In multi-agent systems, a related failure is context leakage in the other direction — a subagent given too much of the orchestrator's history can get confused about which parts are relevant to its specific subtask, degrading its output even though nothing about the loop mechanics is technically broken.

Tool-result and error handling failures

A tool call can fail — a bad argument, a downstream service error, a malformed input the model generated. If the loop doesn't feed that failure back to the model as a clear tool_result (including error state), the model has no way to know its last action didn't work and will often either repeat the same broken call or hallucinate a result and proceed as if it succeeded. Correct error handling surfaces the failure explicitly in the tool result so the model can adapt — retry differently, ask for clarification, or report the failure upward — rather than silently swallowing it or crashing the whole loop on the first error.

Exam trap A scenario describes a loop that has been running for many iterations without producing a final answer, and offers "increase the iteration cap" as a fix. This is almost always the wrong answer on its own — a runaway loop is a symptom of a control-flow or tool-feedback bug (bad stop_reason handling, a tool silently failing and being retried, an underspecified task), and raising the cap just delays the failure and increases cost without addressing the cause. The correct answer diagnoses why the loop isn't converging, not how much longer to let it run.

Scenario: An agent calling a file-write tool keeps calling the same tool with the same arguments for ten consecutive turns without the task advancing. Investigation shows the tool is returning a permissions error each time, but the client code was only forwarding successful tool outputs into the conversation and dropping errors, so the model never saw that its calls were failing and had no reason to change approach. The fix is not a larger iteration cap — it's ensuring every tool_result, success or failure, is returned to the model so it has the information needed to adapt.

Try it

Deliberately break a tool in a small Claude Code or API-based agent loop so it always returns an error, but write the client code to silently swallow that error and feed back an empty success result. Watch how many iterations it takes before the loop either stalls or hits your iteration cap, then fix it by forwarding the real error in the tool_result and observe how quickly the model changes its approach instead.