Cost, latency, and the danger of an agent that just keeps trying
Every tool call and every loop iteration is a separate call to the model, and each of those calls costs money and takes time. In a prototype, running a few extra iterations while the agent 'figures things out' feels harmless. In a shipped product handling real traffic, an agent that keeps retrying, second-guessing itself, or making exploratory tool calls until something works can quietly turn into a very expensive or very slow system, even if it eventually gets the right answer every time. That's not just an implementation detail to optimize later, it's a design constraint that has to shape decisions like the iteration limit, which tools are available, and how aggressively the agent is allowed to retry a failed action, from the start.
Getting this right usually means thinking about cost and latency budgets the same way you'd think about a memory or bandwidth budget in other software: deciding upfront roughly how many tool calls a typical task should reasonably take, and treating an agent that regularly blows past that budget as a signal something needs fixing, whether that's a tool description, a prompt, or the loop's stopping conditions, rather than something to quietly accept because the agent 'got there eventually.'