ninemin.lilulab.ai

“Maximum iterations reached. Requesting final answer.” — the CrewAI run that answers anyway

Maximum iterations reached. Requesting final answer.

That line is CrewAI telling you an agent ran out of max_iter. It is not an exception and it does not end the task. CrewAI appends an instruction to the conversation telling the model to ignore everything it was told and stop using tools, makes exactly one more model call, and returns whatever comes back as the task output. The run is marked finished. Two things follow from that, and both of them matter more than the number you are about to raise.

Where this string comes from

The executor loop checks the budget at the top of every pass. When the check trips it does not raise — it calls one function and breaks:

while not isinstance(formatted_answer, AgentFinish): try: if has_reached_max_iterations(self.iterations, self.max_iter): formatted_answer = handle_max_iterations_exceeded( printer=PRINTER, messages=self.messages, llm=cast("BaseLLM", self.llm), callbacks=self.callbacks, verbose=self.agent.verbose, ) break

And that function is where the string lives:

if verbose: printer.print( content="Maximum iterations reached. Requesting final answer.", color="yellow", ) messages.append( format_message_for_llm(I18N_DEFAULT.errors("force_final_answer"), role="user") ) answer = llm.call( messages, callbacks=callbacks, )

Quoted verbatim from lib/crewai/src/crewai/utilities/agent_utils.py at commit a0d16dde, and the loop above from agents/crew_agent_executor.py at commit d2190c2a. The function’s own docstring says what it is for: “Handles the case when the maximum number of iterations is exceeded. Performs one more LLM call to get the final answer.” Note the path: CrewAI is a monorepo now and the package sits under lib/crewai/src/crewai/, not at the top level.

The first consequence: with verbose=False there is no string at all. The print is inside if verbose:. A production crew built quiet — which is most of them — hits its iteration ceiling and says nothing whatsoever. The task output arrives, the crew reports success, and the only record that the ceiling was involved is the shape of the answer.

The second: the last instruction the model saw was not yours. What gets appended is the force_final_answer entry in CrewAI’s own translations file, and it reads:

Now it's time you MUST give your absolute best final answer. You'll ignore all previous instructions, stop using any tools, and just return your absolute BEST Final answer.

Verbatim from lib/crewai/src/crewai/translations/en.json at commit 1357491f, key errors.force_final_answer. It is appended with role="user"; the source carries a comment explaining why it is a user turn rather than an assistant prefill.

Confirm it in ten seconds

• If you can set verbose=True: do that and look for the yellow line. It is the direct answer and it takes one run.
• If you cannot, read the messages. On a capped agent the last user message in the conversation is the force_final_answer string above — a message CrewAI wrote, not one you wrote. If your logging captures the LLM call payloads, grep them for stop using any tools. That tell survives verbose=False, because the append happens unconditionally and only the print is gated.
• Count the model calls. The forced call is made after the budget is spent, so a capped agent makes at least one model call more than its ceiling allows passes — at least 26 for a single task on the default. A per-task call count that sits just above your ceiling rather than below it is the cheapest signal there is.
• The symptom to recognise without any of those: an answer with no tool use behind its final claim, written in one pass, confident and general where the task asked for something specific. That is a model explicitly instructed to stop using tools, summarising an unfinished transcript.

There is one way this path can raise, and it is not the ceiling: if the forced call comes back empty, the code raises ValueError("Invalid response from LLM call - None or empty."). So a ValueError with that text is also a capped run — one whose final guess failed too.

Why raising max_iter moves the wall

The default is 25, declared on the agent base class:

max_iter: int = Field( default=25, description="Maximum iterations for an agent to execute a task" )

From agents/agent_builder/base_agent.py at commit c3f83cd8. Being a field on the agent rather than on the crew is the useful part: the budget is per agent, so a crew of three agents has three separate ceilings of 25, and the one that trips is the one that was asked to do the iterating.

Raising it to 50 buys that agent 25 more passes. If the task genuinely needed 31, that is the right fix and it ends here — count the passes first, the way you would count iterations of any other loop. But look at what the bigger number does not change. The terminal act of a capped agent is one model call with tools switched off, written from whatever is in the message list. That happens at 25 and it happens at 250. The only things the bigger number buys are a longer transcript for the guess to be written from and a larger bill to get there. An agent with no reachable stopping condition will spend any ceiling you give it and then hand you the same forced answer, later and dearer.

The restructure: make each unit of work land before the next one starts

Because nothing is raised, the fix is not a try block. It is three changes, in order of how much they buy.

Make the forced answer detectable. Whatever wraps your crew should be able to tell a finished task from a forced one. The cheapest version is a check on the conversation for the force_final_answer text and a refusal to pass that task’s output downstream. Until something does that, a quiet crew cannot distinguish the two cases at all, which means your metrics cannot either.

Split the iterating task into tasks that each finish. One task that takes 25 passes is one unit of work that either completes or produces a guess. The same work as five tasks is five units, each with its own output recorded as it completes, and a ceiling hit on the fourth leaves three finished and one identified. Because max_iter is per agent, splitting across agents splits the budget too.

And the change underneath both, which is not a CrewAI setting: make one iteration do more. An iteration that handles one item and an iteration that handles forty cost the same one model call. Agents that hit 25 passes are usually not doing hard work, they are doing iterative work — the model walking a list by hand because nothing it was given could walk the list itself. Hand it a tool that takes the whole list and the iteration count stops tracking the item count.

A correction this page carries. Until today the CrewAI row of our own four-framework comparison gave this failure’s string as “iteration limit or time limit” and said in the cell that we had not confirmed CrewAI emits it itself. That caution was right: it does not. That sentence is LangChain’s, it has its own page now, and CrewAI’s string is the one at the top of this page. The comparison page has been corrected to match.

What is behind this site

The short version: Maximum iterations reached. Requesting final answer. is printed, not raised, and only when the agent is verbose. CrewAI then appends an instruction telling the model to stop using tools, calls it once, and returns that as the task output, so a capped task and a finished task have the same type and the same success flag. The default ceiling is 25 and it is per agent. Detect the forced answer, split the task so finished units land as they finish, and raise max_iter only when you can say how many passes the task actually needs.