Review an agent email draft before sending the exact message

Show the action the human will authorize

A useful review contains the sender inbox, all to/cc/bcc recipients, subject, final body, attachment names and the reason for sending. If the draft replies or forwards an existing message, include the relevant source context and explain the intended audience. A button labeled approve should refer to that concrete snapshot. It should not grant permission for whatever recipients or content a model chooses later. Sending from the right inbox with the wrong attachment or a newly added cc recipient is a different action and deserves a fresh decision.

Keep drafting and sending credentials distinct

The initial autonomous key can create drafts but cannot send them, create new inboxes or mint more powerful keys. Human claim does not silently upgrade that key. An owner must explicitly delegate any required sending authority, subject to workspace verification, recipient policies, provider readiness and plan limits. This lets a drafting worker operate with a smaller credential while a separate send path handles authorized actions. Do not place an owner key in the model prompt or a review page’s URL simply to make a send button work.

Recheck the final resource before submission

Read the current draft when preparing the approval snapshot and again if concurrent editing is possible before execution. Match the revision or digest your application approved. Draft forwarding merges original content and attachments at send time, so a review process must include those dependencies or freeze an appropriate snapshot in its own application record. Any material change should return the draft to review. A note saying reviewed earlier is not enough when the actual recipient list or source content changed since that review.

Preserve one send attempt identity

Send with POST /v0/emails/inboxes/:inbox_id/emails/drafts/:draft_id/send using a saved Idempotency-Key for the authorized action. MCP send_draft requires an explicit idempotency_key argument. Store the attempt before the request, then record the returned message identity and outcome. A successful send returns the email and removes the draft. If the response is lost, preserve the same attempt identity and investigate; a new key can create another external action rather than recover the first. Do not mark an approval consumed and complete solely because the HTTP request was started.

Report evidence with the right scope

Tell the operator whether the draft is pending review, submission failed, the provider accepted the send or delivery remains unconfirmed. email.sent reflects provider acceptance, while current outbound adapters do not automatically provide recipient delivery receipts. Keep denial and cancellation as first-class outcomes so the agent does not repeatedly resubmit the same proposal. Your next step is a local test in which the draft changes after review and the send path refuses the stale approval, followed by a replay test that proves a lost response cannot produce a second send attempt.

Make hidden recipients visible to the reviewer

A review page may collapse cc and bcc by default, but approval still needs the complete recipient set. Expand those fields before confirmation and show which attachment revision will leave the workspace. If the message includes sensitive quoted context, include that context in the review snapshot rather than approving only the model’s newly written introduction.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin draft send lifecycle ↗Checked 2026-11-05
• Lupin MCP authorization ↗Checked 2026-11-05
• Lupin webhook event semantics ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.