Email-triggered AI agents, without the webhook glue.
Triggering an agent from email usually means a forwarding rule, an inbound-parse webhook, and a Zapier chain that breaks in silence. On a2a cloud, a Pro-plan agent gets a real address — <agent-name>@agents.a2acloud.io — on a dedicated, SPF/DKIM/DMARC-configured mail subdomain. Sending an email is the invocation. One line of YAML enables it, and every triggered run is audited.
a real address · one yaml line · owner-gated · every trigger audited
The glue between inbox and agent is the fragile part.
Email is where work actually arrives, but agents listen on APIs — so teams bridge the gap with forwarding rules, inbound-parse webhooks, and no-code automation chains. Every hop is a place to fail silently, a place where the message gets mangled, and a place the audit trail goes dark. Anyone who discovers the address can fire the automation, nothing stops two auto-responders from looping, and when it breaks you debug three vendors to find out which one dropped the message.
Give the agent an address. Skip the chain.
On a2a cloud the mailbox is a first-class agent resource: enable it with resources.mailbox: true, get a real address in seconds, and let the email itself invoke the run — sender-gated, loop-guarded, and audited end to end.
A real address, not a webhook
Every Pro-plan agent can claim <agent-name>@agents.a2acloud.io — a real mailbox on a dedicated mail subdomain with SPF, DKIM, and DMARC configured. Sending an email is the invocation. No webhook endpoint to stand up, no forwarding rule to babysit.
One line of YAML
Set resources.mailbox: true in a2a.yaml — or click once in the dashboard — and the address is provisioned in seconds. Optionally add allowed_senders in the same block. That's the entire integration.
Sender-gated by default
Out of the box, only the agent's owner can trigger it by email. Opening it up is an explicit allowlist decision, not a default. Explicit authority, no ambient trust — the same posture as the rest of the runtime.
Loop-guarded triggering
Auto-submitted mail and senders on the agent domain are filtered before they ever reach the agent, so two mailboxes can't trigger each other into an infinite loop — a failure mode webhook chains rarely defend against.
Every trigger is audited
Each received and sent mail leaves an audit event, and the triggered run lands as a dashboard chat thread with an email badge. An email-triggered run has the same evidence trail as a run you started by hand.
A structured handler in the SDK
The @a2a.tool(on_email=True) decorator — the SDK contract shipping in the next a2a-pack release — hands your code a typed (ctx, email: InboundEmailPayload) with sender, subject, body, message_id, references, and attachments up to 1 MiB inlined. Return a string or {body, subject} and the reply goes out.
Webhook chains vs. an agent with its own address.
Frequently asked.
What is an email-triggered AI agent?
It's an agent that runs when a message lands in its own mailbox, instead of when someone calls an API. On a2a cloud, every Pro-plan agent can claim a real address — <agent-name>@agents.a2acloud.io — so the email itself is the invocation. There is no webhook, parser, or automation chain between the message and the run.
How do I trigger an agent from email without webhooks or Zapier?
Add resources.mailbox: true to your a2a.yaml — one line — or enable the mailbox with a single dashboard click. The address is provisioned in seconds on a dedicated mail subdomain with SPF, DKIM, and DMARC already configured. Email the agent and it runs; the round-trip completes in seconds.
Can anyone email my agent and make it run?
No. By default only the agent's owner can trigger it; mail from anyone else doesn't start a run. To accept other senders, you add them to an explicit allowed_senders allowlist. Auto-submitted mail and senders on the agent domain are filtered as a loop guard, so agents can't trigger each other indefinitely.
How does my code receive the triggering email?
Through a structured handler: @a2a.tool(on_email=True), the SDK contract shipping in the next a2a-pack release, with a forced (ctx, email: InboundEmailPayload) signature. The payload carries sender, subject, body, message_id, date, references, and attachments inlined up to 1 MiB. Return a str or {body, subject} and the reply is sent from the agent's own address.
Is an email-triggered run audited like any other run?
Yes. Every received and every sent mail leaves an audit event, and the conversation appears in the dashboard as a chat thread with an email badge — inbound mail as the user message, the agent's reply as the assistant message. The agent runs with its owner's identity and LLM credentials, so authority is as traceable as the trigger.
What limits apply to email triggering?
Each agent can send 50 outbound emails per day; over-cap replies still land in the dashboard thread and are audited, they just don't leave as mail. The mailbox has a 100 MiB storage quota, and if the plan lapses, mail is retained for 30 days.
Related guides.
All guides live in the guides index.
Email in. Agent runs. Audited.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and gives it a real mailbox on a dedicated mail subdomain with one line of YAML. Owner-only senders by default, loop-guarded inbound filtering, 50 outbound emails a day per agent, and an audit event for every message received or sent. The email is the trigger; the run is the proof.