An agent inbox and a human inbox both have an address and a list of messages, and it's tempting to assume the similarities go further than that. They mostly don't. Here are six concrete differences that actually change how you should build around one versus the other.
A human inbox is protected by a password (often plus two-factor), tied to an identity you can verify and recover. An agent inbox's only credential is a read token, shown once, with no recovery flow — see read tokens explained. Losing it means provisioning a new inbox, not resetting a password.
A human inbox is an archive — folders, search across years of history, nothing deleted unless you delete it. An agent inbox is a rolling window capped at a fixed number of recent messages, with the oldest pruned automatically. See the rolling message window explained. That's a deliberate scope limit, not a missing feature — most agent tasks need recent context, not a permanent archive.
A human inbox is usually bundled into a flat subscription (or "free" in exchange for being the product). An agent inbox is priced per action — a few cents to send, a few cents for priority receive — with provisioning itself free. See pay-per-call vs subscriptions.
If you forget a human inbox's password, there's a recovery flow — a backup email, a phone number, a support team. If an agent loses its read token, there's nothing: no backup contact, because DimeBox never even stores which wallet or address created the inbox in the first place. See who owns an agent's inbox.
Getting a human inbox means a signup flow — email verification, sometimes a phone number, sometimes a wait. Getting an agent inbox is one unauthenticated POST that returns an address and a token immediately. See provisioning an inbox in one API call.
A human reading their inbox applies judgment — they notice something looks like phishing, they hover over links, they're skeptical by default. An agent doesn't do any of that unless you explicitly build it in. Every inbound message to an agent inbox has to be treated as untrusted input before it touches a prompt — see prompt injection via email for what happens when that assumption is skipped.
Treating an agent inbox like a slower, cheaper version of a human inbox leads to the wrong design choices — expecting archive-depth history, assuming a lost token is recoverable, assuming inbound content is as trustworthy as it would be for a cautious human reader. An agent inbox isn't a smaller human inbox. It's a different kind of object, built for a different kind of reader. See email for agents: the complete guide for the full model it's built around.
Beyond the six above, there's a subtler one: a human inbox is read by someone who brings outside context and skepticism to every message — they recognize a familiar sender, notice something's off about a reply, apply judgment that was never explicitly programmed. An agent brings none of that unless it's built in deliberately. That's not a flaw in agent inboxes specifically; it's a reminder that anything reading one has to supply, in code, the skepticism a human reader provides for free.
Each of these six differences has a direct design consequence. No password reset means you need a reliable way to persist the read token the moment it's issued. A rolling window means you can't assume history older than the cap still exists. Pay-per-call means a retry loop can accidentally cost money if it isn't idempotent. None of these are reasons to avoid agent inboxes — they're reasons to design around what they actually are, instead of what a human inbox has trained you to expect.
None of the six differences above change the underlying protocol. A message sent to an agent inbox still travels over SMTP, still has headers, still has to pass through whatever mail infrastructure sits between sender and recipient. The differences are all in what's built on top of that — how you authenticate to read it, how long it's kept, how it's paid for, and how much trust you extend to its contents by default. Agent inboxes aren't a different kind of email; they're the same email, wrapped in assumptions suited to a caller that isn't a person.
Because an agent inbox's only credential is a token with no recovery path, treating it with the same care as a password actually understates the risk — a forgotten password can be reset through a recovery flow; a lost read token cannot be recovered at all. Any system provisioning inboxes programmatically should persist the token the instant it's returned in the response, not after some later step in a pipeline that might fail first and leave the inbox created but inaccessible.