Why email remains the ultimate protocol for agent-to-agent AI communication

In the fast-evolving landscape of AI agents, one fundamental challenge persists: how do disparate systems communicate without prior coordination? The procurement agent at Company A needs pricing data from the sales agent at Vendor B, but neither team has established a shared API or integration pipeline. The solution? A decades-old technology—email.

This approach works because both agents possess something most modern AI systems lack: a fully functional email address. No joint protocol adoption is required. No shared specification implementation is necessary. The sender simply composes a message, and the recipient’s system handles delivery automatically. This federated architecture—where any domain can host mailboxes and every organization already accepts inbound deliveries—eliminates the bootstrapping problem that plagues other agent communication frameworks.

The federated advantage that no protocol can replicate

Current agent-to-agent protocols demand mutual adoption of the same technical specification before meaningful communication can occur. Email sidesteps this requirement entirely through its inherent design: SMTP (Simple Mail Transfer Protocol) provides universal compatibility, while the email address itself serves as a built-in identity system. Conversation state is preserved through threading, ensuring both parties maintain context throughout negotiations.

This federated model means an agent operating on any SMTP-compatible system can communicate with counterparts across different domains, organizations, or even service providers—without requiring prior agreement on technical standards. The infrastructure for this communication already exists globally, making it an immediately deployable solution for agent ecosystems.

Agent Accounts: transforming mailboxes into first-class AI participants

Nylas has introduced Agent Accounts, a beta feature that converts standard mailboxes into fully functional agent mailboxes. These hosted accounts, such as procurement-agent@yourcompany.com, operate identically to human-operated accounts from an external perspective while providing programmatic access through the Nylas API.

Under the hood, each Agent Account receives a unique grant_id that integrates seamlessly with existing Nylas endpoints for messages, drafts, threads, folders, attachments, and webhooks. The critical advantage is that these accounts appear indistinguishable from human accounts to external systems. This uniformity eliminates the need for separate code paths when handling agent-to-agent versus agent-to-human interactions.

The negotiation pipeline in practice

The process begins when Agent A initiates contact by sending a structured message through the Nylas API. A typical procurement request might look like this:

curl --request POST \
  --url " \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "to": [{
      "email": "sales-agent@vendor.example"
    }],
    "subject": "Quote request: 40 units, SKU TR-200",
    "body": "Requesting a quote for 40 units of TR-200, delivery by end of quarter."
  }'

When the vendor’s Agent Account receives the message, it triggers a standard message.created webhook event—identical in format to events generated by human-operated accounts. The vendor’s system processes the request, formulates a response, and replies by referencing the original message ID. The Nylas platform automatically configures the necessary email headers (In-Reply-To and References) to maintain proper threading across both mailboxes.

This threading mechanism serves as the conversation state repository. Both agents can reconstruct the negotiation history by fetching the complete thread, which contains every offer, counter-offer, and constraint in chronological order. The email protocol itself handles state persistence, eliminating the need for separate session stores or shared databases.

Distinguishing agent traffic from human correspondence

When building applications that handle both agent and human communications, developers need a reliable method to route incoming messages appropriately. While the webhook payload structure remains identical for both scenarios, the distinguishing factor lies in the grant metadata.

Agent Accounts include a provider field set to "nylas", which allows applications to implement simple branching logic:

async function handleMessageCreated(payload) {
  const grantId = payload.data.grant_id;
  const grant = await getGrant(grantId); // Cache this lookup
  
  if (grant.provider === "nylas") {
    return agentLoop.enqueue(payload); // Route to agent negotiation handler
  }
  return humanInboxHandlers.dispatch(payload); // Forward to human inbox handlers
}

This approach maintains a single code path for webhook processing while efficiently separating agent traffic from human correspondence. The shared infrastructure for verification, retries, and queueing remains unified across both use cases.

Pre-filtering agent conversations for security and relevance

Unfiltered agent mailboxes risk processing spam, phishing attempts, or unsolicited outreach from other agents. To mitigate this risk, Nylas Agent Accounts support inbound filtering rules that operate at the SMTP level—before messages are stored or webhooks are triggered.

These rules can match on sender attributes such as email address, domain, or top-level domain (TLD), with actions including blocking, marking as spam, or assigning to specific folders. For dynamic lists of vendors or counterparts, rules can reference address collections that can be updated without modifying the rule itself.

A practical implementation might include:

• A whitelist of known vendor domains routed to a negotiations folder
• A blacklist of problematic domains configured to block immediately
• An address list system that team members can update independently

This filtering ensures agents only process relevant, pre-approved correspondence, significantly reducing the attack surface and improving operational efficiency.

Balancing structure with human readability in agent communications

While email bodies traditionally contain free-form text—ideal for LLM agents to parse—they can also incorporate structured data without sacrificing human comprehension. The most effective pattern combines:

• Clear, human-readable prose at the beginning
• A structured payload (JSON block or attachment) appended at the end
• Machine-readable footers containing formal specifications

This dual-format approach ensures the same message serves both human reviewers and parsing agents effectively. Humans can skim the narrative portion while agents extract the structured data for automated processing.

Considering the limitations of email-based agent communication

While email excels in interoperability and established infrastructure, it carries inherent trade-offs. Delivery latency typically measures in seconds rather than milliseconds, making it unsuitable for tight request-response loops. Webhook delivery occurs shortly after SMTP handoff, but this isn’t a channel designed for real-time synchronous interactions.

Additionally, while email threading provides conversation state, it doesn’t offer transactional guarantees. Messages may experience delays or temporary failures without immediate notification. For workflows requiring atomic operations or strict ordering guarantees, supplementary systems may be necessary.

Despite these constraints, email remains the most reliable foundation for agent-to-agent communication in heterogeneous environments. Its universal acceptance, federated architecture, and built-in identity system provide capabilities that no bespoke protocol can match without years of widespread adoption. As AI agents proliferate across industries, the organizations that leverage existing email infrastructure will gain immediate interoperability advantages over those waiting for new standards to mature.