Model-driven agent loops and termination anti-patterns

1.Claude chooses the next tool

In an agentic loop, the model decides what happens next. Anthropic's engineering guidance draws the line between two kinds of system. In workflows, LLMs and tools are orchestrated through predefined code paths. In agents, the LLM dynamically directs its own processes and tool usage. A fixed decision tree such as "always search, then fetch, then summarise" is a workflow. The loop in this lesson is an agent: your code runs whatever Claude asks for and returns the result, and Claude decides what to ask for next.

The Agent SDK documentation describes the same split. On each turn, Claude evaluates the current state and decides what to do next, and each set of tool results goes back to Claude for its next decision. Its worked example starts with a request to fix failing tests. Claude runs npm test through Bash and sees three failures. It reads auth.ts and auth.test.ts, edits auth.ts, and runs the tests again. When they pass, it replies with text only. No application code chose to call Read after Bash. The test output led to that choice.

Neither approach is better in every case. The guidance recommends the simplest solution that works and warns that agentic systems often trade latency and cost for better task performance.

Sources123

2.Why text and phrases are bad stop signals

The API already gives you a structured stop signal, so a stop condition built on Claude's wording takes you backwards. The tool-use documentation gives a general rule: if you are writing a regex to extract a decision from model output, that decision should have been a structured signal. Whether the loop is finished is exactly that kind of decision, and stop_reason already carries it. A check for a phrase like "I have completed the task" relies on wording Claude never promised to use. It fails in both directions: the phrase can show up before the work is done, or be missing when the work is finished.

A related mistake treats any text in the response as the sign of completion. Claude can respond with text, with tool calls, or with both in one response. Here a response opens with a sentence of narration and also asks for a tool:

{
  "id": "msg_01Aq9w938a90dw8q",
  "model": "claude-opus-5-5",
  "stop_reason": "tool_use",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "I'll check the current weather in San Francisco for you."
    },
    {
      "type": "tool_use",
      "id": "toolu_01A09q90qw90lq917835lq9",
      "name": "get_weather",
      "input": { "location": "San Francisco, CA", "unit": "celsius" }
    }
  ]
}

A loop that stops when it sees text would quit here, before the weather was ever fetched. The opposite check fails as well. Claude sometimes returns an empty response with stop_reason "end_turn", typically when it judges that the assistant turn is complete, particularly after tool results. A loop that keeps going whenever it finds no text would send that empty response back. The documentation says this doesn't help, because Claude has already decided it is done. Text being present doesn't prove the task is finished, and text being absent doesn't prove it isn't.

Sources214

3.Iteration caps are limits, not stop signals

Caps on loop length do exist. The SDK tool runner accepts max_iterations, and the Agent SDK accepts maxTurns. Look at how the documentation places them, though. The tool runner loops until Claude returns a message with no tool use, or until it reaches max_iterations if you set one. The main condition is a response with no tool calls. The cap is optional.

The Agent SDK spells out what a cap means when it fires. The final ResultMessage has a subtype you should check to see whether the task succeeded or hit a limit. A normal finish is success, described as "Claude finished the task normally". Running out of turns gives error_max_turns, described as "Hit the maxTurns limit before finishing", and in that case no result field is available. Server-side tool loops follow the same pattern. Their internal iteration limit returns pause_turn, and the documentation says a paused turn means the work isn't finished. In both cases a cap interrupts the work. It doesn't complete it.

Caps are still useful as a safety limit. If you take over the tool runner's message history, the documentation tells you to pass max_iterations so the loop stays bounded. You also become responsible for leaving the loop able to exit when there are no tool calls. The tool runner itself runs the loop for you: it executes tools, handles the request and response cycle, and manages conversation state. A hand-written loop is the better choice when you need human-in-the-loop approval, custom logging or conditional execution.

Sources512

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.If the assistant's response contains text, the task is done and the loop can stop.Why is that wrong?

   A response can hold text and tool calls together, and stop_reason "tool_use" means tools are still waiting. stop_reason is the completion signal, not the presence of text.

   Covered in Why text and phrases are bad stop signals

2. 2.Setting max_iterations or maxTurns is how an agentic loop should decide when the task is finished.Why is that wrong?

   The main stop condition is a response with no tool use. A cap is an optional safety limit, and reaching it reports the task as unfinished.

   Covered in Iteration caps are limits, not stop signals