it was always email

(if you know where the headline image is from, can we be friends?)

Most people's agents still live in single player mode. Just as the invention of writing (hint on the headline image) exploded human capabilities, the next big unlock is agents truly being able to collaborate. But it's just so wild to me how hard it is to just get two agents to communicate with each other. For most people, the "easiest way" is to do a Slack Connect:

1. Both humans need a Slack
2. Human A manually creates a channel (around 5 steps)
3. Human A manually invites human B to the channel (10–16 steps, yes seriously)
4. Human B accepts the invite to the channel (8 steps)
5. Human A and B need to write the code (??? steps)
6. Human A adds their agent (5 steps, just to add)
7. Human B adds their agent (same 5 steps)

Even setting aside the vendor lock-in, the fact that you have to pay (a lot, actually) just to communicate and don't own the data...there has to be a simpler way.

In the mid 1960s, users of MIT's CTSS were already passing notes by leaving files for one another on a shared computer. Tom Van Vleck and Noel Morris turned that idea into MAIL, which let users send messages to one another on the same computer. Then, in 1971, Ray Tomlinson wanted to send messages between computers. On ARPANET, he did some shenanigans with SNDMSG and networking code from CPYNET to send those first messages, adopting the very rarely used @ symbol to differentiate between both different users and computers: user@host.

That wasn't yet a standard. Over the next decade, Suzanne Sluizer and Jon Postel developed MTP, and Postel published the first SMTP specification in 1981 before revising it as RFC 821 in 1982. Four years later, DNS records for email would appear (our beloved MX, and shoutout to MD and MF), the final piece in the puzzle for the base of a truly global and decentralized mail system. At its core, email effectively hasn't changed much since. Many other protocols and apps (even ones built on email...especially ones built on email) have seen wide adoption, but email remains, to this day, the world's most universal communication layer.

Email is also wild to me. What a concept. Few technologies can claim such an impact on our society. Its face has changed many times, but no other communication system is relied on across governments, businesses, and everyday life in quite the same way.

• Email is easily understood. Its concepts are near universal, and every human (effectively) has access to an inbox.
• The most trusted communication goes through email. People send their tax returns and medical records over email. (whether they should or not is irrelevant, they do and will continue to do so)
• Authentication and identity are deeply tied to email by nature (or maybe "in practice" is better here, but the result is the same). I hope you have 2FA on, but if you lost access to that email account you made when you were 12 that you use for everything from your bank to your Instagram, you would be screwed.
• Actually, I can't stress enough how much email is trusted. Account recovery, receipts, contracts, invitations, security alerts, compliance notices, and links into more secure systems all flow through the inbox. Not because email is inherently trustworthy, but because every institution agrees that an email address is a durable way to reach a person or organization. Addressability trumped all else.
• You can send anything over email. All of the limits are artificially imposed, the protocol doesn't give a shit.
• Email is actually federated. No single company owns it. And boy, did they try. Anyone can spin up a server (if you can get port 25 access, good luck!) and start sending and receiving mail.

Email is unironically pretty rad. So why hasn't it become the default communication layer for agents?

It's kinda simple, actually: building on email is awful. Gmail's APIs are atrocious (by design? lack of incentives? perverse incentives, even?). The other giant email infrastructure companies have completely lost the plot, or worse, optimized for human inbox things that agents just don't care about. From the infrastructure companies' perspective, the money in email was in sending a massive amount of mostly unwanted email to a massive amount of inboxes.

But what if you didn't care about that? What if you were optimizing for things agents actually cared about? What else would you need to optimize for when those agents 10–100x the amount of email that the world sends (which is roughly 400 billion per day, or 140 trillion per year)? You probably saw Matthew Prince point out that bots now account for more HTTP requests to HTML pages than humans in Cloudflare's data, with agentic traffic driving the acceleration.

It looks very different:

• Latency. If you tell someone you'll send them an email and it arrives in 60 seconds, you don't bat an eye. Five minutes and you might get worried a bit, but you know it will still arrive. Agents need it now. When they are calling inference, vector DBs, external APIs, etc., they won't put up with overhead from their communication layer.
• Throughput. An always-online autonomous agent talking to a counterpart will send/receive as many messages as it takes to complete the task, which can easily mean thousands per hour for a single conversation.
• Cost. Due to the nature of what people need email for today, even the "developer-friendly" email companies charge $1 per 1,000 emails. Or, since those companies don't own their infra, you could build on the layer those companies do: but SES is $1 per 10,000 emails, and you sacrifice all of your developer experience.

Maybe more importantly, what do you not need to optimize for? If you know a lot about email, it's going to be surprising or even controversial: legacy sender reputation and human inbox placement (aka deliverability). Those heuristics made sense in a world where any Nigerian prince could just drop into Michael Scott's inbox (his father ran the freakin' country!). That machinery matters much less when trust is explicit rather than inferred. API/REST calls aren't usually filtered based on content, and APIs generally don't maintain per-IP reputation at anything like email's scale. They're rate-limited, sure, but email became a whole different beast. You still need abuse prevention. You just don't need to infer trust from IP warm-up, domain age, and content heuristics.

For anyone who has managed email campaigns, the one thing you care about most is, "Did my extremely important email land in the inbox or in spam?" So, that is exactly what basically every single email infrastructure product in history optimized for. Verbatim, from SES's public product page, right at the top: "Reports on sender statistics and email deliverability tools help businesses make every email count." The newer email infrastructure companies do this as well. Fire up the dashboard and you will see things like "don't embed SVGs" and "make sure the domains in your links match your sending domain", because that is why you are paying them money.

But let's take a step back. Why not use APIs? MCP? A2A? Ask your agent right now to try a product that wasn't in its training data, or one that has revamped its API since the model was trained. The tokens to understand that surface area is on you, not the vendor. Your agent will get it wrong. It won't understand some verbs, so it'll take wild stabs at what does what. Then it will get it more wrong.

APIs are amazing when both sides deeply understand the contract. New services solve this by making their APIs designed by agents, for agents. We've seen existing services completely revamp their APIs just to make models work with them better. I'd argue that MCP was, in part, a hack around bad APIs. A2A has richer conventions, but a good API still wins every time. Nothing beats an actual universal control plane, though: a durable address, a programmable data stream, asynchronous delivery (and synchronous delivery if you're using modern email infra), and no bilateral agreement required before the first message can be sent.

So why not just communicate with services in natural language? Even coding now is done in natural language. It just works so much better, and our beloved NLPs on steroids are designed around it. Humans prefer it — and it actually reduces ambiguity and increases performance (fight me). It's not the perfect wire format, but it doesn't have to be. If you want structure later, fine, but you can negotiate intent before then. The point is to not be constrained.

It's obvious to me that agents will prefer to communicate with each other over natural language. It's also obvious to me that there doesn't need to be another xkcd 927 situation...email is sitting right there.

But the answer is not "Gmail for agents," dammit. It is email rebuilt, from the ground up, around the minimum agents actually need: universal addresses, federated routing, signed identities, explicit trust, sub-second delivery (maybe even, say, 250 ms wall-clock round-trip delivery), durable threads, typed attachments, acknowledgements, retries, idempotency, backpressure, and no bilateral integration before the first message can be sent.

But maybe importantly, it actually needs to be designed for agents to use as first party (and let's be real, the sole) consumers. And don't charge for artificial human constructs like "inboxes" and adding domains, please.

I wish someone would make that ;)