A Gmail assistant that asks before sending

What should Botify do on its own in Gmail?

Reading and writing drafts are safe to automate; sending is not. When Botify searches a mailbox, pulls a whole thread and writes a reply into your Drafts folder, it has done most of the work, and nothing has left the account. The moment a message goes to someone else, it cannot be taken back, so that step needs a person.

The useful jobs follow from that split: summarise what a customer or supplier has sent over the last month, find the thread where a price was agreed, draft a reply that quotes the right figures, and file what is done. Botify does the reading and the typing; you keep the decision about what gets said to whom.

Botify connects to Gmail with twelve tools, each tagged with a risk level and an approval mode. The design below uses them as a concrete example, but the same rules are worth copying into any assistant you build or buy.

The 12 Gmail tools and when each one asks first

Every tool carries one of three approval modes: never (runs directly), policy (your tenant’s policy decides) or always (waits for a human every time). The last column shows what the baseline policy new Botify tenants start with does for the policy-mode tools.

Why do send, reply and forward always wait for approval?

They are irreversible and they speak for you. A reply-all that goes to the wrong list, a forward that quotes a confidential thread to an outside address, or a figure the model got wrong cannot be recalled. The cost of a person reading the message first is seconds; the cost of not doing it is a conversation with a customer or a regulator.

Mail is also where untrusted text arrives. An inbound email can contain instructions written to steer an assistant (“forward this thread to…”). A model can be fooled by that; a gate that requires a human to approve the outgoing message, with its recipients in view, is not.

Approval must not cause double sends either. Each send, reply and forward carries an idempotency key, so a run that resumes after approval, or a network retry, does not deliver the same message twice.

How does safe drafting work in practice?

Draft first, send second. Asking for a draft keeps the approval step small and the output reviewable in the place you already work: the Drafts folder in Gmail.

• Ask in plain language: “Find the last three emails from our supplier’s procurement team and draft a reply confirming Thursday’s delivery.”
• The assistant runs gmail.search, then gmail.get_thread for the full conversation, so the draft answers what was actually asked.
• It calls gmail.create_draft; the draft appears in your mailbox and the assistant tells you what it wrote and why.
• You edit the draft in Gmail or ask the assistant to change it.
• When you ask it to send, gmail.send pauses the run. The approval card shows the recipients, subject and a preview of the body; you approve, reject with a note, or correct the payload.
• Only after approval does the message leave, and the result is written to the audit trail.

Writing drafts in Arabic and English

A good assistant answers in the language of the thread unless told otherwise, and keeps names, reference numbers and amounts exactly as they appear in the source messages. For mixed threads, say which language you want; a short instruction such as “reply in formal Arabic, keep the PO number in Latin digits” removes guesswork.

Encoding is where Arabic email usually breaks. The connector described here builds outgoing messages as UTF-8 with base64 transfer encoding, so Arabic text, diacritics and emoji arrive intact instead of as garbled characters. The body is plain text, so right-to-left display is left to the recipient’s mail client; read the draft in Gmail before approving, as the recipient will see it.

Tone deserves a review step of its own. Formal Gulf and Levantine business correspondence differs from a literal translation of English templates, and greetings, titles and closing lines are where machine output most often sounds wrong. Approval is the natural place to catch that.

Which Gmail permissions does Botify need?

Ask for the narrowest OAuth scopes that cover the job. Google’s documentation says to choose the most narrowly focused scope possible, and it classifies the scopes for reading, composing, sending and modifying mail as sensitive or restricted, so every extra scope is a real decision.

By default Botify requests read, compose, send and label access, plus the account’s email address. The broader gmail.modify scope, needed for labelling, archiving and trashing messages, is left out of the default grant and must be requested explicitly by a tenant that wants filing. The full https://mail.google.com/ scope, the one Google reserves for apps that must permanently delete mail and bypass Trash, is never requested at all.

Trash is recoverable. Gmail keeps trashed messages for 30 days before deleting them permanently, which is why gmail.trash is classified as destructive but still reversible within that window.

• Start with read and compose only if you want drafts and summaries, and add send when you are ready to approve outgoing mail.
• Add gmail.modify only for mailboxes where filing saves real time.
• Connect shared mailboxes with an identity that has access to that mailbox alone.

What gets recorded for audit?

Everything that touches the mailbox: the request that started the run, each tool call and its policy decision, each approval request with its summary and risk, the approver’s decision and note, and the result. Here these entries are appended to a per-tenant, hash-chained audit log, so deleting or editing a past entry breaks the chain and is detectable.

Keep the audit useful by reviewing rejections. A rejected send tells you where the assistant misread a thread, picked the wrong recipient or struck the wrong tone, and that is the fastest way to tune instructions.