Email infrastructure for Prefect AI agent flows

Connect MultiMail to any Prefect workflow to send, receive, and gate email with human approval steps — without restructuring your pipeline's retry, scheduling, or observability logic.


Prefect is a Python workflow orchestration platform built for production reliability: retries, scheduling, observability, and deployments on any compute infrastructure. It is a natural fit for AI agent systems that process data, call external services, and need durable execution around those calls.

Email sits at the edge of many agent workflows — notifying stakeholders, parsing inbound requests, routing decisions to humans for review. Without a purpose-built API, agents reach for SMTP libraries or transactional email services designed for marketing teams, not for programmatic agents that need to read replies, wait for approvals, and maintain audit trails.

MultiMail provides a REST API designed for this pattern. Each endpoint maps directly to the operations a Prefect task would perform: send, reply, check inbox, read a message, tag for routing, or pause and wait for a human decision. Oversight modes let you configure how much autonomy the agent has at each stage of the flow, and changing the mode requires no flow restructuring.

Built for Prefect AI Agents developers

Approval steps fit Prefect's retry model

MultiMail's gated_send and gated_all oversight modes hold a message in a pending queue until a human approves it. A Prefect task can poll GET /v1/oversight/pending on a retry schedule and raise until the message drops out of the queue — this is standard Prefect retry behavior with no custom webhook infrastructure required.

Idempotent sends survive task retries

Prefect retries failed tasks automatically. MultiMail's send endpoint is idempotent when you pass an idempotency_key — if a task retries after a transient error, resubmitting the same request returns the existing message id rather than queuing a duplicate. Retry logic in your flow needs no deduplication guard.

Inbound email as a Prefect trigger

MultiMail webhooks emit a structured payload on every inbound message, including sender, parsed body, thread ID, and tags. Point the webhook at a Prefect deployment's HTTP trigger endpoint to start a new flow run automatically for each incoming message.

Observable email actions

Every MultiMail API call produces a structured audit event — sender, recipient, oversight mode, approval status, and timestamps. These surface in the MultiMail dashboard alongside delivery and approval history, and can be exported to the same observability stack your Prefect flows report to.

Per-mailbox oversight modes

A single Prefect flow may need different email policies for different audiences: a gated_send mailbox for external customer mail, an autonomous mailbox for internal status messages. Send each class of mail from the mailbox whose oversight mode matches, so one deployment covers all of them without environment-specific branching.


Try it with your agent

No code, no dashboard. Paste this to your AI agent — it connects MultiMail, creates an inbox, and builds the flow for you.

1. Read https://multimail.dev/llms.txt first, then connect the MultiMail MCP server exactly as described there. Use the MCP tools to create a free inbox and set up a verified sending domain before wiring anything into Prefect. 2. In the Prefect AI Agents workflow, use Prefect’s real primitives: define Prefect tasks for the MultiMail MCP operations, orchestrate them inside a Prefect flow, and use Prefect’s human-in-the-loop pause/resume input pattern for approval. Do not invent Prefect email APIs or bypass the existing workflow retry, scheduling, logging, or observability behavior. 3. Give the agent three capabilities only: check the inbox through the connected MultiMail MCP tools, draft a reply as plain proposed email content without sending it, and send or schedule email only through MultiMail after the Prefect flow has approved that action. 4. Send one test email from the verified sending domain to a developer-controlled recipient. The message should identify itself as a MultiMail and Prefect AI Agents integration test, then confirm the result in the Prefect run logs and by checking the inbox state through MultiMail. 5. Run the mailbox in gated_send. Before any outbound email is sent, the Prefect flow must pause for human review of the recipient, subject, body, and any scheduling choice; only after the developer approves should the flow call the MultiMail send capability. Keep monitored and autonomous disabled until the developer explicitly changes the oversight mode.

Step by step

1

Install Prefect and store your MultiMail API key

Install Prefect and the requests library. Store your MultiMail API key as an environment variable for local development, or as a Prefect secret block for deployed flows.

2

Provision a mailbox for your agent

Create a mailbox using MultiMail's POST /v1/mailboxes endpoint (admin scope). Set the mailbox's oversight_mode — it governs every message sent from this mailbox. AI disclosure is locked on and cannot be disabled.

3

Wrap MultiMail calls in Prefect tasks

Define each email operation as a Prefect task with a retry policy. Tasks raise on non-2xx responses so Prefect records failures and retries automatically.

4

Deploy and schedule the flow

Deploy the flow to a Prefect work pool with a schedule. The MULTIMAIL_API_KEY environment variable must be available in the worker environment.


Common questions

Does MultiMail have a native Prefect block or integration package?
Not yet. MultiMail exposes a REST API at https://api.multimail.dev/v1 and all operations are available via standard HTTP calls using the requests library. Wrapping each call in a Prefect task gives you retries, state tracking, and logging without a dedicated block. A first-party Prefect integration is on the roadmap.
How does oversight mode interact with Prefect's retry logic?
They are independent. Prefect retries happen when a task raises an exception — for example, on a network error or a non-2xx response from MultiMail. Oversight mode controls what MultiMail does with the message after it is accepted: hold for approval, or send immediately. If a task retries after a transient failure, resubmitting the same request with the same idempotency_key returns the existing message id rather than creating a duplicate send.
Can inbound email trigger a Prefect flow run automatically?
Yes. Configure a MultiMail webhook on your mailbox pointing to a Prefect deployment's HTTP trigger endpoint. MultiMail will POST a structured payload for each inbound message — sender, subject, parsed body, thread ID, and any existing tags. Prefect creates a new flow run for each webhook call with the message data passed as parameters.
What happens if a flow is cancelled while an email is awaiting approval?
The message stays in the MultiMail pending queue until explicitly approved or rejected. You should call POST /v1/mailboxes/{mailbox_id}/emails/{email_id}/cancel in a flow cancellation handler or a cleanup task to withdraw pending messages when the flow exits unexpectedly. Otherwise the email may be approved and sent after the flow that queued it has already been marked cancelled.
Which oversight mode should I use during local development?
Use gated_all during development so no emails are sent without explicit approval regardless of which endpoint the task calls. This gives you full visibility into what the agent would send before promoting to gated_send in staging or monitored and autonomous in production.
Can I run multiple concurrent flows that share the same mailbox?
Yes. MultiMail mailboxes are shared resources. If multiple flows list the inbox (GET /v1/mailboxes/{mailbox_id}/emails) on the same mailbox, set a 'claimed' tag (PUT /v1/mailboxes/{mailbox_id}/emails/{email_id}/tags) immediately after reading a message, and filter by the absence of that tag in subsequent list calls. This prevents two concurrent flow runs from processing the same message.

Explore more

The only agent email with a verifiable sender

Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.