AI Agents for Gmail: Triage, Draft, Send With Approval

Email is where an AI agent earns its keep or loses your trust in a single afternoon. An agent that reads your inbox and summarizes what matters is useful on day one. An agent that sends email on your behalf without a checkpoint is a liability, no matter how good the model behind it is.

This article walks through how a Gmail agent actually works on Skopx: what the Gmail toolkit exposes, how grant tiers separate reading from sending, the triage and drafting patterns that hold up in practice, and why every send should route through an approval. The short version of the philosophy: let the agent read freely, let it draft freely, and make it ask before anything leaves your outbox.

What a Gmail agent can actually do

Skopx agents connect to Gmail through a Composio-backed toolkit, one of nearly 1,000 integrations available on the platform. Once you connect your Gmail account, an agent granted the toolkit can work with the same objects you see in the Gmail UI: messages, threads, labels, and drafts.

In practical terms, the useful operations fall into two buckets.

Read-shaped operations:

• Search the inbox with Gmail's query syntax (from a sender, newer than a date, has attachment, specific label)
• Fetch full message content and thread history
• List labels and see how mail is currently organized

Write-shaped operations:

• Create a draft reply on a thread
• Send a message
• Apply or remove labels, archive, or modify a thread's state

The distinction matters because Skopx treats these buckets differently. Read-shaped calls can flow without interruption. Write-shaped calls can be parked as pending approvals that show you the exact call and its arguments before anything executes. That split is the foundation of every pattern in this article.

If you want the general mechanics of building any agent first, the walkthrough in how to create an AI agent covers the full flow. Here we stay focused on the Gmail specifics.

Grant tiers: the difference between reading and sending

When you attach the Gmail toolkit to an agent on Skopx, you choose how much autonomy the agent gets with it. There are three tiers, plus a drafts-only mode:

1. Runs automatically. The agent uses Gmail tools without asking. Reasonable for a read-only research agent; risky for anything that can send.
2. Asks first every time. Every Gmail action parks as a pending approval. You see the exact call and arguments, and nothing happens until you approve.
3. Agent decides when to ask. The agent uses judgment: routine actions flow, consequential ones come to you. Under this tier and under approval_required generally, reads still flow without approval; it is the write-shaped actions that get parked.
4. Drafts-only mode. The agent can create drafts in your Gmail account but cannot send. You review drafts in Gmail itself and hit send yourself.

Here is how those tiers map to common Gmail agent jobs:

The pattern most people converge on: start at "asks first every time," watch a week of runs, then relax specific low-stakes actions once the agent has shown you what it actually does. The broader reasoning behind this progression is covered in AI agents with human approval.

One honest caveat: no grant tier makes the agent's judgment perfect. Tiers control what the agent can do without you, not whether its draft is any good. Expect to edit drafts, especially in the first weeks. The agent gets better instructions from you; it does not read your mind.

Pattern one: inbox triage

Triage is the highest-leverage Gmail agent because it is mostly reads with a few cheap writes. A typical triage agent on Skopx looks like this:

Instructions (plain language, editable, versioned):

Every morning, review all unread email from the last 24 hours. Sort into: needs my reply today, FYI only, newsletters and promotions, and potential problems (angry customer, failed payment, deadline mentioned). Apply the matching Gmail labels. In your report, list the "needs reply today" messages with a one-line summary each and a suggested response angle. Flag anything that mentions money, legal matters, or a deadline within 72 hours.

Trigger: a schedule, for example "Every weekday at 7:30 UTC." Scheduled triggers are the natural fit for triage; the mechanics are covered in scheduled AI agents.

Grants: Gmail at "agent decides when to ask." Labeling flows automatically; if the agent ever wants to archive or modify something unexpected, that comes to you as an approval.

Success criteria: something the run report can be evaluated against, for example "Every unread message from the window is categorized, and every message mentioning money or a deadline appears in the flagged list."

The output of each run is a markdown report rendered as a document: your categorized inbox, the priority list, the flags. You read one document instead of forty subject lines. Skopx run reports include the full step timeline with humanized labels, duration, and token count, so when the agent miscategorizes something you can expand the exact step and see what it read and why.

Memory is what makes triage compound. Skopx agents keep memory between runs: cursors and baselines persist, so the second run knows where the first one stopped. In practice that means run two processes only new mail and produces a delta report, which is faster and typically cheaper than run one. How that works under the hood is explained in AI agent memory explained.

Pattern two: reply drafting

Drafting is where a Gmail agent saves real time, and where the guardrails matter most. Two viable setups:

Drafts-only mode. The agent reads a thread, writes a reply, and saves it as a Gmail draft. It never sends. You open Gmail, find drafts waiting on the threads that needed replies, edit if necessary, and send. This is the lowest-trust, lowest-risk configuration, and for many people it is the permanent end state, not a stepping stone. There is nothing wrong with an agent that never earns send permission.

Send with approval. The agent composes the reply and calls the send tool. That call parks as a pending approval in Skopx. You see the exact arguments: the recipient, the subject, the full body, the thread it attaches to. Approving executes exactly that parked call, once. Rejecting executes nothing. Approvals can expire, so a stale draft from Tuesday cannot fire on Friday after the situation changed.

The precision of that approval mechanism is the point. You are not approving "the agent may send an email." You are approving one specific message, exactly as shown. If the agent then wanted to send a second, different message, that would be a new approval. There is no gap between what you reviewed and what executes.

Instructions for a drafting agent should encode your voice concretely:

Draft replies in my voice: short sentences, no exclamation marks, sign off with "Best, Sara." Never commit to a meeting time without checking my calendar first. If the sender is angry, acknowledge the frustration in the first sentence before anything else. If you are less than confident about the right answer, draft the reply as questions back to the sender instead of guessing.

Because instructions are versioned on Skopx, you can tighten them after every miss and roll back if an edit makes things worse. A deeper treatment of instruction writing lives in the AI agent instructions guide.

Pattern three: follow-up and chasing

The third durable pattern is outbound: chasing unanswered emails. A follow-up agent searches for threads where you sent the last message more than N days ago and no reply arrived, then drafts a polite nudge for each.

This is the pattern where "asks first every time" is the right call almost without exception. Follow-ups go to external people: customers, candidates, vendors. A tone-deaf nudge to someone who already replied on another channel, or a chase sent to someone who is out on leave, costs you something real. Routing every send through approval means the worst case is that you reject a bad draft, which costs ten seconds.

Memory earns its keep here too. The agent's memory records which threads it has already nudged and when, so it does not chase the same person twice in a week. Without persistent state, follow-up agents become spam machines; with it, they are a patient assistant with a tickler file.

Budgets: the other guardrail

Approvals control what an agent does. Budgets control how much it does. Every Skopx agent carries budgets: tokens per run, tokens per day, a maximum step count, and a minute cap. If the agent hits a budget limit, the run stops. Three budget failures in a row auto-pause the agent entirely.

For Gmail agents this matters because inboxes are unbounded. A triage agent pointed at an inbox with 4,000 unread messages should not attempt to read all of them in one run; a step cap and token-per-run budget force it to work in slices, and its memory cursor picks up where it left off next run. Set budgets by watching your first few runs: the run history shows the token count and duration for each, which gives you a realistic baseline instead of a guess.

And if a run goes sideways in real time, you can stop it mid-flight. Pausing the agent is a kill switch for any queued runs. Run history is append-only, so even a stopped run leaves its full timeline behind for inspection.

Setting one up on Skopx, start to finish

Building this does not involve code or a canvas. On Skopx, you describe the agent in chat at Create Agent, and the chat assembles it:

1. Describe the job. "Build an agent that triages my Gmail every weekday morning, labels everything, and drafts replies to the messages that need one, drafts only, no sending."
2. Connect Gmail. Attach the Gmail toolkit and connect your account. Connected credentials are encrypted, and there are security controls in place around how agents use them.
3. Review the assembled agent. The chat produces the instructions (which you can edit directly, and every edit is versioned), the trigger, the grants, and default budgets. Adjust the Gmail grant to drafts-only mode.
4. Pick a model. You choose per agent among Claude, GPT, Gemini, Kimi, and others, either bring-your-own-key across eight providers with zero markup or the $16 per seat Team plan with included tokens. Triage is a good fit for a fast, inexpensive-tier model; nuanced drafting may deserve a stronger one.
5. Set success criteria. "All unread mail from the window is labeled; every needs-reply message has a draft attached to its thread." The run report is evaluated against these.
6. Run it manually first. Before trusting the schedule, trigger a manual run and read the whole step timeline. Manual-first is the safest testing posture; more on that in the sibling piece on testing agents safely.
7. Turn on the schedule once a manual run looks right.

Your Gmail agent then lives in the agents workspace alongside every other agent you have built, each with its own run history, memory, and grants.

Where a Gmail agent falls short

Candor section. A Gmail agent is not a good fit for everything, and knowing the limits saves you the disappointing week of finding them yourself.

It will not match your judgment on sensitive threads. Negotiations, HR matters, anything legal, anything where subtext dominates text: draft yourself. An agent can summarize these threads for you; it should not speak for you in them.

Drafts need editing, especially early. Expect the first weeks to be a training period where you tighten instructions after every clunky draft. The agent improves because you improve its instructions, not by osmosis.

Triage categories drift. Your definition of "needs reply today" changes with your workload. Revisit instructions monthly or the labels slowly stop matching reality.

It cannot fix a broken inbox strategy. If you are getting 400 irrelevant emails a day, the fix is unsubscribing and filtering upstream, not a smarter summarizer. The agent helps most when the inbox is noisy but the noise has structure.

Approval fatigue is real. If you set "asks first every time" on high-volume actions like labeling, you will drown in approvals and start rubber-stamping, which defeats the purpose. Reserve strict approval for sends and other consequential writes; let cheap reversible actions flow.

FAQ

Can the agent send email without my approval?

Only if you explicitly grant the Gmail toolkit at the "runs automatically" tier. Under "asks first every time," every send parks as a pending approval showing the exact recipient, subject, and body; approving executes exactly that call once, and rejecting executes nothing. Under drafts-only mode, the agent cannot send at all. Most people should start with drafts-only or full approval and stay there until the agent has a track record.

How do I see what the agent actually did in my inbox?

Every run has an append-only step timeline: each Gmail call appears as a humanized step you can expand to see the raw result, alongside the run's duration and token count. The run ends in a markdown report evaluated against your success criteria. If the agent labeled something wrong, you can find the exact step where it read that message and see what it saw.

Will it re-read my whole inbox every run?

No, if you set it up with memory in mind. Skopx agent memory persists between runs, so the agent keeps a cursor of what it has already processed and each subsequent run handles only new mail, producing a delta report. Second and later runs are typically cheaper than the first for exactly this reason.

What happens if the agent starts misbehaving mid-run?

You can stop a run in flight, and pausing the agent acts as a kill switch for anything queued. Budgets provide the automatic backstop: caps on tokens per run, tokens per day, steps, and minutes stop a runaway run on their own, and three budget failures auto-pause the agent entirely.

Is drafts-only mode a temporary training setting or a real end state?

Either. Some users graduate their agent to send-with-approval once drafts consistently need no edits. Plenty keep drafts-only permanently because reviewing drafts inside Gmail fits how they already work. There is no pressure to escalate autonomy; the tiers exist so you can pick the trust level that matches the stakes of your mail.

Where to go from here

A Gmail agent is usually the first agent people build because the pain is universal and the feedback loop is immediate: you know within one morning whether the triage report matches your own read of the inbox. Start with the triage pattern on a schedule, add drafts-only reply drafting once the categories look right, and hold sends behind approval for as long as it takes the agent to earn otherwise.

From there the same anatomy extends outward: the follow-up pattern becomes invoice chasing when pointed at billing threads, and the triage pattern becomes a full morning brief when the agent can also read your calendar and your team's Slack. The inbox is just the first tool the agent sits above. Catching what falls between all of them is the actual job.