Auto-Responders That Actually Read the Email

MultiMail's inbound webhooks and gated_send oversight let AI agents draft contextual replies that a human reviews before anything reaches the customer.


Why this matters

Generic auto-responders erode trust. A customer emailing about a billing dispute doesn't want 'Thanks for contacting us — we'll respond within 2 business days.' They want an answer. But fully autonomous AI replies carry real risk: hallucinated policy details, wrong account information, or a tone-deaf response to an already-frustrated customer. Most teams are stuck between 'useless template' and 'fully autonomous AI' with no intermediate option that's actually safe to deploy.


How MultiMail solves this

MultiMail's inbound webhook delivers the full email to your agent the moment it arrives. The agent loads the complete conversation history via GET /v1/mailboxes/{mailbox_id}/threads/{thread_id}, drafts a reply using your LLM of choice, then queues it via the reply endpoint (POST /v1/mailboxes/{mailbox_id}/reply/{email_id}). When the mailbox is in gated_send mode, the draft is held for review. A human reviewer sees the draft alongside the original thread, approves or rejects it, and MultiMail delivers. The agent handles reading and drafting; the human handles last-mile judgment. As you build confidence in specific email categories, you can shift the mailbox to monitored or autonomous mode without changing your agent's code.

1

Inbound webhook triggers the agent

Configure your MultiMail mailbox to POST to your webhook endpoint on every inbound message. The payload includes email_id, thread_id, mailbox_id, sender, subject, and body text. Your agent receives this event and begins processing immediately — no polling required.

2

Agent loads full thread context

The agent calls GET /v1/mailboxes/{mailbox_id}/threads/{thread_id} with the thread_id from the webhook payload. This returns the complete conversation history — all prior messages, timestamps, and directions — so the draft accounts for everything that's already been said and avoids repeating questions already answered.

3

Agent drafts a contextual reply

The agent passes the thread history and incoming message to your LLM with a system prompt that includes your product knowledge and any verified account data you've fetched from your own database. The model generates a reply scoped to what it actually knows.

4

Draft queued for human review

The agent calls the reply endpoint (POST /v1/mailboxes/{mailbox_id}/reply/{email_id}) with the drafted response. With the mailbox in gated_send mode, the message is held in the pending queue rather than delivered. Reviewers access the queue via GET /v1/oversight/pending and see the original email, full thread, and proposed reply side by side.

5

Human approves or rejects

The reviewer calls POST /v1/oversight/decide with {email_id, action} where action is approve or reject. Approved messages deliver immediately. Rejected drafts can trigger a revision loop in your agent, which drafts again and queues a fresh reply.

6

Delivery webhook closes the loop

MultiMail fires a delivery event when the message sends. Your agent logs the outcome, sets tags via PUT /v1/mailboxes/{mailbox_id}/emails/{email_id}/tags to mark the thread resolved, and optionally updates your CRM or support system with the resolution details.


Try it with your agent

Pick your platform, copy the prompt, and paste it to your AI agent — it sets up MultiMail and builds the whole flow. Nothing to fill in.

1. Get MultiMail ready: read https://multimail.dev/llms.txt, connect the MCP server, create a free inbox, and set up a verified sender. 2. In Zendesk Admin Center, create a webhook and attach it to a Support trigger that fires when a ticket is created or updated, the channel is email, and the latest public comment is from the requester. 3. When the trigger fires, use Zendesk ticket, user, organization, and comment history data to classify the issue, check policy-sensitive categories such as billing disputes or cancellations, and draft a direct reply that answers the customer without inventing account details. 4. Compose the reply in MultiMail against the customer thread, preserve the Zendesk ticket ID in your working notes, and use a short cadence: immediate draft for new urgent tickets, same-business-day draft for normal tickets, and no draft for spam or security-sensitive requests that require escalation. 5. Run the inbox in gated_send mode so a human reviews every draft before delivery; ask me only for Zendesk credentials, MultiMail access, and approved brand voice/policy notes when it is time to go live.

What you get

Contextual replies, not templates

The agent reads the full conversation thread via GET /v1/mailboxes/{mailbox_id}/threads/{thread_id} before drafting. Replies reference what the customer actually said, not a generic acknowledgment that ignores the question entirely.

Human review before every send

gated_send mode holds every draft in the pending queue. Your team reviews the agent's work and approves, edits, or rejects before anything reaches the customer. You get drafting speed without losing control over what goes out.

Incremental path to autonomy

Start with the mailbox in gated_send. As you build confidence in specific email types — shipping status, password reset instructions, plan upgrade confirmations — route those categories to a mailbox set to monitored or autonomous. Oversight mode is a per-mailbox setting, so dedicating a mailbox per trust tier lets you mix modes without changing your agent's code.

Structured audit trail

Every draft, every approval decision, and every delivery event is logged. You can query the full history of any thread, see exactly what the agent drafted, and review what a human changed before approving. This matters for support quality audits.

Model-agnostic drafting

MultiMail handles inbound routing, thread stitching, and delivery. Your agent can use any model for the drafting step — Claude, GPT-4o, Gemini, or a fine-tuned model trained on your historical support data. The API does not care which LLM you use.


Recommended oversight mode

Recommended
gated_send
Auto-responders handle high-volume, customer-facing email where errors are visible and trust-damaging. gated_send is the right default: agents draft quickly, but a human reviewer catches hallucinated policy details, wrong account information, or inappropriate tone before the message reaches the customer. Once you've reviewed enough drafts in a given email category to trust the agent's output quality, switch that category to monitored or autonomous — neither requires changes to your webhook handler or agent logic.

Common questions

How does the agent access the full conversation, not just the latest message?
The inbound webhook payload includes a thread_id. Your agent passes this to GET /v1/mailboxes/{mailbox_id}/threads/{thread_id}, which returns all messages in the conversation in chronological order — body text, sender, timestamp, and direction (inbound or outbound). The LLM receives the full history before drafting, so replies don't repeat questions already answered or ignore prior commitments.
What happens when a reviewer rejects a draft?
Calling POST /v1/oversight/decide with action: 'reject' removes the message from the pending queue without delivering it. Your agent can detect the rejection and trigger a revision workflow — for example, re-prompting the LLM and queuing a new draft. The original inbound message remains readable via GET /v1/mailboxes/{mailbox_id}/emails/{email_id} so the thread is not lost.
Can I use different oversight modes for different email categories?
Yes — oversight mode is a per-mailbox setting. Provision separate mailboxes for separate trust tiers: a gated_send mailbox for ambiguous cases and an autonomous mailbox for well-defined categories where the response is deterministic — like confirming a support ticket was received with a ticket number from your system. Your agent inspects the incoming email's subject line, sender domain, or body content and routes the reply through the mailbox whose mode matches the risk.
How do I prevent the agent from making up account details it doesn't have access to?
Two approaches work well together. First, inject verified account data into the system prompt before calling your LLM — look up the sender's email in your database and include their plan, account status, and relevant history. Second, instruct the agent to write [REVIEWER: please fill in X] for any detail it cannot verify, so reviewers know exactly where to complete the draft before approving.
What email volume can this handle?
MultiMail processes inbound webhooks synchronously with no per-mailbox rate limit on inbound processing. Outbound sending is subject to your plan's monthly limit: Builder (5,000/mo), Pro (30,000/mo), Scale (150,000/mo). High-volume support queues should use the Pro or Scale plan. Drafts that are rejected or expire do not count against your send limit.
Can I build this with the MCP server instead of the REST API?
Yes. The MCP server exposes equivalent tools: list_emails, get_email, get_thread, reply, oversight_pending, oversight_decide, and set_tags. If your agent runs inside Claude Desktop, Cursor, Windsurf, or another MCP-compatible client, you can use these tools directly without writing a webhook handler. Oversight mode behavior is identical to the REST API.
How do I notify my support team when drafts are waiting for review?
Poll GET /v1/oversight/pending on an interval and notify your team when it returns new entries — post a Slack message, send an internal email, or update your support team's dashboard. Each pending entry includes the email id, mailbox_id, subject, and sender so reviewers can triage before opening the full queue.

Explore more use cases

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.