Email handoff for LiveKit voice agents

When a live session ends, your agent shouldn't go silent. Wire MultiMail into your LiveKit worker to send auditable follow-ups, summaries, and confirmations after every conversation.

LiveKit Agents is a Python framework for building realtime voice and multimodal agents on top of LiveKit's media infrastructure. Agents run as workers that join rooms, listen for speech, invoke tools, and respond in voice — all within low-latency sessions optimized for live interaction.

The gap most voice agent builders hit: realtime sessions are ephemeral, but their outcomes need to persist. A scheduling agent books a call — someone needs a confirmation email. A support agent resolves an issue — the customer expects a written summary. A sales agent qualifies a lead — the CRM needs a follow-up sent.

MultiMail's REST API gives your LiveKit worker a direct path from session end to auditable email delivery. Use gated_send mode to let humans review outbound emails before they leave — a clean trust boundary between autonomous voice handling and permanent written communication.

Why MultiMail

Built for LiveKit Agents developers

Clean session-to-email handoff

LiveKit sessions are event-driven and short-lived. MultiMail's POST /v1/mailboxes/{mailbox_id}/send endpoint accepts a POST at session end, decoupling your realtime logic from async email delivery without requiring a separate queue.

gated_send for voice-to-email trust

Voice agents move fast. Email is permanent. gated_send mode lets your agent compose the follow-up autonomously, but holds delivery until a human approves via the MultiMail dashboard or API — giving you automation speed with human accountability.

Webhook-driven approval flow

MultiMail fires approval webhooks to your server when a gated email is reviewed. Your LiveKit worker can subscribe to these events and trigger downstream actions — CRM updates, session archival, next-step scheduling — without polling.

Mailboxes your agent actually owns

Provision dedicated mailboxes via the POST /v1/mailboxes endpoint — agent@yourdomain.com or agent@multimail.dev. Replies from recipients show up in the mailbox's GET /v1/mailboxes/{mailbox_id}/emails listing, so your agent can continue the thread after the voice session ends.

Thread continuity across channels

Use GET /v1/mailboxes/{mailbox_id}/threads/{thread_id} to pull the full email history when a contact rejoins a session. Your LiveKit agent can greet a returning caller with context from prior written exchanges — no separate memory layer needed.

Try it

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.

You are modifying my LiveKit Agents worker so the agent can send auditable email follow-ups after live sessions end. 1. Read https://multimail.dev/llms.txt first, then use those instructions to connect the MultiMail MCP server, create a free inbox, and set up a verified sending domain. 2. Wire MultiMail into LiveKit Agents using LiveKit Agents MCP support: add the MCP extra for livekit-agents, wrap the MultiMail MCP server in mcp.MCPToolset, and pass that toolset through the tools parameter on the Agent or AgentSession. Use MCPServerHTTP or MCPServerStdio exactly as specified by MultiMail’s llms.txt. 3. Give the agent email capability only through the connected MultiMail MCP tools: check the inbox, draft replies, compose email, send email, and schedule email. Do not invent direct HTTP calls, custom webhooks, or hidden endpoints. 4. After a LiveKit conversation ends, have the worker ask the agent to draft a concise follow-up summary and send one test email from the verified sender to my test address. 5. Run MultiMail in gated_send oversight mode for this integration so every send is queued for developer review before delivery. Keep it in gated_send until I explicitly switch to monitored or autonomous.
Getting started

Step by step

1

Install LiveKit Agents and get a MultiMail API key

Install the LiveKit Agents package and sign up for MultiMail to get a live API key. You'll use the key to authenticate REST calls from your worker.

2

Provision a mailbox for your agent

Create a dedicated mailbox your agent will send from. You can use a multimail.dev subdomain or bring your own domain.

3

Add send_email as a tool in your AgentSession

Expose email sending as a callable tool. The LLM decides when to invoke it; MultiMail handles delivery in gated_send mode so humans approve before anything sends.

4

Register a webhook endpoint for approval events

Set your webhook URL in the MultiMail dashboard so approval and rejection events POST to your server. Verify the signature on every request.

FAQ

Common questions

Does MultiMail block the LiveKit session while waiting for email approval?
No. The POST /v1/mailboxes/{mailbox_id}/send call is async and returns a 202 with the message id and a status of pending_scan. The session continues normally. Approval happens out-of-band via the MultiMail dashboard or API, and you receive the result via webhook — the realtime session path is never blocked.
Can my LiveKit agent receive replies to emails it sent?
Yes. Use the GET /v1/mailboxes/{mailbox_id}/emails endpoint to poll for inbound messages on your agent's mailbox. Replies from recipients land there; read a single message via GET /v1/mailboxes/{mailbox_id}/emails/{email_id} or pull the whole conversation via GET /v1/mailboxes/{mailbox_id}/threads/{thread_id}. You can pull these at the start of a new session to give the agent written context from the interval between sessions.
What oversight mode should I use for session summary emails?
gated_send is the right default for most voice-to-email use cases. The agent composes the email autonomously based on session content, but a human reviews it before delivery. This is appropriate when email content is generated from free-form conversation — the human review step catches errors or sensitive information the agent may have included incorrectly. Switch to monitored or autonomous once you have high confidence in your agent's output quality.
How do I pass session context into the email so reviewers can approve it efficiently?
Put the context reviewers need directly in the message — the subject and markdown body are what's shown in the MultiMail approval UI, so a brief session reference or summary line at the top gives the reviewer what they need before approving. To correlate approvals back to sessions on your own side, keep a mapping from the message id returned by the send call (and echoed in the approval webhook payload) to your session ID.
Can I use MultiMail without a custom domain?
Yes. Provision mailboxes on the multimail.dev domain — e.g., your-agent@multimail.dev — without any DNS configuration. Custom domains (with SPF, DKIM, and DMARC setup) are supported for production use where deliverability and brand identity matter.
Is there a Python SDK instead of raw HTTP calls?
There is no Python SDK package — call the REST API directly with httpx or aiohttp for async HTTP, as shown in the code samples. The other supported client surface is the MCP server (the @multimail/mcp-server npm package), used via MCP tools. The REST API is stable and fully documented at api.multimail.dev.
Related integrations

Explore more

OpenAI Agents SDK

orchestration · python

View guide →

Trigger.dev

workflow · typescript

View guide →

Browser Use

tool-use · python

View guide →
Get started

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.

Read the Docs →See Pricing