A CrewAI agent keeps calling the same tool and never finishes — which Agent settings bound it?

## The failure being described An agent that repeats a tool call is almost always one that cannot tell it is finished. The tool returns something ambiguous — an empty result, an error string, a page of text that does not contain the answer — and the model, seeing no progress and no stop condition it recognises, tries again. Left alone this consumes tokens, wall-clock time and provider quota. CrewAI gives you four `Agent`-level knobs to contain it and one to observe it. ## max_iter `max_iter` is the maximum number of iterations the agent may perform, defaulting to 20. An iteration is one pass of the agent's loop: think, optionally call a tool, observe. When the cap is reached CrewAI does not throw; it forces the agent to give its best final answer with whatever it has. That behaviour is deliberate — a crew of dependent steps degrades better than it crashes — but it has an important operational consequence: **hitting the iteration cap is silent unless you look**. A task that returns a plausible paragraph may in fact be an agent that gave up. Lowering `max_iter` for a well-scoped agent (five or six is plenty for a single-tool specialist) turns a runaway into a fast, visibly-poor result you can catch in evaluation. ## max_execution_time `max_execution_time` bounds the agent's execution in seconds. This is the cap that matters when the problem is tool latency rather than iteration count: three calls to a slow scraper can outlast twenty calls to a fast lookup. In any crew that runs behind a request or a queue with its own deadline, set this — an unbounded agent inside a bounded caller is how a crew takes down the thing that invoked it. ## max_rpm `max_rpm` limits how many requests per minute that agent may issue. It is frequently misunderstood as a loop guard; it is not. It throttles the rate of the loop, so a runaway agent with a low `max_rpm` runs longer and just as far. Its real job is to keep an agent inside a provider's rate limit, especially when several agents share one API key. Note that it interacts with `max_execution_time`: throttling hard enough can make an agent hit its time bound before its iteration bound. ## cache Tool result caching is on by default (`cache=True`). Identical tool invocations reuse the previous result rather than calling out again. For a literal repeat loop this cuts the external cost sharply, and it makes the loop obvious in a trace — the same call, over and over, returning the same thing. It does not shorten the loop, because the model still spends a turn on each attempt. Individual tools can also declare their own caching policy, which matters when a tool's result is time-sensitive and must not be reused. ## step_callback `step_callback` on the `Agent` is a callable invoked after each step of that agent's execution. It receives the step output — a tool action when the agent decided to call a tool, and the finishing output at the end — which makes it the natural place to emit a structured log line per step, count iterations, push a metric, or detect that the same tool and arguments have appeared N times in a row. A crew-level callback exists too for blanket coverage; the agent-level one is what you reach for when a single agent is the suspect. Together with `verbose=True` during development, it turns "the crew hangs" into a readable timeline. ## respect_context_window Worth knowing in the same breath: `respect_context_window` (default on) keeps the agent's growing message history inside the model's context window rather than letting the request fail. A long loop is exactly what fills a context window, so this is often what stands between a runaway agent and a hard provider error — at the price of the agent quietly losing earlier detail. ## Containment is not a cure Caps buy you a bounded failure. They do not make the agent finish. The actual causes worth fixing are: a tool that returns an unhelpful empty or error result instead of a message the model can act on; a tool description that does not say what the tool cannot do; an agent whose goal has no observable stopping condition; and a missing instruction for the empty case ("if the search returns nothing, report that no results were found"). Fix those and the caps stop firing. ## How to answer this in an interview Name the three caps and be precise about what each bounds — iterations, seconds, request rate. Say explicitly that reaching `max_iter` produces a forced best answer rather than an exception, because that is the detail that shows you have watched it happen. Then close on the diagnosis: caps contain, tool output and stop conditions cure.