There is a classic office horror story. Someone hits reply-all on a message to the entire company. Then someone replies-all to say "please remove me from this list." Then forty people reply-all to say "please stop replying all." By lunch, the mail server is sweating.
Now imagine that story with no humans in it.
Two agents, each configured to answer any email it receives. One sends an out-of-office-style acknowledgment. The other acknowledges the acknowledgment. Both are polite, both are tireless, and neither has any idea the conversation has no point. This is not a thought experiment so much as a very predictable failure waiting for the right configuration.
I think agents should get their own inboxes, with their own identity, from day one. Here is the case.
The shortcut everyone takes
The easy path to agent email is the one already open: point the agent at an existing mailbox.
It works in the demo. It even works for a while. And then it starts failing in ways that are hard to trace.
Hazard 1: the shared mailbox is a crime scene
When an agent and several humans all work out of one mailbox, nobody knows who did what.
A shared inbox assumes every actor is a person with a social sense of "someone already got that." Agents do not have that sense. They have a rule, and the rule fires.
Hazard 2: threading breaks quietly
Email threading is held together by headers and by convention. Replies reference earlier message IDs, and clients group on subject lines and those references.
Agents are surprisingly good at damaging this:
The result is that the human on the other end loses the plot of their own conversation. The whitepaper's session model makes the underlying point: conversation context should be maintained by the infrastructure as a thread, not reconstructed by each agent from whatever mail it can see.
Hazard 3: the loop
This is the headline hazard, and it has a simple mechanism.
Agent A sends message to Agent B
Agent B is configured to reply to anything
Agent B replies to Agent A
Agent A is configured to reply to anything
...Illustrative pseudocode. It looks silly, and it happens anyway, because each side's rule is perfectly reasonable in isolation.
Email has defenses, mostly built for older machine-to-machine mess like bounces and vacation auto-replies. There are conventions for marking automatically generated mail and for not auto-responding to it, and well-behaved systems honor them. But those conventions depend on both sides cooperating, and an agent that writes free-form natural-language replies does not necessarily look like an auto-responder to the other agent's filters.
Practical protections, all of which belong at the infrastructure level rather than inside a prompt:
Hazard 4: identity and reputation spillover
If the agent sends from a human's address, recipients cannot tell who they are dealing with. That is both a trust problem and a disclosure problem. It also means a mistake by the agent is attributed to a person.
The reputation side is worse, and it is where the whitepaper is most direct. Inbox providers score sending domains on behavior patterns tuned on human volumes. An agent sending bursts of mail through the company's primary domain can look like abuse, and if the domain's reputation takes the hit, every human at the company pays for it. The paper's own framing is stark: the CEO's email going to spam is the day you discover the problem.
The fix it describes is architectural: a dedicated sending identity for each agent, reputation-isolated from the company's human mail, with its own authentication keys, and with machine-readable headers that say the message came from an agent. Isolation means that if an agent misbehaves, the blast radius is the agent.
What an agent inbox should look like
Pulling it together, a good setup has:
The honest counterargument
"This is more setup than just using support@."
True. It is a few extra minutes at the start. But the cost of a shared inbox is deferred and compounding: a confusing thread here, a deliverability dip there, and one day a runaway loop that costs real money and real embarrassment. The same pattern appears across agent communication: the shortcut is free until it is very expensive.
The takeaway
An agent is a new kind of sender, and it deserves its own address the way a new employee deserves their own login. Give it an inbox, an identity, a reputation of its own, and brakes.
This is the logic behind Dial's email approach as described in the whitepaper: isolated agent identities, managed deliverability, and policy enforced at the infrastructure layer, so a chatty agent cannot take your company's mail down with it.