An agent retry loop can become an outage.
That is not an intelligence problem. It is a systems problem.
I have seen ordinary services take down their own dependencies with bad retries. Agents make that failure mode easier to disguise, because the behavior looks "smart" right up until it floods something.
Think about what an agent actually does under the hood: it calls tools, reads state, retries on failure, runs in parallel with other agents and humans, and resumes work after interruptions. Every one of those is a distributed-systems problem we already know is hard. A flaky tool call should not replay five successful steps. Two agents editing the same record should not silently overwrite each other. A retry on a rate-limited API should back off, not hammer. None of that is solved by a better model — it is solved by durable execution, idempotency, row-level claims, and backpressure. The intelligence plans the work; the runtime has to survive it.
The uncomfortable part: a smarter agent does not reduce these risks, it raises them. It takes more actions, touches more systems, and runs longer, which means more chances to trigger exactly the failure modes ordinary distributed systems spend years hardening against. We are handing production authority to actors that act faster than the runtime underneath them was designed for.
The agent does not get a pass on distributed-systems basics. If anything, it needs them more.
The smarter the agent becomes, the more seriously we have to engineer its failure modes.