An agent loop is designed to run until the model returns no tool calls. During a stress test, the loop executes 200 iterations on a complex task without terminating. The model continues generating tool calls indefinitely. What termination conditions should the architect add to prevent infinite loops?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you need multiple independent guards, not one fragile signal. Hard iteration caps catch runaway loops, wall-clock limits catch slow iterations, and repeated-tool-call detection catches models stuck oscillating without progress.
Full Explanation
Robust agent loop termination requires multiple independent guards rather than relying on a single condition. The correct design combines a maximum iteration counter, such as 50 turns, a maximum wall-clock time limit, and detection of repeated identical tool calls within a sliding window, then terminates and surfaces an error if any condition triggers. The iteration counter catches infinite loops directly; the time limit catches loops where each iteration is slow; and repeated identical tool call detection catches the specific pathology of a model oscillating between the same actions without progress. Combining these guards makes termination logic resilient to different failure modes.
The system-prompt instruction to stop after completing the task, with a fallback maximum of 1,000 iterations, is wrong because the stop instruction is already implied by normal agent design and is evidently insufficient when the model cannot determine task completion; a 1,000-iteration fallback is dangerously high and would cause severe cost overruns before triggering.
The token budget tracker that terminates when cumulative input tokens across all turns exceed the model's context window is wrong because tracking cumulative input tokens is useful for context management but not as a primary termination mechanism; a loop making short tool calls could execute thousands of iterations without approaching the context limit.
Routing each tool call result through a secondary Claude instance that evaluates whether the primary agent's task is complete and returns a DONE signal, reducing the primary loop to polling the secondary model, is wrong because it doubles API call overhead and adds latency per iteration; it is over-engineered for what is fundamentally a loop control problem.