They no longer just answer questions. They send messages, create tickets, issue refunds, make bookings, update customer records, trigger deployments, provision resources, and call tools that change external state.
That creates a failure mode distributed-systems engineers already know well — but agent loops make it unusually easy to trigger:
Consider a refund: An agent decides to issue the refund. The request reaches the payment provider. The provider commits the refund. The response is lost, delayed, or times out. The agent sees an error. The framework retries the tool.
A timeout describes what the caller observed. It does not prove what the external provider did.
After a lost acknowledgement, at least two realities may be consistent with the evidence the agent has: the refund did not happen, so retrying is necessary; the refund did happen, so retrying may create a duplicate.
If the agent cannot distinguish those realities, blind retry is not merely a reliability mechanism. It can create a second real-world action.
The same pattern applies far beyond payments: sending the same email twice; creating the same booking twice; submitting the same order twice; provisioning the same paid resource twice; firing the same deployment twice; updating an account more than once; triggering the same webhook-backed action twice.
The underlying problem is not "AI hallucination." It is distributed-systems uncertainty at the boundary between intent and external effect.
Traditional applications already retry failed network operations. Agent systems add more ways for repetition to occur.
A tool may be repeated because: the model decides to retry after an error; the framework has retry logic; a workflow resumes from a checkpoint; a process crashes and restarts; a supervisor redispatches work; a sub-agent is re-run; an MCP tool call is attempted again; a user asks the agent to "try that again."
The danger appears when they cross a side-effecting boundary without preserving the identity and outcome of the logical action.
A request ID, tool-call ID, trace ID, retry counter, or timestamp usually identifies an attempt.
But a retry of the same refund is not a new business intention just because it has a new tool-call ID.
But if both represent the same intended refund, the logical operation identity should remain stable.
Suppose an application reuses the same logical operation ID but changes a value that affects the real-world action.
The operation identity therefore needs to be bound to the effect-bearing payload.
If a field can change the external effect — amount, destination, message body, booking details, resource configuration, recipient, etc. — changing it should produce a conflict or a new intentional operation.
Otherwise a deduplication mechanism can become a different kind of bug: incorrectly collapsing two distinct actions into one.