Can you automate Gmail replies without sending them automatically?

Yes, and it is the safe default. An agent built on the Gmail API reads the message, writes a reply, and saves it as a Gmail draft instead of sending. You open the draft, edit if needed, and click send yourself. On Major, sending stays gated behind the person who owns the mailbox.

How do you build a custom Gmail automation?

Build on the Gmail API. Use watch, via Google Cloud Pub/Sub, to react to new mail, read the messages resource, apply labels, and save replies as drafts, requesting the narrowest OAuth scope the job needs, usually gmail.modify. On Major, the OAuth grant lives behind a credential proxy and triage history lands in a managed database.

Is it safe to let AI act on my inbox?

With the right guardrails, yes. Scope the OAuth grant to read, label, and draft (gmail.modify) rather than send, so the agent never sends or deletes on its own. Keep the default at drafts for human approval, and log every classification, label, and draft. Major enforces that with a credential proxy, RBAC, and an audit log.

Can an AI agent remember what it already did in my inbox?

Only if it has somewhere to keep that memory, because a model's context window resets between runs. Without persistence, a triage agent re-reads the same thread every morning and can draft a second reply. Major keeps processed message IDs, classifications, and escalations in a managed database inside the app.

Gmail Automation: From Filters to an Inbox-Triage Agent

Filters and templates sort your mail, but they can't read it. Here's the next step: an inbox-triage agent that classifies email, drafts replies for one-click approval, and captures leads to your CRM, with guardrails.

Jose GironJuly 20, 2026Updated October 21, 2026

Major x Gmail lockup for an inbox-triage agent that classifies email and drafts replies

What is Gmail automation, and where does it stop?

Gmail automation is the set of built-in rules that sort and send mail for you: filters, labels, canned-response templates, and schedule-send. These rules are deterministic, free, and correct for what they do. They cannot read a message and decide what it means. An inbox-triage agent can, and on Major that agent builds the app that runs the repeatable parts so the model only handles judgment.

If a filter labels every receipt from stripe.com as Finance, leave it alone. It runs the same way forever. The gap starts when the decision depends on meaning. A filter cannot tell an angry customer from a routine question that shares the same keywords. It cannot spot that "quick question about pricing" from an unknown domain is a lead worth logging.

Here is how the three common approaches compare:

Gmail filters and templates: match sender, subject, and keywords. No judgment, no drafting, fires automatically.
Zapier or Make: move fields between tools. An optional AI step can classify, but each step is one prompt, and auto-send is the usual default.
Inbox-triage agent on Major: reads the full message, classifies it, drafts a reply, writes to the CRM, and pings Slack, with a person approving every send.

What an inbox-triage agent does

Three jobs filters cannot do.

Classify. The agent reads the body and headers and assigns lead, client, invoice, or junk, with a confidence score. Anything below your threshold goes to a person instead of a guess.

Draft. For messages that warrant a reply, the agent saves a Gmail draft. It does not send. You read it, edit it, and click send. The drafting is automated and the sending stays yours.

Route. A lead becomes a HubSpot or Salesforce record so it does not die in an inbox. An urgent client issue, a churn signal, or an outage report from a key account posts to a Slack channel with a link to the thread.

What the Gmail API gives you

Messages are immutable. The agent cannot edit an email, so it changes state by adding or removing labels. Drafts are a first-class resource, so "write but do not send" is a native operation. For near real-time reaction, call watch on the mailbox and Gmail publishes to a Google Cloud Pub/Sub topic whenever the inbox changes.

POST https://gmail.googleapis.com/gmail/v1/users/me/watch with labelIds set to ["INBOX"] and a topicName for your Pub/Sub topic.

Two gotchas matter before you build. A watch subscription expires and must be renewed at least every seven days, so something has to re-arm it on a schedule or the agent goes quiet. And gmail.readonly, gmail.modify, and the full mailbox scope are restricted scopes. An app that requests them and stores that data goes through Google's restricted-scope verification and often a third-party security assessment, so budget for that review early.

Request the narrowest scope that works. gmail.modify covers reading, labeling, and drafting. gmail.send is a separate scope, and the agent should not hold it.

Build the Gmail inbox-triage agent on Major

Major is the enterprise platform where agents build the software they run on. For this problem that means the triage logic does not get re-reasoned on every email. The agent works out the classification rules, thresholds, and routing once, builds an app for them, and runs the app from then on. Reason once. Run forever.

The pieces:

Connectors. Gmail, HubSpot (or Salesforce), and Slack, each connected through scoped credentials. The agent calls them through a credential proxy and never holds a raw token.
The app that holds state. A triage app with a managed database. A processed_messages table stores message IDs, category, confidence, the draft ID, and the CRM record ID. A person reviews the queue in the app's view and sees what the agent did and why.
The agent and its judgment. The model reads each new message and decides the category and whether a reply is warranted. That is the only step that needs reasoning. Labeling, the CRM write, and the Slack post run as deterministic code in the app.
The trigger. A workflow fires on the Pub/Sub notification from watch, and a second scheduled workflow renews the watch subscription before the seven days are up.
Governance. The Gmail grant is scoped to read, label, and draft. RBAC decides who can see the triage queue and who can change thresholds. Every classification, label, draft, and CRM write lands in the audit log.
Memory. Because the app stores processed message IDs, the agent does not re-read yesterday's threads or draft a second reply to something already answered. That is the difference between state in a database and state in a context window.

Start building the triage agent on Major.

How a message moves through the app

A new email arrives and Gmail publishes a notification to Pub/Sub.
The workflow wakes the app, which fetches the message and checks the database to confirm it has not been handled.
The agent classifies it as lead, client, invoice, or junk, with a confidence score.
A lead gets a CRM record and a drafted reply. A client issue gets a label, a draft, and a Slack ping to the account owner. An invoice is labeled for finance. Junk is labeled and archived.
The app records every step. A person opens each draft and clicks send.

As the app handles more mail, the model carries a smaller share of the work. The rules it needed are already code, so cost is front-loaded and then flat rather than climbing with every email.

What the agent should never do

Hold the boundary in plain terms. The agent drafts and labels. It does not auto-send and it does not delete mail unattended. If you want to loosen that later, change the scope deliberately and log the change.

This walkthrough covers triage and drafting on an inbox you own. It does not cover cold outreach or bulk mail merge, which tools like Mailmeteor already do, and it does not replace spam filtering. Keep the filters you trust. The agent handles the reading and deciding that rules cannot encode.

Start building on Major

Build the Gmail inbox-triage agent on Major, with Gmail, your CRM, and Slack connected through scoped credentials, a managed database holding every decision, and a human clicking send on every draft.

Frequently asked questions

What is Gmail automation?: Gmail automation is the set of built-in rules that sort and send mail for you: filters that label, archive, or forward on a match, templates for canned replies, and schedule-send. Those are deterministic and rule-based, so they do exactly what you wrote and nothing more. An inbox agent goes further, reading each message and deciding what it means, which filters cannot do.
Can you automate Gmail replies without sending them automatically?: Yes, and it is the safe default. An agent built on the Gmail API reads the message, writes a reply, and saves it as a Gmail draft instead of sending. You open the draft, edit if needed, and click send yourself. On Major, sending stays gated behind the person who owns the mailbox.
How do you build a custom Gmail automation?: Build on the Gmail API. Use watch, via Google Cloud Pub/Sub, to react to new mail, read the messages resource, apply labels, and save replies as drafts, requesting the narrowest OAuth scope the job needs, usually gmail.modify. On Major, the OAuth grant lives behind a credential proxy and triage history lands in a managed database.
Is it safe to let AI act on my inbox?: With the right guardrails, yes. Scope the OAuth grant to read, label, and draft (gmail.modify) rather than send, so the agent never sends or deletes on its own. Keep the default at drafts for human approval, and log every classification, label, and draft. Major enforces that with a credential proxy, RBAC, and an audit log.
Can an AI agent remember what it already did in my inbox?: Only if it has somewhere to keep that memory, because a model's context window resets between runs. Without persistence, a triage agent re-reads the same thread every morning and can draft a second reply. Major keeps processed message IDs, classifications, and escalations in a managed database inside the app.