Gmail AI agents: triage requests without losing urgent work

A well-configured Gmail AI agent is not there to answer everything: it is there to decide quickly what deserves a reply, what lacks information, what is urgent and what is not your responsibility. This guide gives you a four-category triage taxonomy, explicit priority rules, a fictional set of eight messages to test your setup, and a method to measure what really matters: urgent items slipping through.

Why the taxonomy comes before the tool

Many teams start by connecting a Gmail assistant to their inbox, then discover that the agent classifies poorly because nobody defined what "classify" means. The taxonomy is not a settings detail: it is the contract between your organization and the agent. Without it, every message becomes a matter of interpretation, and email automation produces inconsistent decisions you will have to fix by hand.

A useful taxonomy has three properties. It is short: four categories maximum at the first level, otherwise nobody remembers them. It is decision-oriented: each category triggers a clear action, not just a decorative label. It is testable: you can take a real or fictional message and two reasonable people will agree on the category.

The four operational categories

To handle: the request is clear, within your scope, and someone on your team must act. Example: a customer asks for a copy of their March invoice. The expected action is identifiable even if it is not yet scheduled.

Missing information: the request seems legitimate and within your scope, but you cannot act without an element. An order number, a desired date, an attached document is missing. The right action is not to process but to request the missing element — or to flag it to whoever will.

Urgent: the request is to be handled and the deadline is short or the cost of inaction is high. An urgency is defined by two cumulative dimensions: content (an outage, a deadline, a blocked customer) and an explicit time constraint ("before tomorrow 10 a.m.", "server down"). A message shouting "URGENT" in the subject line while asking for a quote for three months from now is not urgent.

Out of scope: the request is clear but does not concern your business — an unsolicited application for a position you do not have, sales prospecting, a message meant for someone else. The right action is archiving or a standard redirect reply, not processing.

These four categories can combine: an urgent message can also lack information. In that case, the priority is to handle the urgency, and the request for information is part of the handling. That is a priority rule, not a fifth category.

Priority rules: evaluation order matters

The agent must evaluate the categories in a fixed order, otherwise edge cases flip at random. An order that works well:

1. Out of scope first: if the message does not concern you, no point analyzing its urgency.
2. Urgent next: if signals of a critical deadline and impact exist, the urgent category overrides missing information.
3. Missing information: if the message is in scope but incomplete, with no urgency signal.
4. To handle: the default case once the three filters have passed.

Each rule must be worded in a verifiable way. "Urgent if the tone is worried" is unverifiable; "urgent if the message mentions a dated deadline under 48 hours or an ongoing service outage" is verifiable. You can adjust these thresholds — 48 hours is a hypothetical example, not a standard — but the wording must remain observable in the message text.

Also provide a doubt rule: if the agent hesitates between two categories, it picks the more cautious one (to handle rather than out of scope) and flags it. A false positive costs a few seconds of human reading; a false negative costs a customer.

Gmail labels: useful, but not boundaries

Labels are the natural carrier of this taxonomy: tri/a-traiter, tri/info-manquante, tri/urgent, tri/hors-perimetre. They make the triage visible in the interface, enable per-category views and serve as a trace for your measurements.

Two precautions. First, a label is not a Gmail permission boundary: adding or removing a label does not restrict what the agent can do with the message. Second, an OAuth scope granted to the agent may cover more than you imagine: the gmail.compose and gmail.modify scopes can also allow sending messages. If you want the agent limited to preparing drafts, that limit must come from your application-level controls — your agent's logic — not from the choice of label or scope alone. The official documentation on Gmail API scopes details what each authorization level covers.

A fictional set of eight messages: test before deployment

Before letting an agent triage your real inbox, submit a set of fictional messages covering edge cases. Here is a hypothetical set of eight messages, with the expected category:

#	Message (summary)	Expected category	Trap
1	"Could you resend the March invoice?"	To handle	Simple, unambiguous
2	"I want to order, please call me back" with no contact details	Missing information	Legitimate request, unactionable
3	"Our site is down, we're losing sales, call us before noon"	Urgent	Dated deadline + impact
4	"URGENT: quote for a project planned for next year"	To handle	The word URGENT is not enough
5	Unsolicited application for a position that is not open	Out of scope	Serious tone, but off-topic
6	"The delivery never came, third time, we need an answer today"	Urgent	Complaint + time constraint
7	"Following our exchange, here is the order number: 48291"	To handle	Answers a request for info: the thread's category becomes to handle
8	Partnership request from an unrelated sector	Out of scope	Can look like an opportunity

Comment on the trap cases. Message 4 tests the rule "urgency is proven, not declared". Message 7 tests conversation tracking: a message that supplies requested information changes the thread's category. For that tracking, your agent must read the latest state of the thread, not just the last message in isolation — a topic developed in our guide on automatic email management and thread tracking. An agent that ignores history will reclassify message 7 as "missing information" and ask the customer again for a number they just provided.

Step-by-step implementation procedure

1. Write the taxonomy on one page: four categories, a one-sentence definition each, two real or realistic examples per category.
2. Formulate the priority rules in order: out of scope, urgent, missing information, to handle. Each rule with criteria observable in the text.
3. Build the set of eight fictional messages (the table above is a starting point) and have the agent triage the set before any contact with the real inbox.
4. Compare expected and actual results. Every gap gets corrected in the rules, not in a specific case.
5. Deploy in observation mode: the agent proposes a label, a human validates, for a period you set.
6. Move to semi-automatic: the agent applies labels, a human handles the high-stakes categories (urgent, out of scope requiring a reply).

For the "to handle" category, an agent's safest output remains the prepared draft awaiting validation, an approach detailed in our article on the AI email agent and drafts. The draft keeps the human in the loop without slowing down the triage.

Measuring urgent false negatives

The metric that matters is not the share of messages triaged, it is the number of urgencies wrongly placed in a less critical category. An urgent false negative is a message that met your urgency criteria and which the agent placed in "to handle" or, worse, in "missing information".

Concretely: each week, review the messages labeled tri/urgent (true positives) and look through the other labels for messages that should have been there. The ratio — number of missed urgent messages over the total number of genuinely urgent messages — is your urgent false-negative rate. If your test set and first weeks show, for example, two missed urgencies out of eleven genuinely urgent messages, you have a hypothetical rate of 18%: fix the rules before widening the agent's autonomy.

Complement this with a measure of time saved, otherwise you will not know whether the triage is worth anything. Our guide on email automation and the time actually saved offers a simple before/after comparison method. And if the agent prepares replies, tone consistency remains a human check, as explained in our article on keeping your tone in AI-drafted replies.

An OAuth connection is not proof of real reading

One confusion keeps coming back: "the agent is connected to Gmail, so it reads the inbox." A successful OAuth connection proves the transport works and the provider issued an authorization, nothing more. Transport connection, provider authorization and proof of operation are three different things. Proof of operation is a specific message the agent actually triaged, with the label visible in the interface and a traceable action.

In practice, test with a test message sent to the inbox after connection: if it does not show up triaged, the cause may be the scope — for example one without read access to received emails — or the reading or trigger pipeline. Also check that the agent follows the thread rather than the isolated message, and that the applied labels match the written taxonomy. Our checklist on AI agent permissions helps you separate these levels of control. Finally, keep in mind that restricting the agent's capabilities (for example, drafts without sending) is a matter of your application-level controls, as noted above regarding scopes.

Limits and common mistakes

Three mistakes recur. The first: an eight-category taxonomy "to be precise". It becomes unworkable and the agent will arbitrate at random. Stay at four.

The second: urgency rules based on tone or capital letters. Message 4 in our fictional set shows why: the word URGENT is a declaration, not a criterion. Require a dated deadline or a described impact.

The third: measuring triaged volume instead of missed urgencies. An agent that classifies 98% of messages but misses one customer outage in two costs you more than it earns. Triage quality is judged by its most expensive errors, not by its completion rate.

Finally, revisit the taxonomy when your business changes: a new type of request that consistently lands in "missing information" may signal a form to create, not a triage defect.

Frequently asked questions

Can an agent handle more than four categories?

Yes, but only if each additional category triggers a genuinely different action. Beyond four or five, the boundaries become subjective and two people will classify the same message differently. Prefer sub-labels (for example tri/a-traiter/facturation) over new first-level categories.

How do you define "urgent" without an arbitrary threshold?

You will always have a threshold, but you can make it explicit and adjustable: for example, a dated deadline under 48 hours or an ongoing service outage — these values are hypothetical examples to calibrate to your business. What matters is that the criterion is verifiable in the message text, not inferred from tone.

Are Gmail labels enough to control what the agent does?

No. A label organizes the display and your measurements, but does not limit the agent's capabilities. A scope like gmail.modify can cover sending; if you want an agent that prepares drafts without sending, the restriction must be written into the agent's application logic and verified through tests.

How often should urgent false negatives be reviewed?

Weekly at first, then you can space it out once the rate stabilizes. The review consists of comparing messages labeled urgent with those in other categories that met the urgency criteria. It is a sampled review, not an exhaustive one of the whole inbox.

Should the eight-message set be rerun after every rule change?

Yes, that is precisely its purpose: it is a low-cost regression test. Add, as you go, the real messages that caused problems, keeping the set under about fifteen cases to stay maintainable. If a rule change breaks a case that used to work, you will know within minutes.