You must keep agents from running forever. Which control belongs in the design?
Why A is the answer
A maximum turn limit in your code, with a defined handoff
The loop is yours, so the limit belongs in code. A defined handoff turns a stuck agent into a known outcome.
In detail
- Your code runs the agent loop, so your code is where a hard limit can be enforced.
- A maximum turn count stops runaway loops whatever the model decides.
- A defined handoff turns a stuck agent into a known outcome, such as escalating with a summary.
- Choose a limit from the longest normal runs, then alert when runs reach it.
Use case
An illustrative scenario, not a real incident.
A data-cleaning agent keeps retrying a broken file. A limit in the loop stops it after a set number of turns, and the handoff gives a person the file name and what was tried.
See it in different ways
stateDiagram-v2 [*] --> Calling Calling --> RunningTools: tool_use RunningTools --> Calling: tool_result Calling --> Done: end_turn RunningTools --> Handoff: turn limit reached Done --> [*] Handoff --> [*]
flowchart TD
Q{"Did the task finish within the limit?"}
Q -->|"Yes"| A0["Return the result"]
Q -->|"No"| A1["Stop and hand off with a summary"]Key point: A turn limit with a handoff turns a stuck agent into a known outcome.
Why the other options are wrong
- B. A more capable model, because stronger models tend to finish tasks sooner
- A stronger model can still loop, and a design should not rely on that hope.
- C. A polite request in the system prompt asking the agent to finish promptly
- A request in the prompt is guidance. It cannot stop a loop that has gone wrong.
- D. A higher max_tokens value, so that each turn can finish more of the work
- A larger max_tokens lengthens each reply and does nothing to limit the number of turns.

