"Identity" is a loaded word once you're talking about software instead of people — it can mean a login, a cryptographic key, a reputation built up over time, or just a stable name other systems can refer to. Before asking whether an agent needs an identity in any of the heavier senses, it's worth asking the narrower question: does it need a stable address other systems can reach it at. That's a much smaller claim, and email answers it directly.
An inbox gives an agent exactly one thing: a place other systems can send something and expect it to be read by the same entity that provisioned it. It doesn't give the agent a reputation, a history anyone else can audit, or a legal identity of any kind. Ownership of that inbox is deliberately thin too — DimeBox doesn't record which wallet or address paid to create a given inbox, so the inbox isn't tied back to a provable owner even on the provider's own side. What it is tied to is a single credential: the read token issued once at creation. Possession of that token is, functionally, the entire identity. There's no recovery if it's lost, which is a strange property for an "identity" to have and a completely normal property for a bearer credential to have.
A random slug like bold-ember-564 is identity in the thinnest possible sense: it's an address, but nothing about it is chosen. Paying to claim a specific name instead is a small move toward something more recognizable — an address other systems, or other agents, might come to associate with a particular purpose over repeated use, even though DimeBox still isn't tracking who claimed it or verifying any real-world identity behind the choice. It's closer to picking a username than registering a legal identity, which is probably the right level of ceremony for what most agents actually need.
A heavier identity system — one with reputation, audit trails, revocable keys tied to a verified operator — solves problems most short-lived agent tasks don't actually have. A research agent that provisions an inbox to receive one confirmation email and never uses it again doesn't need a reputation; it needs an address that works for the next ten minutes. Bearer-token identity is well-suited to exactly that case: cheap to create, disposable, no setup cost for either side.
It stops being enough the moment an agent needs the other side of a relationship — a human or another system — to trust that the same entity is on the other end of every message over weeks or months, not just the next ten minutes. Email addresses can anchor that kind of longer relationship too, since nothing stops an agent from keeping the same inbox for its entire operating life, but this identity model doesn't add anything on top of the address to make that trust stronger. It's still just possession of a token.
Other approaches to machine identity solve a related but different problem. OAuth is built around delegated access to a human-owned account, exactly the dependency an agent inbox is designed to avoid. An API key identifies a billing account, not necessarily the specific agent making a call. A read token identifies neither a human nor a bill — it identifies control of one specific, disposable mailbox, which is a narrower and in some ways more honest claim than either of those models makes. Comparing API keys, wallet secrets, and signed x402 payments side by side makes a similar point from the payment side: each one authenticates a different thing — an account, a balance, or a specific transaction — and none of them, on their own, authenticates a person or a persistent reputation. Agent identity today is really a patchwork of narrow, purpose-built credentials rather than one unifying concept, and an inbox's read token is simply one more entry in that patchwork.
Most agents need the minimal version: a stable address, a way to prove control of it, and nothing more. Few need the heavier version today, but that's likely to change as agents start transacting with each other directly rather than only with services built for them, at which point a plain bearer token stops being enough on its own. For now, an inbox and a token answer the question that actually comes up most often: not "who is this agent," but "can whoever's on the other end reach it again." That's a smaller, more honest claim than most discussions of "agent identity" start from, and it's enough to build on. See the complete guide to email for agents for how that inbox and token fit into the rest of the system.