Why Your Agent Loops Forever: Termination Conditions in the Agent Loop

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 7)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your agent calls a tool, reads the result, decides it needs more information, calls the same tool again — and again, and again. Ten minutes and forty dollars in API spend later, someone kills the process by hand. Nothing crashed. No error was thrown. The agent just never decided it was done. This is one of the most common failure modes in production agent systems, and it is also a favorite on the Claude Certified Architect exam because it tests whether you actually understand the agent loop or just know the buzzwords.

The one-sentence version: An agent that never stops is missing an exit-guard — the max-step cap and goal check that turn an open-ended loop into a bounded one.

The question

An agent repeatedly calls the same tool and never stops. Most likely root cause?

• A) Model too small
• B) Missing termination/stop condition
• C) Temperature too high
• D) Tool is slow

This is Domain 1 — Agentic Architecture & Orchestration, the heaviest domain on the exam at roughly 27% of the questions. Pause here and pick an answer before you keep scrolling.

The answer

The correct answer is B — missing termination/stop condition.

The agent loop is: think → act (call a tool) → observe (read the result) → think again. That loop is supposed to run until one of two things happens — the agent decides the goal is met, or an external limit tells it to stop. If neither of those checks exists in the orchestration code, the loop has no exit. The model will happily keep calling the same tool forever, because from its perspective each iteration looks reasonable in isolation: it got a result, it’s still not fully confident, so it calls again.

THINK ──► ACT (call tool) ──► OBSERVE (read result) ──► THINK ──► ...
  ▲                                                        │
  │                                                        │
  └────────────────────── loops back ─────────────────────┘

        No exit-guard anywhere in this cycle = infinite loop.

Fix: insert a check after OBSERVE, before the next THINK:

  OBSERVE ──► ◇ max steps reached OR goal met? ──► YES ──► STOP, return answer
                        │
                        NO
                        │
                        ▼
                     THINK (loop continues)

The fix is not a smarter model or a cooler temperature setting — it’s an architectural control that sits outside the model entirely. Two guards, used together, cover the practical cases:

1. A max-step cap. A hard ceiling on how many tool calls (or loop iterations) the agent is allowed to make in one run. When the cap is hit, the orchestrator forces a stop and either returns the best answer so far or escalates to a human.
2. A goal check. After each observation, something — the model itself via a structured “am I done?” judgment, or an explicit success condition in the orchestration code — evaluates whether the task is actually complete. If it is, the loop exits early, before the cap is even reached.

Neither guard lives inside the model’s weights. Both live in the code that wraps the model call — the orchestration layer you design. That is precisely why this is an architecture question and not a prompting question: you cannot prompt your way out of a missing stop condition, because the model has no way to know it should stop if nothing in the system is checking.

Why the other options fail

• A) Model too small. Model size affects reasoning quality, not whether a loop has an exit condition. A frontier model with no step cap and no goal check will loop forever exactly as readily as a small one — it will just produce more articulate tool calls while doing it.
• C) Temperature too high. Temperature controls token sampling randomness — it changes what the model says, not whether the orchestration knows when to stop asking. A repetitive tool-calling pattern can correlate with low temperature (the model keeps converging on the same “call this tool again” decision), but temperature is not the root cause of an unbounded loop, and lowering it does not add an exit condition.
• D) Tool is slow. Latency is an efficiency problem, not a termination problem. A slow tool makes each iteration take longer; it does not cause the agent to decide it needs the same result twice. If anything, a slow tool would make the cost of a missing stop condition worse — you would burn more wall-clock time per wasted call — but it isn’t the reason the loop never ends.

The pattern across all three distractors: they attribute the failure to the model (its size, its sampling temperature) or to an external dependency (the tool), when the actual defect is in the orchestration layer that wraps the model. That is the tell for this entire domain — when a question describes a structural failure (a loop with no exit, a step that ignores feedback, a context window that overflows), the answer almost always points at the architecture around the model, not at the model’s competence.

The concept behind it

Every agent loop is, formally, an unbounded recursive process unless something bounds it. “Agentic” architectures are attractive precisely because the model can decide, turn by turn, whether to keep going — but that same flexibility means the system has no natural stopping point unless you engineer one in. This is different from a single-shot LLM call, which terminates the instant it produces output. An agent loop only terminates when a termination condition fires.

In practice, production agent frameworks combine several guard types, because any single one has failure modes of its own:

The max-step cap and the goal check are the two the exam question is built around, but a repetition detector is worth calling out separately because it targets this scenario precisely — “same tool, called repeatedly” is a pattern you can detect directly (compare consecutive tool-call signatures) rather than waiting for a generic step cap to eventually trip. A well-designed orchestrator layers these: the repetition detector catches the fast, obvious version of this failure; the step cap and cost budget are the backstop for the slower, subtler version where the agent keeps calling different tools without converging.

The deeper architectural point: termination is not something you delegate to the model’s judgment alone. You design it into the loop, the same way you’d design a while loop with a bounded condition instead of while (true) with no break. Treat “how does this loop end” as a first-class question at design time, before you write the first tool integration — not as a bug you patch after the first runaway bill.

FAQ

Isn’t the model supposed to know when it’s done? It often does — a capable model will frequently reason its way to “I have enough information, I should answer now.” But “often” is not “always,” and an architecture that only works when the model happens to behave well is not a reliable architecture. The termination guard exists precisely for the cases where the model’s own judgment fails, loops on ambiguous results, or gets stuck re-verifying something it already confirmed.

What’s a reasonable max-step cap for a typical agent? There’s no universal number — it depends on the task’s expected tool-call depth. A simple lookup-and-answer agent might cap at 5–8 steps; a multi-stage research agent might reasonably need 20–30. The exam-relevant point isn’t the number, it’s that a cap exists at all and that hitting it produces a defined behavior (return best-effort, escalate to a human, or fail loudly) rather than silent, unbounded execution.

Is this the same failure as ignoring tool results? No — they’re adjacent but distinct D1 failure modes. Ignoring tool results means the observation never re-enters the context, so the agent reasons from stale memory (see The Agent Loop Explained). A missing termination condition means the observation is being read correctly, but nothing ever evaluates it against a stop criterion. Both break the same think → act → observe → think loop, but at different points in the cycle.

Does this apply to Claude Code specifically, or agent loops in general? The mechanism is provider-agnostic — any agentic system built on a tool-calling loop needs an exit-guard, regardless of which model sits inside it. Claude Code and similar tools implement their own internal step limits and cancellation controls for exactly this reason. If you’re building a custom orchestration layer on top of the Claude API, the max-step cap and goal check are yours to design.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is question 4 of the Domain 1 practice set — Agentic Architecture & Orchestration, the largest single domain on the exam (roughly 27% of the 60 scored questions, 120-minute proctored exam through Pearson VUE, $125 with retakes available; verify current logistics on Anthropic’s official pages before you register).

Termination conditions are one piece of the loop. If you haven’t yet, work through The Agent Loop Explained: Why Ignoring Tool Results Breaks Your Agent for the observation-feedback failure mode that sits right next to this one, and When NOT to Build an Agent Loop: Workflows vs Agents for the flip side — recognizing when you shouldn’t be looping at all. For orchestration questions involving multiple agents, see The Coordinator-Subagent Pattern.

For the foundational concepts this domain builds on, see MCP Explained on One Diagram and RAG vs Context Engineering. And for the full picture of all five exam domains, start with the Claude Certified Architect (CCA) Exam Guide.

Browse all tutorials for the rest of the series.