Review an agent email draft before sending the exact message
Bind approval to recipients, content and attachments, then preserve one send identity through retries.
Choose reply, reply-all or forward by the intended audience
Understand conversation and recipient behavior before an agent responds or shares a message.
Start with who should receive the message
Reply, reply-all and forward express different communication decisions. A reply continues a conversation with a narrower audience, reply-all includes other participants, and forward starts a new conversation with chosen recipients. Choose the audience from the user’s request and the actual source message rather than from a vague model instruction such as handle this. Read the source before creating the action. If the latest email contains sensitive material, a forward can disclose more than a reply even when the short introductory text looks harmless.
Inspect the current reply implementation
The source-email routes are POST /v0/emails/inboxes/:inbox_id/emails/:email_id/reply and /reply-all. Lupin derives subject and threading from the source message. The current ordinary reply selects the source sender unless the source was sent by the inbox itself, in which case it uses the original destination set. The reply request’s reply_to field can override the derived destinations. Do not assume that every provider’s handling of an RFC Reply-To header is replicated automatically. Preview the actual derived audience whenever your workflow relies on that distinction.
Review reply-all as an expanded disclosure
The current reply-all implementation gathers original to, cc and from participants, excludes the inbox’s own address and deduplicates them into the destination list. It is therefore a materially different send from a one-person reply. Show the resulting recipients in the approval snapshot, even when the user interface labels the action with a familiar reply-all icon. Incoming participants are not automatically trusted customers or authorized operators. A malicious sender can add an address to a conversation; that does not grant permission to disclose earlier private correspondence to it.
Forward with explicit content boundaries
POST on the source message’s /forward route starts a new thread and derives an Fwd: subject. It combines the introductory text with a forwarded-message body containing source context. Inspect attachments deliberately rather than assuming direct forward and draft forward have identical behavior: draft forwarding merges source content and attachments when the draft is sent. Choose the endpoint that matches your review process, and include the forwarded material in that review. An approved sentence saying please see below does not authorize disclosure of an unseen document.
Preserve the chosen action through retries
Save the source message, action type, approved audience and idempotency identity together. MCP exposes reply_to_email, reply_all_email and forward_email with explicit idempotency_key arguments. A timeout is not a reason to switch from reply to send or create a new key, because that can change threading and duplicate the communication. Report provider acceptance separately from delivery. Your next step is a local fixture containing self-sent mail, multiple copied participants and an attachment, then compare the exact generated recipients and conversation IDs before enabling these actions in a real agent.
Sources & verification
Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.
- Lupin conversation actions Checked 2026-11-05
- Lupin drafts Checked 2026-11-05
- RFC 5322 message identifiers and recipients Checked 2026-11-05
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.