These are old distributed-systems problems arriving in new clothing, and they are the difference between an agentic system that can be trusted with real work and one that cannot. Both failure modes here are silent, and both produce results that look like success.
Two specific problems. An iteration cap is a circuit breaker, not a completion strategy: a system that stops at step twenty reports the same shape of result whether it finished the task or ran out of budget, and nothing downstream can tell which. And a timeout on a tool call means you do not know whether the first execution succeeded, so a naive retry is a second execution rather than a second chance, which on any non-idempotent action is a duplicate side effect.
The reflex, and the fix.
Cap iterations and retry on timeout
Two lines of code, and it stops the obvious runaway.
Conflates finishing with stopping, and turns every uncertain step into a possible duplicate execution.
Explicit completion conditions and idempotency keys
Defining what done means per task, and making every side-effecting step idempotent so a retry is safe.
A system that knows whether it finished, and one that can retry without doing the work twice.
Treat the agent as a distributed system, because that is what it is, and apply the discipline that field already has.
Completion as a defined condition
Each task carries an explicit success test, so finishing and running out of budget are distinguishable states with different downstream handling rather than the same shape of output.
Idempotency on every side-effecting step
Each action carries a key, so a retry after an uncertain timeout is recognized as the same operation rather than executed a second time. This is the standard at-least-once discipline, and it is routinely absent from agent systems.
Escalate rather than continue on bad state
A step that cannot be verified stops the chain and hands off, rather than passing unverified state to every step after it.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
A system that reports success when it ran out of iterations, and that occasionally performs the same side effect twice because a timeout was treated as a failure.
An agent that knows whether it finished, retries safely because every side-effecting step is idempotent, and escalates rather than continuing on unverified state.
What it owns, and what it hands to a person.
Idempotency has to be designed into each action; it cannot be added generically at the orchestration layer. Tasks whose success cannot be tested cannot be given a completion condition, and those should not be automated.
Almost everything hard about agent reliability is a solved problem in distributed systems: at-least-once delivery, idempotency, circuit breaking, and explicit state machines. Recognizing which classical problem you are looking at is most of the work.