Because the model is stateless and each request re-sends the entire history. Iteration 10 includes the system prompt, all tool definitions, and every thought, action, and observation from iterations 1 through 9. Input tokens therefore grow with each step, and you pay the accumulated total every time. The cost curve is closer to quadratic than linear, which is why keeping runs short matters more than it first appears.

No — the cap is doing its job by revealing a problem. Hitting it means the agent could not decide it was finished, and giving it more iterations usually just costs more before failing the same way. Look at the traces: it is typically an unclear definition of done, a tool returning something the agent cannot act on, or the same call repeating. Fix the termination condition; keep the cap as a safety net.

Because the reasoning text becomes part of the context the next decision is made from. Committing to an explicit rationale before choosing an action measurably improves the choice, and it also gives later iterations something concrete to check against. The readable trace is a genuine second benefit — it is most of your debugging ability — but the decision-quality effect is the reason the pattern exists.

In the tool's error handling, not the agent. A bare empty result or an unstructured error string arrives in the context looking exactly like a legitimate observation, so the agent reasons from it as fact. The fix is to return something explicit and actionable — "query failed: region 'EU' not recognised, valid values are Europe, Americas, APAC" — which lets the agent correct itself instead of drawing a false conclusion.