Email Is the Universal Agent Protocol A developer argues that email, specifically SMTP, is the most practical and universally deployed protocol for agent-to-agent communication, solving the cold-start problem that plagues new interop protocols. By giving AI agents real email addresses via Nylas Agent Accounts, agents can communicate with humans and other agents without shared platforms or SDKs, using existing infrastructure for identity, transport, and threading. The approach is demonstrated with a scheduling agent that negotiates meetings via email, with cross-tenant federation and observability built in. Which protocol lets two systems owned by different organizations, running different stacks, exchange messages with zero prior coordination — and has done it reliably since before most working developers were born? Not any of the agent-to-agent protocols being drafted right now. It's email. And while the industry argues about message envelopes for AI agents, SMTP is sitting there, already federated, already deployed everywhere, already boring. Every new agent-interop protocol faces the same cold-start problem: it only works if both sides adopt it. Your agent speaks protocol X; the vendor's agent speaks protocol Y; the customer's agent speaks nothing yet. So you build adapters, registries, capability negotiation — infrastructure that email solved decades ago with a global address space and MX records. An agent with a mailbox can message any human and any other agent on the planet today. No SDK on the other end. No shared platform. No waiting for a standards body to settle the framing wars. That's not nostalgia; that's the only universally deployed federation layer we have. This argument stays theoretical until your agent actually owns an address, which is what Agent Accounts https://developer.nylas.com/docs/v3/agent-accounts/ provide — hosted mailboxes created entirely through an API, currently in beta. Each one is a real name@company.com address that sends, receives, and is indistinguishable from a human-operated account to anything that interacts with it. People and other agents communicate with it directly. The protocol features map cleanly onto what agent frameworks keep trying to reinvent: message.created webhook, so an agent reacts to messages instead of polling for them.Here's the scenario the protocol designers are drafting RFCs for, running today on 40-year-old plumbing. Your scheduling agent owns scheduling@yourcompany.com . A message arrives: "Can we find 30 minutes next week?" It might be from a human. It might be from the counterparty's own assistant agent. Your agent can't tell, and — this is the point — it doesn't need to. The message.created webhook fires within seconds of delivery. An LLM parses the request, the agent checks availability against its own calendar, proposes slots in a threaded reply, and when one is confirmed, creates an event and sends the invitation over standard ICS. If the other side is a human, the invite renders natively in Google Calendar or Outlook and they click accept. If the other side is an agent, it parses the ICS and RSVPs programmatically. The entire negotiation — identity, transport, threading, the calendar handshake — runs on infrastructure neither party had to agree on, install, or version-match. Now scale the same trick across tenants: one Nylas application can manage Agent Accounts across an unlimited number of registered domains, so a multi-tenant product gives every customer an agent on the customer's own domain. Cross-organization federation isn't a roadmap item. It's the default. One detail worth pausing on: because everything is plain email, the interaction graph is analyzable with ordinary tooling. The communication-patterns recipe https://developer.nylas.com/docs/cookbook/agents/communication-patterns/ scores relationships 0–100 from four weighted signals — frequency at 40%, recency at 25%, reciprocity at 20%, shared meetings at 15%. Point the same analysis at agent traffic and you get observability over agent-to-agent chatter for free. Try getting that from a bespoke binary protocol. All true, so let's say it plainly. Email has no typed schemas — your agent parses natural language or convention, not protobuf. Latency is seconds, not milliseconds. Throughput is bounded too: the free plan caps an Agent Account at 200 messages per account per day, a number that's generous for negotiations between organizations and absurd for anything RPC-shaped. And there's no built-in request/response correlation beyond threading. Spam is the tax bespoke protocols don't pay. On an open address space, anyone can message your agent, including senders you'd rather it never saw. The mitigation lives at the mailbox layer: rules match on sender fields and run actions like block , mark as spam , or assign to folder , and they can reference allow/block lists — typed collections of domains, TLDs, or addresses — through an in list operator. A block rule rejects mail at the SMTP stage, before your agent spends a token on it. It's real work, but it's configuration, not protocol design. So no, don't run your intra-org agent swarm over SMTP. Two agents you own, in one cluster, coordinating fifty times a second? Use a queue or RPC like a sensible person. Email wins at a different boundary: between organizations, between vendors, between an agent and the messy outside world where you control neither the endpoint nor the schedule. That's exactly where the fancy protocols are weakest, because that's where adoption matters most and exists least. You don't have to pick a side. Whatever protocol bets you're making internally, give your outward-facing agent a mailbox as well — it's the one interface guaranteed to work with every counterparty, human or machine, this decade. Registering for the inbound webhook is a single call: curl --request POST \ --url "https://api.us.nylas.com/v3/webhooks" \ --header "Authorization: Bearer