a2a protocol email agent: how google's agent-to-agent standard changes email automation

Google's Agent2Agent protocol shipped in early 2025 with a bold premise: let AI agents talk to each other the way APIs let software talk to software. Any framework, any vendor, any server. One open protocol to connect them all.

The immediate question for anyone building with agents: what does this mean for email? If your agent can now delegate tasks to a specialized email agent running on a different framework across the network, does that simplify things or just add a new layer of complexity?

I've spent the last few weeks digging into the A2A spec, building test agents, and watching the community figure out where this protocol actually helps versus where it's just a shiny new abstraction. Here's what I've found.

What is an A2A protocol email agent?#

An A2A protocol email agent is a specialized AI agent that handles email operations (composing, sending, receiving, parsing) and exposes those capabilities to other agents through Google's Agent2Agent protocol. Instead of every agent in a multi-agent system implementing its own email logic, a dedicated email agent advertises its skills via an "Agent Card," and other agents discover and delegate email tasks to it using standardized JSON-RPC messages. The A2A protocol handles capability discovery, task lifecycle management, and message formatting between the agents.

That's the theory. In practice, the A2A protocol solves the communication layer between agents but says nothing about what happens when an email actually needs to leave your system and land in someone's inbox. That gap matters more than most A2A tutorials let on.

How A2A works (the 60-second version)#

The protocol defines a few core primitives:

• Agent Cards describe what an agent can do, hosted at a well-known URL so other agents can discover capabilities at runtime.
• Tasks represent units of work. One agent sends a task to another, and the receiving agent processes it through states: submitted, working, completed, or failed.
• Messages carry the actual content between agents, structured as "parts" with explicit content types (text, files, structured data).
• Channels support streaming for long-running operations, so a sending agent doesn't have to poll for results.

An email agent would publish an Agent Card advertising skills like "send-email," "check-inbox," and "parse-verification-code." A planning agent somewhere else in your pipeline discovers that card, creates a task ("send this welcome email to the new user"), and the email agent picks it up.

The A2A protocol is open source, framework-agnostic, and designed so agents built with LangChain can talk to agents built with CrewAI, Google's ADK, or anything else. That interoperability is real, and it's the protocol's strongest selling point.

Where A2A stops and infrastructure begins#

Here's where the conversation in most A2A tutorials ends. An email agent receives a task, composes a message, calls an email API, and reports success. Tutorial complete.

But "calls an email API" is doing enormous work in that sentence. Which API? Whose infrastructure? What happens when your agent sends 5,000 emails in a burst because a downstream agent triggered a batch operation?

The A2A protocol handles agent-to-agent communication beautifully. It does not handle:

Authentication and domain ownership. When your email agent sends a message, the receiving mail server checks SPF, DKIM, and DMARC records to verify the sender is authorized. An autonomous agent can't log into a DNS dashboard and configure TXT records. Someone (or something) needs to provision that infrastructure before the agent can send a single authenticated email.

Deliverability at scale. A new email address that suddenly sends hundreds of messages gets flagged as spam by every major provider. Domain warming, reputation management, bounce handling, feedback loops: none of this exists in the A2A spec, and none of it goes away because you're using a protocol.

Rate limiting and back-pressure. Multi-agent systems are fast. That's the point. But email providers enforce strict rate limits (Gmail caps at 2,000 sends per day for workspace accounts, and much less for new domains). An A2A email agent needs queuing, retry logic, and the ability to push back on upstream agents when it's hitting limits.

Identity and compliance. CAN-SPAM requires a physical mailing address and an unsubscribe mechanism in commercial email. GDPR requires consent tracking. When an autonomous agent sends email via A2A, who is legally the "sender"? The agent's operator. Which means the infrastructure needs to enforce compliance, not just hope the agent remembers.

A2A vs. MCP: different problems, different protocols#

I see this question constantly, and the confusion is understandable. Both protocols involve agents and tools. But they solve different problems at different layers.

MCP (Model Context Protocol) connects an agent to tools and data sources. It's how an agent gets the ability to send email in the first place. Think of it as giving your agent hands. LobsterMail's MCP server, for instance, gives any compatible agent (Claude, Cursor, OpenClaw) the ability to create inboxes, send emails, and read incoming messages with zero code.

A2A connects agents to other agents. It's how a planning agent delegates an email task to a specialist email agent running on a different server. Think of it as giving your agents a shared language.

They're complementary. A realistic production setup might look like this: a coordinator agent uses A2A to send a task to your email agent. That email agent uses MCP to connect to LobsterMail's email infrastructure. LobsterMail handles the actual sending, authentication, deliverability, and security. The A2A protocol never touches an SMTP server. MCP never routes between agents.

What an A2A email agent actually needs to work#

If you're building an email agent that participates in A2A workflows, the agent itself is the easy part. You define its Agent Card, implement task handling, and write the email logic. Most of that is boilerplate.

The hard part is the infrastructure underneath. Your email agent needs:

1. Inboxes it can provision on demand. Agents don't fill out signup forms. When a new workflow spins up, the email agent should create an inbox programmatically. With LobsterMail, that's a single SDK call: lm.createSmartInbox({ name: 'My Agent' }) returns a human-readable address like my-agent@lobstermail.ai in under a second.

2. Authenticated sending out of the box. SPF, DKIM, and DMARC should be pre-configured so the agent never has to think about DNS. Every email sent through LobsterMail passes authentication checks automatically.

3. Injection protection on incoming email. This is one most people miss. If your A2A email agent receives email (verification codes, replies, notifications), those messages can contain prompt injection attacks. An agent that reads raw email content is an agent that can be manipulated. LobsterMail scores every incoming email for injection risk, so your agent can filter before processing.

4. Send limits that prevent reputation damage. An agent with no guardrails will burn a domain overnight. Rate limiting at the infrastructure level protects you from your own agents' enthusiasm.

Running an A2A email agent in production#

The gap between a demo and production is where most agent email projects stall. A demo sends one email from a hardcoded address. Production means multiple inboxes, thousands of sends, real deliverability pressure, and compliance requirements that don't pause because your system is autonomous.

The economics matter too. Running an A2A email agent on a traditional email service means paying per-seat or per-address pricing designed for human users. LobsterMail's free tier gives you 1,000 emails per month with no credit card. The Builder plan at $9/month unlocks 10 inboxes and 5,000 emails per month. That's infrastructure priced for agents, not for humans clicking "compose."

Monitoring is another production concern the A2A spec doesn't address. You need visibility into what your email agent is sending, delivery rates, bounce rates, and whether your domain reputation is healthy. Observability for autonomous agents is a different problem than monitoring a marketing campaign, and most traditional email dashboards aren't built for it.

Should you build an A2A email agent?#

If you're running a multi-agent system where different agents need to collaborate across frameworks, A2A is worth adopting. The protocol is well-designed, Google is actively developing it, and the interoperability story is strong.

But don't confuse the protocol layer with the infrastructure layer. A2A tells your agents how to talk to each other. It doesn't send a single email. For that, your email agent needs infrastructure that was built for agents, not retrofitted from a human email service.

If you want to get an A2A email agent running without spending a week on SMTP configuration, grab an inbox here and point your agent at it. The protocol handles the rest of the coordination.