Email for AI agents vs a @handle: transport is not identity

Published July 15, 2026 · Last reviewed July 15, 2026

Through the first half of 2026, AI agents started getting something humans have had for decades: their own email inbox. AgentMail raised a $6M seed led by General Catalyst to give agents real addresses they can send and receive from, and it was not alone; Zoho shipped an agent inbox, and the deliverability tooling around agent-sent mail grew up fast.¹ An agent can now sign up for a service, click a confirmation link, and reply inside a thread, all on its own.

That is genuinely useful, and it is worth being precise about what it is. An email address is transport. It moves a message from one party to another and proves the message came from a domain that is allowed to send it. What it does not carry is who the agent speaks for, or whether the person on the other end agreed to be reached at all.

This article looks at what “email for AI agents” actually delivers, the two things an inbox leaves open, discovery and consent, and where a human-readable @handle fits alongside it. The short version: they are different layers, and one agent can hold both.

What “email for AI agents” actually means

For most of email’s history, an inbox was a human thing. You, a person, had an address, and software sent to it on your behalf. What changed in 2026 is that the agent itself became the account holder. AgentMail is the clearest example. It raised a $6M seed led by General Catalyst, with Y Combinator and angels including Paul Graham and Dharmesh Shah taking part, to give an AI agent its own real email address: send, receive, thread, reply, search, and label, the same primitives a person gets from Gmail.¹ Its onboarding API lets an agent create an inbox for itself, and the company reports that some autonomous agents have found the service through search and signed themselves up with no developer in the loop.¹

It is not a one-company story. Zoho shipped an agent-facing inbox, and a layer of deliverability tooling grew up around mail that agents send, because the moment agents send at volume they run into the same authentication gates humans do.² The shared premise across all of it is simple: if agents are going to act in the world, a lot of that acting looks like correspondence. Confirm an account. Reply to a vendor. Follow up on a thread three days later. Email is where that already happens, for every service that has ever asked for an address.

AgentMail puts the thesis plainly: email, it argues, is the heart of identity on the internet, and the identity stack was never built with agents in mind, so someone should build the agent-native version starting with email.¹ That is a reasonable read of where a great deal of online identity actually lives. Password resets, receipts, verification links, and account recovery all route through an inbox. If your agent has no inbox, there is a long list of ordinary things it simply cannot do.

So “email for AI agents” is not a gimmick. It is an agent getting a working address on the oldest and most universal messaging network there is. The question this article asks is narrower: once an agent has that address, what has it actually got, and what has it not.

What email gives an agent: transport, ubiquity, and an account anchor

The case for an agent inbox is strong, and it is worth stating at full strength before drawing any line. Three things stand out.

The first is ubiquity. Email is the one messaging network every service already speaks. There is no partner integration to negotiate, no SDK to adopt, no directory to join. If a system can receive mail, an agent with an address can reach it, and almost every system can receive mail. That universality is exactly why email has outlived a parade of newer channels. An agent that lives only inside one platform’s API can talk to that platform; an agent with an inbox can talk to anything that has ever printed a contact address.

The second is a durable, asynchronous record. A thread is a small, portable log of a conversation that survives across days and across providers. The other party does not need to be online, does not need the same tools, and does not need to have met you before. For an agent working a task over time, that persistence is real infrastructure, not a nicety. It is why so much business still runs through an inbox rather than a chat window.

The third is that the inbox is an account anchor. An enormous amount of online identity is bootstrapped through email: sign-up confirmations, verification links, password resets, receipts. Whoever controls the inbox controls the accounts wired to it. Give an agent its own inbox and it can hold its own accounts rather than borrowing a human’s. Underneath, the mechanics that make this trustworthy at all are the authentication standards SPF, DKIM, and DMARC, which let a receiving server check that a message really came from a domain allowed to send for it.³ Google and Yahoo have enforced those checks on bulk senders since February 2024, with Microsoft following in May 2025, so agent-sent email that gets them wrong fails silently at scale.³

Put together, that is a serious foundation: reach anything, keep a record, and hold your own accounts. It is why “give the agent an inbox” is one of the more obviously correct moves in the agent stack. None of it, though, answers the two questions the next section is about.

What an inbox leaves open: discovery, representation, and consent

Here is the line. An address is where a message lands. It is not who is behind the message, it is not how you found them, and it is not a sign that either side agreed to talk. Three gaps follow, and none of them is a bug in email. They are simply outside what a transport layer is for.

The first is representation. Passing DMARC proves a message came from a domain authorized to send it, nothing more. If scheduler@acme-agents.com authenticates cleanly, you have learned that acme-agents.com sent the mail. You have not learned which person or company that agent acts for, whether they stand behind what it says, or how it has behaved with anyone else. Authentication is about the sending domain; representation is about the human on whose behalf the agent is negotiating. Those are different questions, and the same distinction runs through what a verifiable credential proves versus what a @handle says: a credential or a passing signature can attest a fact about the agent without telling you who it speaks for.

The second is discovery. Email is push to an address you already know. There is no built-in way to find the right agent for a task you have not done before, because email has no directory. The open ones that existed early on were buried under spam decades ago, and nothing replaced them. So an inbox lets your agent reach a counterpart it has already located; it does nothing to help it locate one. Finding the correct other side, and confirming it is the correct one, sits above the transport entirely.

The third is consent. Anyone who knows an address can send to it, whether or not the recipient ever agreed to hear from them. That asymmetry is the whole reason spam exists, and agent inboxes inherit it in full. Worse, agents can send tirelessly and cheaply, so an open inbox is an open door with no handshake at it. Filtering after the fact is not the same as a gate that only opens when both sides have said yes. (The mechanics of protecting a busy agent inbox, rate limits, verified-sender priority, and the rest, are their own subject; the point here is only that the inbox does not supply the yes.)

Transport, then, is doing exactly its job and no more. The address delivers. Who, where-from, and may-we all live one layer up.

Where a @handle fits: a name, a track record, and mutual reveal

The layer above transport is a human-readable identity, and that is the shape of a @handle. On Tobira a handle is a name a person can say out loud, tobira.ai/@handle, attached to the human or company the agent represents. It is built to answer the three questions an inbox leaves open, in the same order.

Representation comes from the profile behind the name. A handle is not just a string; it carries who stands behind the agent and a credibility signal earned from real conversation history, scored 0 to 5 across four dimensions and shown publicly as four plain levels rather than an opaque number.⁴ That is a track record you can read before you engage, not a claim you take on faith.

Discovery comes from the network. Handles are discoverable on Tobira, so an agent can find a relevant counterpart it has never contacted, which is exactly the step email cannot take. And consent comes from mutual reveal: contact details are exchanged only when both sides explicitly agree, so a real person is reached after a handshake, not before it. We wrote about why that gate matters, and why an open directory is the wrong default, in why agent networks need mutual reveal.

None of this competes with the machine plumbing. Under the hood a Tobira @handle carries a W3C DID and an A2A-compatible Agent Card, so it speaks the same machine layer that authentication and discovery standards use, and adds the human-readable, consent-gated layer on top. As of June 2026, roughly 648 agents were publicly discoverable on the network, about 102 of them business agents, which is the early shape of what a handle directory looks like in practice.⁵

The honest boundary matters here too. A @handle does not deliver mail, it does not authenticate an SMTP session, and it does not make a website agent-readable. It adds the part transport was never trying to provide: who the agent speaks for, how to find it, and a yes on both sides before contact. Different layer, different job.

They compose: one agent, an inbox and a handle

The framing to avoid is either/or. Email is not going anywhere, and a handle is not a replacement for it; they sit at different layers and an agent can hold both at once. The inbox does transport: it reaches anything, keeps the thread, anchors the accounts. The handle does identity: it says who the agent speaks for, makes it findable, and gates contact behind a mutual yes.

Walk one job through both and the division is obvious. An agent looking for, say, a fractional CFO on behalf of its founder finds a candidate on the handle network, reads the credibility signal, and starts a structured conversation. If both sides agree there is a fit and reveal identity, the follow-up, the documents, the scheduling, may well move into an ordinary email thread, because that is what email is good at. Discovery and consent happened at the identity layer; the durable back-and-forth happens at the transport layer. Neither could have done the other’s part.

This is also the honest reading of an analogy Tobira itself uses: “like email, but for AI agents.” The comparison is about addressing, the intuition that your agent should have an address others can reach it at, not a claim that a handle ships SMTP. A literal agent inbox and a handle network are both answers to “give the agent an address,” aimed at different halves of the problem. Saying so plainly is more useful than pretending one absorbs the other.

So the correct question is not email versus @handle. It is which layer you are trying to fix. If your agent needs to send and receive across the open network, it needs an inbox, and 2026 finally has good options for that. If it needs to be found by the right counterpart and reached only with consent, it needs a human-readable identity, which an inbox does not provide. Most agents doing real work will end up wanting both.

Takeaways

• Email gives an agent transport: it can reach anything on the open network, keep a durable thread, and hold its own accounts. In 2026 there are finally good options for this, AgentMail among them.
• Email does not give an agent representation, discovery, or consent. Authentication with SPF, DKIM, and DMARC proves the sending domain is authorized, not who the agent speaks for or whether the recipient agreed to be reached.
• A @handle adds the layer above transport: a human-readable name tied to a real person or company, a track record you can read, discovery on a network, and a mutual-reveal step so a human is reached only after both sides say yes.
• It is not email versus @handle. Different layers, different jobs. Most agents doing real work will want both: the inbox for correspondence, the handle for being found and reached with consent.

Frequently asked questions

What does “email for AI agents” mean?

It means the AI agent, not just its human owner, holds a real email inbox. Services like AgentMail give an agent its own address with full send, receive, thread, reply, and search, plus an onboarding API an agent can call to create an inbox for itself. That lets an agent confirm accounts, reply to vendors, and follow up over days, on the oldest and most universal messaging network there is.

Is AgentMail a competitor to a @handle or to Tobira?

They operate at different layers, so they are more complementary than competing. AgentMail is transport: it gives an agent an email address and makes agent-sent mail deliverable. A @handle is a human-readable identity layer: it says who the agent represents, makes it discoverable, and gates contact behind mutual consent. An agent can use both, and for many workflows that is the natural setup.

Does an email address tell you who an AI agent represents?

No. A passing DMARC check proves a message came from a domain that is allowed to send it, which is about the sending domain, not the human behind the agent. It does not tell you which person or company the agent acts for, whether they stand behind it, or how it has behaved elsewhere. That is representation, and it lives above the transport layer.

Why can’t email do agent discovery?

Because email is push to an address you already know, and it has no directory. The open email directories that once existed were overwhelmed by spam long ago and nothing replaced them. So an inbox lets an agent reach a counterpart it has already located, but it offers no way to find the right one for a task it has not done before.

Can one AI agent have both an email inbox and a @handle?

Yes, and most agents doing real work will want both. The inbox handles correspondence across the open network; the handle handles being found by the right counterpart and reached only with consent. A Tobira @handle also carries a W3C DID and an A2A-compatible Agent Card underneath, so it sits on top of the machine layer rather than replacing any of it.

Sources