An AI Agent That Drafts Your Email, and Asks Before Sending

Email is the most tempting place to put an AI agent and the most dangerous place to give one autonomy. A message sent under your name to a customer, a candidate, or your board is not something you can un-send. One wrong reply costs more trust than a hundred good drafts earn back.

So the right design for an AI email agent is not "an agent that answers my email." It is "an agent that drafts my email, and asks before anything leaves the outbox." The draft is cheap to review and cheap to discard. The send is the only irreversible step, so the send is the only step that needs your signature.

This article walks through how to build exactly that with Skopx: a drafting agent whose Gmail or Outlook grant is set to drafts-only, or whose send action always parks as a pending approval you can inspect before it executes. Along the way we will cover how tone control actually works, what the approval screen shows you, and where this pattern breaks down.

Why drafting is the right job for an email agent

Think about what actually takes time in your inbox. Reading a message takes seconds. Deciding what to say takes a bit longer. But writing the reply, in full sentences, with the right tone, with the relevant context pulled in from your CRM or your last thread with this person, takes minutes. Multiply by forty messages a day and the writing is the bottleneck, not the judgment.

An agent that produces ready-to-edit drafts attacks the bottleneck without touching the judgment. You stay the decision-maker. The agent does the part that is slow but low-stakes: assembling context, matching your tone, structuring the reply. You do the part that is fast but high-stakes: deciding whether this draft actually goes out, and to whom.

This division holds up better than full autonomy for a simple reason: email failures are asymmetric. A draft that misses the mark costs you thirty seconds of editing. A sent email that misses the mark can cost you a deal, a hire, or a relationship. When failure costs are that lopsided, you keep the human on the irreversible step. We cover this principle more generally in our guide to AI agents with human approval, but email is the cleanest case for it.

The core mechanism: grants, and the drafts-only tier

In Skopx, every agent you build gets explicit grants per integration toolkit. A grant is not a vague "connect Gmail" toggle. It is a statement about what the agent may do with that toolkit and under what supervision. There are several tiers:

• Runs automatically. The agent can call any action in the toolkit without asking. Fine for read-only work, dangerous for sending.
• Asks first every time. Every write-shaped action parks as a pending approval. Nothing executes until you approve it.
• Agent decides when to ask. The agent uses judgment about which actions need sign-off, guided by your instructions.
• Drafts-only mode. The agent can create drafts but the send action is simply not available to it. There is nothing to approve because sending is off the table entirely.

For an email drafting agent, drafts-only is usually the right starting point. The agent reads incoming mail, writes replies, and saves them as drafts directly in your Gmail or Outlook drafts folder. You open your email client, and the replies are sitting there waiting. You edit or discard, and you press send yourself, in your own client, like you always have. The agent never touches the send button because it cannot.

Here is how the tiers compare for email specifically:

Notice that drafts-only and asks-first solve the same problem in different places. Drafts-only puts review in your email client, where you already live. Asks-first puts review in Skopx, where you can see the exact API call before it fires. Both keep a human on the send. The difference is workflow preference, not safety.

What the approval flow actually shows you

If you do grant send access under the asks-first tier, it is worth understanding precisely what happens, because "human approval" is a phrase that gets used loosely across the industry.

In Skopx, when the agent decides an email should go out, the send does not execute. It parks as a pending approval. The approval shows you the exact call and the exact arguments: the recipient address, the subject line, the full body, every field the API will receive. Not a summary of what the agent intends. The literal parked call.

When you approve, exactly that parked call executes, once. The agent does not get a second chance to rewrite the email between your approval and the send. What you read is what goes out. When you reject, nothing executes at all. And approvals can expire, so a draft reply to a Tuesday question does not fire awkwardly on Friday after the moment has passed.

This exactness matters more than it might seem. Some automation tools implement "approval" as a checkpoint where the agent resumes running after you click yes, which means the agent could take further actions you never saw. The parked-call model closes that gap: your approval authorizes one specific, fully visible action and nothing else. Reads still flow without approval under this tier, so the agent can search your inbox and pull thread history freely. Only write-shaped actions park.

Tone control lives in the instructions

The most common worry about AI-drafted email is not safety, it is voice. "It will sound like a robot." "It will sound like a press release." "My customers will know."

This is solvable, and the solution is unglamorous: you write it down. A Skopx agent runs on plain-language instructions that you can read and edit at any time, and tone rules belong in them, stated as concretely as you can manage. Vague direction produces vague drafts. Compare:

Weak: "Write in a friendly, professional tone."

Strong: "Write like I do. Short sentences. First names, no honorifics. Never open with 'I hope this email finds you well.' Never apologize for delay unless the delay was over three business days. Sign off with just my first name. If declining something, decline in the first two sentences, then soften. Keep replies under 150 words unless the question genuinely requires more."

The second version is falsifiable. You can look at a draft and check it against each rule, and when a draft misses, you know which line of the instructions to sharpen. Instructions in Skopx are versioned, so you can tighten them run over run without losing track of what changed and when. A useful exercise: paste three of your own recent sent emails into the chat while building the agent and say "match this." Concrete examples beat adjectives every time. We go deeper on this craft in the guide to writing agent instructions.

Two tone rules deserve special mention for email agents:

1. Tell the agent when not to draft. "If the email is emotionally charged, legally sensitive, or from anyone at these three domains, do not draft a reply. Flag it in the report instead." An agent that knows its limits is worth more than one that drafts everything.
2. Tell the agent what it does not know. "Never invent details about pricing, timelines, or commitments. If the reply requires information you do not have, draft the email with a bracketed placeholder like [CONFIRM: ship date] so I can fill it in."

Building the agent: a concrete walkthrough

Here is what assembling this agent looks like in practice. In Skopx you build agents by describing them in chat at the Create Agent screen. No canvas, no node graph, no code. You say what you want, the chat assembles the agent, and the workspace shows the agent's full anatomy beside the conversation so you can see exactly what you are getting. The general process is covered in how to create an AI agent, but the email-specific version goes something like this.

You start with a description: "I want an agent that checks my Gmail every morning at 7:00 UTC, finds unanswered emails from the last 24 hours that actually need a reply from me, and writes draft replies in my voice. It should skip newsletters, notifications, and anything already answered. Save the drafts in Gmail. Never send anything."

The chat turns that into the agent's parts, each of which you can inspect and adjust:

• Instructions: the drafting rules, tone rules, and skip rules, in plain language you can edit later.
• Trigger: a schedule, "Every day at 7:00 UTC." You could also make it manual (runs when you ask) or webhook-triggered on new mail. For a first-drafts agent, the morning schedule is a good rhythm: one batch, one review session, instead of interruptions all day.
• Grants: Gmail in drafts-only mode. That single setting is the safety architecture.
• Budgets: caps on tokens per run, tokens per day, maximum steps, and a minute cap. If the agent hits budget failures three times, it auto-pauses rather than burning quietly in the background.
• Success criteria: what a good run looks like, for example "every genuine unanswered email from the window either has a draft or an explicit skip reason in the report." Each run's report is evaluated against these criteria.

Then you run it once, manually, and read the run. Every Skopx run has a step timeline with humanized labels you can expand into raw results, a duration, a token count, and a final markdown report. For a drafting agent the report is your morning digest: which emails it drafted replies for, which it skipped and why, and which it flagged as needing your personal attention. If the first run drafts a reply to a newsletter or skips something important, you edit the instructions and run again. Expect two or three iterations before the skip logic matches your actual inbox.

Pairing drafting with triage

Drafting answers the question "what do I say?" But there is an upstream question: "which of these 80 messages even deserve a reply?" That is a triage problem, and it is a distinct job with distinct instructions. Many teams run it as a separate agent that labels and prioritizes incoming mail, which we cover in detail in AI agent inbox triage.

You can combine both jobs in one agent, and for a personal inbox that often works fine: triage first, then draft for the messages that clear the bar. The single-agent version is simpler to maintain. The split version is easier to debug, because when a draft is wrong you know whether the failure was "should not have drafted this at all" or "drafted it badly." Start combined, split if the instructions grow unwieldy.

One more pairing worth knowing: the drafting agent gets much better when it can pull context beyond the thread. With additional read grants, it can check HubSpot or Salesforce for the sender's deal stage before drafting, or look at your Google Calendar before proposing meeting times. Skopx agents can reach nearly 1,000 integrations, so the context that makes a draft feel informed rather than generic is usually one read grant away. Browse what is connectable at skopx.com/integrations.

Memory: why the second week is better than the first

A Skopx agent keeps memory that persists between runs. For an email drafting agent this does quiet but real work. The agent remembers where it left off, so a 7:00 run processes mail since the last run instead of re-reading the whole inbox. It can carry baselines and cursors forward, which makes second and subsequent runs produce delta reports, and typically makes them cheaper than the first.

Memory also compounds the tone problem in your favor. When you consistently edit the agent's drafts in a particular direction, you can fold those corrections back into the instructions: "I keep deleting your second paragraph, stop restating the sender's question before answering it." The agent does not silently learn from your edits on its own, and it is better that way. Explicit instruction changes are visible and versioned. Silent drift would mean you no longer know what your agent believes about your voice.

Where this pattern breaks down

Candor section. An email drafting agent is genuinely useful, and there are situations where you should not use one, or should constrain it harder.

High-stakes threads. Negotiations, legal matters, anything involving a personnel issue. The cost of a subtly wrong draft is not the edit time, it is the risk that a plausible-sounding draft anchors your own thinking in the wrong place. Tell the agent to flag these and stay out.

Email that is really a relationship. If you have three investors or five key customers, you do not need drafts for them, and they can tell. Volume is the case for drafting. Low-volume, high-touch email is not.

Perfect voice matching. The agent will get to "clearly written by my team, in our style" quickly. It will not get to "indistinguishable from me on my best day." If the last five percent of voice matters, budget editing time for it, permanently.

Approval fatigue. If you use the asks-first tier and the agent generates thirty send approvals a day, you will start approving without reading, which defeats the entire mechanism. This is a signal to move to drafts-only, where review happens in your natural email flow, or to tighten the triage rules so fewer drafts exist. An unread approval is worse than no approval, because it launders an unreviewed action through a reviewed-looking process.

Webhook-triggered instant replies. Tempting, and mostly a mistake for drafting agents. Reply latency of two minutes signals automation to the recipient, and it converts your inbox from a batch process back into an interrupt stream. Also, webhook payloads are treated as untrusted data in Skopx for good reason: an inbound email is attacker-controlled text, and you do not want its contents steering an agent that holds a send grant. Drafts-only plus a schedule sidesteps most of this risk.

If any of these limits sound disqualifying for your situation, they might be. Our honest take on when not to use AI agents covers the broader decision.

What this costs and what it needs

The agent runs on whichever model you pick for it: Claude, GPT, Gemini, Kimi, or others across eight providers. You can bring your own API key with zero markup, or use the $16 per seat Team plan with included tokens. A daily drafting run over a normal inbox is a bounded, predictable workload, and the budget caps you set per run and per day keep it that way. Because run history is append-only and every run reports its token count, you can see exactly what a week of drafting costs you in tokens and decide whether the arrangement earns its keep.

The full agent surface, including how autonomous agents sit alongside chat and workflows, is at skopx.com/agents.

FAQ

Can the agent send emails completely on its own?

Only if you grant it that, and for external email you mostly should not. With the "runs automatically" tier on Gmail or Outlook, sends execute without asking. With "asks first every time," every send parks as an approval showing the exact recipient, subject, and body, and executes only when you approve. With drafts-only, the send action is unavailable to the agent entirely. The safe default is drafts-only; graduate to approval-gated sending only for narrow, well-defined cases like internal status notes.

How does the agent learn my writing style?

Through instructions, not magic. You describe your voice with concrete rules, paste examples of your real sent emails, and iterate: run the agent, read the drafts, edit the instructions where drafts miss. Instructions are versioned, so each refinement is recorded. The agent does not silently train on your mailbox; changes to its voice happen only when you change what it is told.

What happens to a draft I never send?

Nothing. Under drafts-only mode, drafts sit in your email client's drafts folder like any draft you wrote yourself. Delete them, edit them, ignore them. Under the approval flow, a parked send you never act on can expire, and an expired approval executes nothing. In both designs, inaction is always safe.

Can it check my CRM or calendar before drafting?

Yes, with read grants for those toolkits. A common setup gives the agent read access to HubSpot or Salesforce so a reply to a prospect reflects their actual deal stage, or read access to Google Calendar so proposed meeting times are ones you can actually make. Reads flow without approvals, so this context gathering does not add review overhead. The write-shaped action, the send, remains the single gated step.

How do I stop it if a run goes sideways?

Two levers. You can stop an individual run mid-flight from its run view. And pausing the agent acts as a kill switch for queued runs, so nothing further executes until you unpause. Combined with drafts-only grants, the worst case for a bad run is a batch of bad drafts, which you delete. That bounded worst case is the whole point of the design.