An agent finds the answer, calls the tool again, and then announces it has reached its iteration limit. Developers have reported both repeated retrieval without using the result and loops after the answer is already visible. Follow one task from its requested outcome through the tool result to the next decision.

Why does the agent call the same tool after it has the answer?#

Inspect the result the model receives. A successful HTTP request can still produce an empty tool message, a truncated object, an unhelpful serialization, or a response attached to the wrong call.

Then inspect the completion condition. "Research the account" gives the agent no stopping point. "Return the account owner, current renewal date, and unresolved support commitments with their references" gives it a finite job. Once those fields are established, the next step is the answer.

For an account task, record each missing field before the call and each resolved field afterward. If a search fills the renewal date and the next decision searches for it again, you have a precise transition to debug. Save the tool message with the model's next requested action.

Should I increase the iteration limit?#

Increase it only after the trace shows useful progress exhausting a reasonable budget. A public iteration-limit report includes parsing failures, where more iterations buy more failed attempts.

Separate a task budget from a progress rule. The budget caps total calls, elapsed time, and spend. The progress rule asks whether another call can resolve a named uncertainty.

Trace pattern	Next investigation
New records on every page	Pagination needs a larger, capped budget
Same error and unchanged arguments	Fix the input or stop the retry
Answer present, another identical search	Inspect result delivery and completion routing
Different queries, same documents	Check whether search is adding evidence
Repeated status reads on one unfinished job	Treat as capped polling

LangChain's middleware documentation describes model-call and tool-call limits. Use the controls for your installed version, since an old AgentExecutor example and a current agent middleware example are different APIs.

How do I stop repeated calls without breaking polling?#

Do not stop on the first repeated argument set. A developer reported this false-positive problem with loop detection: intentional verification was treated as a loop.

Assign each call a purpose:

A status poll identifies an existing job, has a next-check time, and ends on a terminal state or deadline.
A read after a write identifies the expected change.
A research retry explains what new evidence it expects.

Make the repeated-call decision depend on that purpose, observed progress, and remaining budget. Canonicalized arguments catch literal repeats but are insufficient alone. Two searches can differ in wording and return the same evidence, and the same read can return a changed deployment state.

Why does a parsing error turn into another tool call?#

A recovery path sends an error back to the model and asks it to try again. If the expected output format is still unclear, the same recovery repeats.

Capture the first malformed response, the expected schema, the parser error, and the first repair attempt. Return a specific correction, such as a missing required field, instead of "try again." Give repairs their own small budget. When it ends, return the partial result and the exact unresolved field to the caller.

Do not convert malformed output into an empty successful answer. That erases the difference between "nothing was found" and "the result could not be read," and sends the agent back to search again.

What should the agent return when it cannot finish?#

A useful response contains the established facts, references, remaining uncertainty, and why it stopped. A generic iteration-limit sentence forces the next person to repeat the investigation.

Use a task checkpoint like this:

Goal: prepare the Acme renewal brief
Established: account owner and renewal date
References: account record and signed agreement
Unresolved: support has not confirmed the escalation owner
Stopped because: repeated search produced no new evidence
Next action: ask support to name the escalation owner

Test the successful answer, an empty result, a malformed response, a changing status poll, and the same documents under different search terms. Assert that the agent stops with useful work intact.

For calls routed through Deixic, the action history records decisions and results so you can find the repeated step, and evaluations replay sessions as scenarios to revisit failures.

Find another symptom in the agent troubleshooting question index.