Will an AI assistant send emails without asking me first?

The fear behind this query is not abstract autonomy. It is a concrete reputational failure: the wrong recipient sees confidential material, a draft states an invented fact, a promised attachment is absent or a terse message leaves under the professional's signature. A useful assistant should remove composing and coordination work without blurring who authorised the communication. That requires more than a sentence in a system prompt. Draft creation, recipient resolution, attachment verification and provider sending must be separate states with a visible control between them. The current code implements an Outbox and stages outward sends for user confirmation across primary surfaces. It also fails closed when a stored attachment is missing. Those mechanisms still need end-to-end testing, and the product currently has no verified delayed-send recall. So the honest description is approval before sending, and editing before that — never an “undo” that recalls a message a provider has already accepted.

What is the difference between drafting and sending?

Drafting creates reversible content inside the user's workspace; sending causes an external communication under the user's identity. The two operations should never share an ambiguous success state.

The current agent has a create_draft tool that writes to an Outbox and does not send. Drafts can be edited for To, Cc, Bcc, subject and body, have real documents attached, or be discarded. A separate send_draft request selects an existing draft and stages it for confirmation. New outbound messages use another proposal route that also returns a confirmation card rather than calling Gmail directly.

The Outbox record retains status as draft or sent. That supports a clear user promise: if it says draft, nothing has left through that route. A trial should confirm this with the provider's Sent folder, not only the application's label. It should also apply the broader email-access safety checklist.

What should happen from an email request to an approved send?

The workflow should preserve source context, resolve real recipients, create an editable draft, attach actual files, present a complete review and call the provider only after confirmation.

Consider: “Send the IC client group the new venue pack and explain that they may share it with their clients.” The safe sequence is:

1. Resolve the named contact group from stored contacts rather than guessing addresses.
2. Put group members in Bcc by the user's standing rule, unless Cc was explicitly requested.
3. Retrieve the exact venue pack and attach its stored bytes.
4. Draft the explanation from the user's instruction and known facts.
5. Display resolved recipient count, Bcc, subject, body and attachment name.
6. Let the user edit the draft in Outbox.
7. On Send, reload the draft and attachment, validate them and call Gmail once.
8. Record the provider result or leave the draft for retry with a visible failure.

This is the outward-action boundary in AI that reads email and takes action.

How are wrong recipients and group emails controlled?

Recipient identity must come from verified addresses or an inspected group, and the approval must expose the actual outward audience. A name alone is not a safe send target.

The tool definition requires an email address and directs the agent to look up a named contact. Group drafting resolves a contact tag and defaults members to Bcc so recipients do not expose one another's addresses. If the group is empty or unknown, the assistant is told to inspect groups and ask rather than invent membership.

Code-side sending splits To, Cc and Bcc values and refuses an empty primary recipient. It does not currently perform sophisticated domain warnings, duplicate-recipient checks or a second semantic confirmation for a large or external group. Those cases belong in the proof packet. A strong approval view should also highlight a changed recipient after a revision and show the sending Google account when several identities could be connected.

How are facts, signatures and attachments handled?

The assistant should derive claims from real sources, append the configured signature at one controlled gateway and refuse to claim an attachment that is not present. Polished prose is not the safety test.

The current doctrine forbids invented names, numbers and dates and requires mailbox or contact lookup before stating facts from the user's world. A single Gmail send function appends the stored signature, reducing the chance that the model fabricates or duplicates a signature block. Attachments carry a storage path, size, content type and origin. At send time, the API reloads every file and returns a conflict instead of sending if any object is unavailable.

The important remaining test is semantic: a real attachment can still be the wrong version or wrong client's document. Approval should make the filename, source and preview accessible. Tests must include similar filenames, an expired transient attachment, an oversized group of files and a draft body that incorrectly says “attached” after removal.

What happens when sending fails or repeats?

A provider failure should leave a visible unsent draft and a repeat confirmation should not create duplicate external messages. Failure and uncertainty must not be labelled as success.

The send route marks the Outbox record sent only after Gmail returns a message identifier. Missing Google connection, absent recipient, missing attachment and Gmail error return explicit failures. A record already marked sent returns alreadySent, reducing repeat sends through the same draft route.

There remains a difficult network edge: Gmail can accept a message while the application fails before storing sent. Retrying may duplicate it unless idempotency or Sent-folder reconciliation resolves the ambiguity. The adopted policy names idempotency and provider confirmation as action-gateway responsibilities, but the current route does not show a provider idempotency key or post-failure reconciliation. Publication requires a forced timeout after provider acceptance and proof of the user-visible outcome.

Is there really an undo button after sending?

Editing or discarding a draft is reliably reversible; recalling a message after provider acceptance is not. A product should not call both behaviours “undo.”

Some email clients create an undo-send experience by delaying delivery for a configured period. The current server route calls Gmail immediately after the user presses Send and then marks the draft sent. No delayed queue or cancellation endpoint is evident. Gmail's API response confirms submission; it does not guarantee recall from recipients' servers.

The honest statement is therefore: the user can review, revise, remove attachments and discard before sending. Once approved and accepted, the message should be treated as sent. If a future delay window is implemented, public copy must state its exact duration, which surfaces support it and what happens after the window closes.

Who it is not for

Approval-based AI sending is not suitable when an organisation requires dual control, formal correspondence sign-off, legal hold integration or a supervised communications archive the product does not provide.

Regulated mass communication belongs in a campaign or case-management system with consent, templates, suppression, delivery and approval controls. Shared mailboxes may require role-based approval and a record of which person authorised the message. High-risk legal, financial or employment statements may always require qualified human review regardless of draft quality.

A user who wants fully autonomous outreach is also asking for a different operating model. That model needs narrowly defined policy, recipient limits, monitoring and suspension controls; it should not be smuggled into a general assistant through a broad preference.

Conclusion: will the assistant send without permission?

The current design separates drafting from sending: internal drafts live in an editable Outbox, while outbound email is staged for a user confirmation and sent through a server-side Gmail gateway. The route validates recipients, reloads real attachments, appends the configured signature and marks success only after a provider response. That is the correct foundation for an approval promise. Publication still depends on product tests across Ask, Outbox, Telegram and the open-email surface, including group Bcc, changed recipients, missing files, provider timeouts and repeated taps. The product should not claim post-send undo because no verified delay or recall mechanism exists. The dependable control is a complete, meaningful review before the message leaves. That is the standard buyers should demand from every AI email assistant.