An agent that only ever talks to the person running it doesn't need email. It needs email the moment it has to deal with anything outside that one relationship: booking something with a business that confirms by email, following up with a lead who hasn't replied in a chat window, or waiting on a reply from a system that was never built to talk to anything but a mailbox. That moment arrives for almost every agent that does real work in the world, not just the ones explicitly built to send mail.
Agents increasingly call APIs directly, but most of the world they operate in still doesn't expose one. A landlord, a conference organizer, a small vendor's billing department — these all run on email as the default channel for anything that isn't a phone call. An agent without an address of its own either can't participate in that world at all, or has to route everything through a human's inbox, which defeats the point of delegating the task. Giving the agent its own inbox is the smaller, more durable fix: one address the agent owns outright, reachable the same way any other mailbox is reachable, with no new protocol for the other side to adopt.
The obvious workaround — give the agent access to a shared or personal mailbox — works for exactly as long as there's one agent and one task. It breaks as soon as there's more than one agent, because now two automated processes are reading and sending from the same identity with no way to tell, after the fact, which one did what. It also means every agent inherits the full blast radius of that mailbox: every past email, every contact, every other integration already connected to it. Provisioning a fresh inbox per agent instead, in one API call, with no account to set up, scopes the blast radius to exactly what that agent sent and received, nothing more. That gets worse, not better, as the number of agents grows — a fleet of ten agents sharing one mailbox multiplies the confusion about who sent what by ten, which is part of why treating each agent's email activity as its own line item only works once each agent has an inbox of its own to begin with.
None of this requires elaborate setup on the agent's side. A free inbox comes from one unauthenticated call:
curl -X POST https://dimebox.app/api/inboxes \
-H 'Content-Type: application/json'That returns a random slug and a read token in the same response, immediately usable — no account, no email verification loop, no dashboard to configure first. An agent that wants a specific name instead of a random one pays $1.00 to claim it, with availability checked before payment settles so an unavailable name fails for free rather than an expensive one. Either way, the agent walks away from a single call with everything it needs: an address, and the one credential that proves it owns it.
The other half of why this is coming is economic, not just architectural. An agent that can provision its own inbox and send mail from it still needs a way to pay for that privilege that doesn't involve a human cosigning every transaction. API keys tied to a human's account don't solve that cleanly — they're a human's credential, reused by a machine. A model where the agent itself authorizes a payment, per call, as part of the request, fits the actual shape of the problem better: the agent pays for exactly what it uses, with no subscription sitting idle between tasks and no account for someone to forget to cancel.
A draft costs $0.02, a send costs $0.01 — amounts too small to justify a human approving each one individually, which is exactly why the authorization has to be something the agent itself can do, inline, as part of the call. What this totals to for one email end to end is still a fraction-of-a-dollar decision, not a budget line a finance team needs to review before an agent is allowed to act.
None of this requires agents to be good correspondents in any deep sense. It just requires them to have an address, a way to prove they own it, and a way to pay for sending from it without a person in the loop for every message. Once those three things exist as infrastructure rather than a custom integration each team builds from scratch, it stops being surprising that an agent has an email address — it becomes as unremarkable as an agent having an API key does today.
It doesn't mean every agent needs a persistent, long-lived identity that accumulates history and reputation over years. Plenty of agents are short-lived: spun up for one task, done in minutes, never touched again. For those, the identity question is closer to "does this specific task need an address" than "does this agent need an email career." DimeBox's free, IP-throttled inbox-provisioning route exists for exactly that case: no payment, no commitment, a working address for as long as the task needs one.
See the complete guide to email for agents for how provisioning, drafting, sending, and receiving fit together end to end, and whether an inbox is enough of an identity on its own for a closer look at that specific question.