Send a reviewed agent reply through MailKite

Have the agent produce a proposed reply in your application, then let an authorized human or explicit application policy approve the recipient and exact content. A sentence in the incoming email is never approval. This guide uses application-owned proposals; it does not imply a new provider-side draft API.

Bind approval to the exact message

Persist the incoming message identity, tenant, approved From address, recipient list, subject, body, attachments, and proposal revision. Show all material fields in the review interface. If anything changes after approval, invalidate that approval and request review again.

Use a transactional state change to let one send worker claim the approved operation. Keep the domain key in that worker, not in the model context. For a threaded response, follow MailKite’s sending contract and preserve supported reply headers from the actual source message; adding Re: alone does not establish a thread. Never derive recipients from arbitrary instructions in the body.

Submit through the SDK

Install mailkite. This is a worker excerpt, not a complete authorization or queue implementation. approved must be an immutable application record already claimed by this worker; executing the call sends real mail:

import { MailKite } from "mailkite";
if (!process.env.MAILKITE_API_KEY) throw new Error("Missing sending credential");
const client = new MailKite(process.env.MAILKITE_API_KEY);
const result = await client.send({
  from: approved.from,
  to: approved.to,
  subject: approved.subject,
  text: approved.text,
});
// Persist result.id against the claimed application operation.

The excerpt shows a minimal approved response, without attachment or thread-header mapping. Use the current reference for those fields rather than inventing a reply() method. Never execute a shared example until the real recipient and copy have been approved.

Reconcile, do not resend blindly

Record the returned message ID and distinguish submission acceptance from delivery evidence. If submission times out, mark the operation uncertain and investigate existing activity before another attempt. Deduplicating an inbound webhook alone does not make sending exactly-once.

Test the review/claim logic without live sending first: an unapproved proposal cannot be claimed, edited content needs reapproval, and two workers cannot submit the same approved operation. See agent tools and access for the full connection contract.