email as an inter-agent communication protocol

Every few weeks a new inter-agent communication protocol shows up. MCP, ACP, A2A, ANP. Each one solves a real problem. Each one requires every participant to adopt the same standard, run compatible servers, and agree on message formats before a single byte moves between agents.

Meanwhile, email has been routing structured messages between independent systems since 1971. It works across every organization, every framework, and every agent runtime on the planet. No SDK adoption required on the receiving end. No firewall rules. No mutual authentication handshake.

I'm not saying email replaces purpose-built agent protocols. I am saying it's being overlooked as a native transport layer for inter-agent communication, and that's a mistake.

Protocol comparison#

Here's how the major inter-agent communication protocols compare when you line them up honestly:

The pattern is obvious. Every protocol built specifically for agents runs over HTTP. Email is the only production-grade async transport that doesn't require the receiving agent to expose an endpoint or run a compatible server.

What ACP and A2A actually solve#

Agent Communication Protocol (ACP) gives agents a standard way to exchange structured tasks over HTTP. One agent posts a task, the other agent picks it up, processes it, and returns a result. It's clean. It's well-defined. IBM and the open-source community have put real thought into the message format and lifecycle states.

A2A (Agent-to-Agent Protocol), pushed by Google, does something similar but focuses on cross-framework interoperability. Your LangChain agent can talk to your CrewAI agent without either one knowing the other's internals. The "Agent Card" concept for discovery is genuinely useful.

MCP (Model Context Protocol) is different. It's not really agent-to-agent. It's agent-to-tool. MCP gives an agent access to external resources (databases, APIs, file systems) through a standardized interface. AWS has been exploring how to layer agent-to-agent communication on top of MCP, but that's still experimental.

ANP (Agent Network Protocol) targets open discovery. Agents find each other, negotiate capabilities, and establish communication channels. Think DNS for agents.

All four protocols assume both sides are online, reachable, and running compatible software. That assumption breaks the moment you need to communicate across organizational boundaries where you don't control the other side's infrastructure.

Where email fills the gap#

Email works where HTTP-based protocols don't, and the reasons are structural, not nostalgic.

Cross-boundary communication without mutual setup. When your agent needs to contact a vendor, a client's system, or a government portal, you can't ask them to install an ACP server. But they already have email. Every business on the planet has email. Your agent sends a message, their system (or their human) receives it. No integration required on their end.

Built-in identity and authentication. SPF, DKIM, and DMARC aren't new protocols. They've been hardened over two decades of spam warfare. When your agent sends email through properly configured infrastructure, the receiving server can cryptographically verify who sent it. That's more authentication than most A2A implementations ship with today.

Async by default. HTTP-based protocols can do async, but it's bolted on. You need callback URLs, polling, or websockets. Email is natively async. Your agent sends a message and moves on. The response arrives when it arrives. For workflows where agents coordinate over minutes or hours (not milliseconds), this is exactly right.

Message durability. Emails don't vanish if the receiving agent is offline. They queue. They retry. They sit in an inbox until someone reads them. HTTP requests to a downed server just fail.

We covered this idea in more depth in the agent communication stack: email, chat, voice, and what's next, where email sits as the universal base layer beneath everything else.

Structured payloads over email#

"But email is unstructured text" is the objection I hear most. It doesn't have to be.

Your agent can send a JSON task envelope in the email body, with a human-readable summary in the subject line. The receiving agent parses the body, extracts the structured payload, and processes it exactly like it would process an ACP task object.

{
  "task_id": "inv-2026-0441",
  "type": "invoice_review",
  "payload": {
    "vendor": "Acme Corp",
    "amount": 14200,
    "currency": "USD",
    "due_date": "2026-04-01"
  },
  "reply_to": "finance-agent@lobstermail.ai",
  "callback_format": "json"
}

The email subject could be Task: Invoice review for Acme Corp ($14,200). A human who intercepts it can read it. An agent who receives it can parse it. That dual readability is something no HTTP-based protocol offers.

For multi-agent workflows where agents need to coordinate across systems, email envelopes like this give you a message format that's both machine-parseable and human-auditable.

Agent mailboxes vs. human mailboxes#

Here's where the difference matters. A human mailbox is a destination for correspondence. An agent mailbox is a message processing endpoint.

Agent mailboxes need different things:

• Programmatic provisioning. The agent creates its own inbox without a human filling out a signup form.
• Structured parsing. Incoming messages get parsed for structured data, not just displayed as text.
• Injection protection. Emails can contain prompt injection attacks. Agent mailboxes need to score and flag suspicious content before the agent processes it.
• Disposability. Some agent workflows need a fresh inbox for each task. Create it, use it, discard it.

This is the distinction that traditional email providers miss entirely. Gmail wasn't built for agents. It was built for humans who check email between meetings.

LobsterMail treats each agent as a first-class email citizen. Your agent provisions its own inbox with a single function call, receives messages with built-in security metadata, and can spin up new addresses for specific workflows. No OAuth, no Google Cloud Console, no consent screens.

The latency question#

I'll be honest about the tradeoff. Email is slower than HTTP. An ACP request-response cycle can complete in milliseconds. An email round-trip takes seconds at minimum, sometimes minutes.

For real-time agent collaboration (two agents co-writing a document, for example), email is the wrong choice. Use ACP or A2A.

For async workflows where timing isn't critical (sending a report, requesting approval, coordinating across organizations, receiving verification codes), email's latency is irrelevant. The message arrives, the agent processes it when it's ready. We wrote about the delivery mechanics in webhooks vs polling: how your agent should receive emails.

The real question isn't "which protocol is fastest?" It's "does this workflow need synchronous communication?" If the answer is no, email's reliability and universality outweigh its latency.

Where this is heading#

Twilio recently announced A2H (Agent-to-Human), a protocol for agent-to-human communication with cryptographic evidence and authentication flexibility. That's interesting because it acknowledges something the agent protocol community has been ignoring: agents don't just talk to other agents. They talk to humans, to legacy systems, to organizations that will never adopt A2A.

Email is already the protocol that bridges all of those. The missing piece was treating agent email infrastructure as a first-class concern, not an afterthought bolted onto human email accounts.

I think the future looks like agents using ACP or A2A for real-time collaboration within a system, and email for everything that crosses an organizational boundary. Not either/or. Both, with email as the fallback that always works.

If your agents need to communicate across boundaries today, give them their own email. Get started with LobsterMail for free, and your agent can provision an inbox in seconds.

Give your agent its own email. Get started with LobsterMail — it's free.