MultiMail tracks thread identity, conversation history, and reply headers so your AI agent never loses context or forks a conversation incorrectly.
Email agents fail in subtle, trust-destroying ways when thread context is missing. An agent that replies to the wrong message in a chain, repeats information already addressed three emails ago, or sends a response that omits the References header — breaking thread grouping in every major email client — looks broken even if the underlying logic is correct. These failures are hard to catch in testing because they depend on real conversation state that unit tests do not model. The root cause is usually the same: the agent fetched the most recent message and replied to it in isolation, without access to the thread as a whole.
MultiMail exposes email conversations as first-class objects. Each thread has a stable thread_id and an ordered list of its emails. When your agent calls get_thread, it receives the full conversation — every email's id, sender, subject, and direction, not just the latest. To reply, you call reply_email against the email's id; MultiMail computes and attaches the RFC 2822 In-Reply-To and References headers for you, so downstream mail clients group the conversation correctly regardless of which client receives the reply.
Call get_thread with the mailbox_id and thread_id to retrieve every email in the conversation, ordered chronologically. Each entry includes the email's id, sender, subject, direction, and timestamp (the thread list omits bodies — read an email by id for full content). The response also surfaces the participant list, message_count, and whether there's an unanswered inbound email.
The get_thread response includes a messages array with every message in the thread. Pass this ordered history to your LLM so it can draft a reply with full awareness of what has already been said, committed to, or asked — not just the most recent message.
Your agent generates a reply grounded in the full thread history. Because the complete conversation is available, the agent avoids repeating resolved items, surfaces only what is genuinely new, and matches the tone and commitments established earlier in the thread.
Call reply_email against the id of the specific email you are replying to (POST /v1/mailboxes/{mailbox_id}/reply/{email_id}). MultiMail resolves the thread, then constructs and attaches the In-Reply-To and References headers automatically — no manual header manipulation required in your agent code.
Webhooks fire on delivery confirmation, bounces, and inbound replies. The message.received payload carries the email_id; read that email to get its thread_id, then load the thread — so your agent can process the next message in the conversation reactively without polling check_inbox.
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.
MultiMail computes and attaches In-Reply-To and References headers on every reply_email call. Replies group correctly in Gmail, Outlook, Apple Mail, and any RFC 2822-compliant client without any header construction in your agent code.
get_thread returns every email in the thread ordered chronologically — id, sender, subject, direction, and timestamp. Read each email by id to pull its body, and your LLM receives the complete context it needs to write a coherent reply — not just the most recent message.
Thread identity is tracked server-side. Whether the next message arrives from the customer or is sent by your agent, it is appended to the same thread object under the same thread_id. No client-side state or header parsing required.
Inbound reply webhooks carry the email_id; one read resolves its thread. For high-volume deployments handling thousands of conversations, your agent processes new replies reactively rather than polling check_inbox on an interval.
get_thread and reply_email are available as MCP tools (Claude Desktop, Cursor, Windsurf) and as direct REST endpoints. Threading header logic is handled server-side identically across both paths.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.