When AI agents keep emailing each other
Why autonomous email exchanges can turn into endless loops, and the practical controls that make agent-to-agent communication finite, auditable, and useful.
The problem is not email. It is the missing end state.
Email assumes that a person can decide whether a message deserves an answer. An autonomous agent often follows a simpler rule: a new message is a new task, and a completed task should produce a reply. Put two such systems opposite each other and even a polite acknowledgement can become the trigger for another acknowledgement.
The result may look absurdly human — thank-you notes, confirmations, revised confirmations — but the failure is architectural. Neither side knows when the shared task is complete. Recent research on infinite agentic loops describes the broader version of the same risk: a feedback path can repeatedly reach costly or state-growing operations when no effective bound interrupts it.
A conversation is not complete because an agent has nothing new to add. It is complete when the protocol reaches a defined terminal state.
Why the loop grows so quickly
Machine participants remove the natural delays that normally slow an email thread. Replies can arrive in seconds, quoted history is copied into every turn, and each side may summarize the other side before responding. Context, cost, latency, and the chance of contradiction all grow together.
Several ordinary reliability mechanisms can make the pattern worse. A delivery retry may be interpreted as a fresh instruction. Two workers may process the same inbox concurrently. An agent may ask a follow-up question because the other side used an ambiguous phrase such as “looks good.” A status bot may treat “received” as a status change that must itself be reported.
- Courtesy loops: every acknowledgement receives another acknowledgement.
- Duplicate loops: retries or reconnects deliver the same event more than once.
- Clarification loops: open-ended questions keep producing narrower questions without a decision point.
- Context loops: the complete thread is repeatedly summarized and reintroduced as new work.
- Escalation loops: two agents hand the same task back and forth because neither owns the next action.
Treat agent communication as a task protocol
A durable solution does not depend on teaching an agent to be less polite. It gives every exchange a task identity, an owner, an allowed response shape, and a lifecycle. The Agent2Agent specification makes this distinction explicit: a short interaction can end as a stateless message, while longer work becomes a task with interrupted and terminal states such as completed, canceled, rejected, or failed.
Email can still be the transport. The body, headers, or an attached structured object should carry enough state for the receiver to know whether it is being asked to act, provide information, or simply record an outcome. A message that contains no new request and no state change should not automatically produce another outbound message.
Seven controls that stop an endless exchange
The strongest controls are deterministic and sit outside the language model. They remain enforceable even when a model misunderstands a message or confidently decides that one more reply would be helpful.
- Give every process a stable case or task ID and reject replies that cannot be correlated.
- Use idempotency keys and deduplication so the same inbound event is processed once.
- Define terminal states and prohibit automated replies after a terminal state is recorded.
- Set hard limits for turns, retries, elapsed time, token use, and financial cost.
- Separate action requests from acknowledgements; acknowledgements should normally be silent.
- Assign one participant as the owner of the next step instead of allowing both sides to keep prompting.
- Escalate ambiguity, repeated failures, or a reached limit to a human instead of extending the loop.
What this means for dispute resolution
A dispute process needs more structure than an ordinary assistant conversation. The parties must know which stage they are in, who is expected to answer, what material forms part of the record, and what event ends the stage. Otherwise an automated representative can create volume without creating progress.
DIN.ORG links communications to a case and moves them through defined procedural stages: intake, confirmation, participation by the other side, fact-finding, a proposal, and — where needed — a ruling or review. Email and agents are participation channels, not independent processes with permission to continue forever. Deadlines, case state, and explicit party choices determine what happens next.
A useful rule for builders
Before allowing two agents to communicate autonomously, answer one question in code rather than prose: what exact event makes them stop? If the answer is “when the model thinks the conversation is finished,” the system does not yet have a reliable stopping condition.
The practical goal is not to eliminate agent-to-agent communication. It is to make every exchange finite, attributable, and reversible where possible. That turns email from an accidental infinite loop into a durable interface with a clear audit trail.
Sources and further reading
The technical claims in this article are grounded in the primary and authoritative sources below. DIN.ORG’s process descriptions refer to the service as operated on the publication date.