AI Agent for Inbox Triage: Categorize, Draft, Ask First

Email triage is the most obvious job to hand an AI agent and the easiest one to get wrong. Obvious, because triage is repetitive judgment: read a message, decide what kind of message it is, decide whether it needs a reply, and if the reply is routine, write it. Easy to get wrong, because the failure mode is an agent sending email as you, to real people, with words you never saw.

The design that works is simple to state: the agent reads freely, categorizes everything, drafts replies for the routine threads, and never sends anything without you approving the exact message first. Reads flow. Writes wait. This article walks through building exactly that agent, what the instructions look like, how the approval gate works mechanically, what a run report contains, and where the approach genuinely breaks down.

The examples use Skopx, where you build an agent by describing it in chat at Create Agent, but the architecture applies to any platform that separates read permissions from write permissions. If a platform cannot make that separation, it is the wrong platform for this job.

What an inbox triage agent actually does

Strip away the label and a triage agent performs four steps on a schedule or on demand.

Fetch. Pull recent messages from Gmail or Outlook, typically everything that arrived since the last run. This is a read operation. No approval needed, no risk of side effects.

Categorize. Assign each thread to a category you defined: needs your reply, routine and draftable, FYI only, newsletter, cold outreach, spam that slipped the filter. Categorization is pure reasoning over text. The model reads the message and applies your rules.

Draft. For threads in the routine category, write a reply in your voice using the context of the thread. A scheduling confirmation, a "yes, attached" with the right document referenced, a polite decline of a vendor pitch. Drafting is still safe territory: a draft sitting in a report or in your drafts folder sends nothing.

Park for approval. For anything that would actually leave your outbox, the agent stops and asks. In Skopx, a write-shaped action like sending an email parks as a pending approval showing the exact call and arguments, meaning the literal recipient, subject, and body the agent intends to send. You approve that parked call and it executes exactly once, exactly as shown. You reject it and nothing happens. Approvals can also expire, so a stale draft from Tuesday cannot fire on Friday after the thread has moved on.

The critical property is that the dangerous step is structurally separated from the useful steps. Ninety percent of the value of triage is in fetch, categorize, and draft, all of which are read-and-reason operations. The send is a small final step, and it is the only one that needs a human.

Building the agent: instructions that survive real email

In Skopx you describe the agent in chat and the chat assembles it: instructions, trigger, grants, budgets, success criteria. No canvas, no code. If you have not built an agent before, the step-by-step guide to creating an AI agent covers the general flow. Here is what the triage-specific parts look like.

The instructions are plain language, editable, and versioned. A workable first version:

Every weekday at 7:30 UTC, fetch all Gmail messages received since your last run. Categorize each thread as one of: URGENT (customer escalation, anything from the board list, payment failures), REPLY-ROUTINE (scheduling, confirmations, simple questions answered by our docs), REPLY-JUDGMENT (negotiations, sensitive topics, anything legal or HR), FYI (updates I should skim but not answer), NEWSLETTER, COLD-OUTREACH.

For REPLY-ROUTINE threads, draft a reply. Match my tone: short sentences, no exclamation marks, sign off with just my first name. Never commit to dates, prices, or deliverables that are not already stated in the thread.

For URGENT and REPLY-JUDGMENT, do not draft. Flag them at the top of the report with a one-line summary of what the sender wants.

Submit each drafted reply for approval. Never send anything directly. End with a report listing every thread by category.

Notice three deliberate choices. First, the categories are defined by examples, not abstractions. "Anything from the board list" is checkable; "important emails" is not. Second, the drafting rules include hard negatives: never commit to dates or prices not already in the thread. Models follow prohibitions better when they are concrete. Third, the judgment tier exists precisely so the agent has somewhere to put messages it should not touch. An agent with no escape category will force-fit sensitive threads into the draftable pile. There is more on writing instructions that hold up under messy input in the guide to AI agent instructions.

Because instructions are versioned, you can tighten them weekly as you see misclassifications, and roll back if a change makes things worse.

Grants: how the ask-first gate is enforced

Instructions alone are not a safety mechanism. A model can misread its instructions. The enforcement layer in Skopx is grants: per-integration permissions with tiers.

For a triage agent, the sensible grant configuration on the Gmail toolkit is:

The "asks first every time" tier on send is the load-bearing setting. It does not depend on the model remembering to be careful. The platform intercepts the call itself. Even if the instructions were garbled or the model hallucinated an urgent reason to reply immediately, the send parks and waits. Skopx also offers a drafts-only mode, which is a good starting posture: the agent can create drafts in Gmail but the send action is not available to it at all, and you send from your own client after review.

Under approval_required, reads still flow without approval. This matters for cost and speed: a triage run touches dozens of messages, and gating every read would make the agent useless. The gate sits exactly where the risk sits. The broader pattern of humans approving specific parked actions, rather than vaguely "supervising" an agent, is covered in AI agents with human approval.

Memory: why the second run is better than the first

A triage agent that starts from zero every morning would re-fetch and re-categorize threads it already handled. Skopx agents have memory that persists between runs: cursors and baselines the agent maintains itself.

For triage, the memory typically holds the timestamp of the last processed message, so run two starts where run one ended. It can also hold observed norms: which senders you consistently reclassified, which drafted replies you rejected and why, what your actual response to a recurring vendor was. Second runs produce delta reports, only what changed since last time, and are typically cheaper because the agent is not re-reading history.

This is also how the agent improves without you editing instructions. If you reject three drafted replies to the same sender, that fact can live in memory, and the agent stops drafting for that sender and moves them to the judgment tier. The mechanics of what persists and what does not are covered in AI agent memory explained.

The morning run, concretely

Here is a hypothetical but representative run, framed as an example rather than a customer story.

The agent triggers at 7:30 UTC on its schedule. The step timeline, which you can inspect step by step with humanized labels and expandable raw results, shows: fetched 34 messages since the 6:12 PM cursor from yesterday. Categorized: 2 urgent, 6 reply-routine, 4 reply-judgment, 9 FYI, 8 newsletters, 5 cold outreach. Drafted 6 replies. Submitted 6 sends for approval. Wrote report. Total: 41 steps, a few minutes of wall-clock time, token count displayed on the run.

You open Skopx with coffee. The report is a markdown document rendered like any other doc. At the top: the two urgent threads, each with a one-line summary. "Acme's invoice bounced twice, their AP contact is asking for updated bank details." You handle those yourself, first, because that is the whole point of triage: the agent surfaced them instead of letting them sit at position 19 in an unsorted inbox.

Then the pending approvals. Six parked sends, each showing the exact recipient, subject, and full body. You approve four as-is. One you reject because the tone is slightly off for that particular client; you reply manually. One you reject because the agent misread the thread, the question was already answered. Rejecting executes nothing. Total time: maybe six minutes, versus the forty an unsorted inbox would have taken.

Every run appends to an immutable history, so a month later you can audit exactly what was fetched, drafted, approved, and rejected on any given day. What a good report contains, and how to make agents write better ones, is the subject of AI agent reports.

Triage agent vs. filters vs. workflow automation

Inbox triage predates AI agents. It is worth being honest about when the older tools are enough.

Filters are unbeatable for the deterministic slice: newsletters to a label, a specific sender to a folder. Keep them. The agent earns its place on the part filters cannot do: understanding that "quick question about the March invoice" is actually an escalation because the previous two emails in the thread went unanswered, or drafting a reply that references the correct attachment. If your triage needs are fully deterministic, an agent is overkill, and the comparison in AI agent vs. workflow automation can help you decide which side of the line your inbox falls on.

Budgets and guardrails: containing the blast radius

An email agent touches your most sensitive integration, so it should run inside hard limits. Skopx agents carry budgets: tokens per run, tokens per day, a max step count, and a minute cap. A triage agent that normally finishes in 40 steps and hits its 80-step ceiling is telling you something is wrong, maybe a mail loop, maybe a malformed thread it keeps re-reading. Three budget failures auto-pause the agent, which converts a runaway into a notification instead of a bill.

Beyond budgets, the practical guardrails for this specific use case:

• Start in drafts-only mode. Run for a week where the agent can only create Gmail drafts. Review them in your own drafts folder. Promote to ask-first sending only after the drafts consistently pass.
• Never grant automatic send. For an inbox agent, "agent decides when to ask" on send is not appropriate. Every send should ask, every time. The cost of approval is seconds; the cost of one wrong email to a customer is not.
• Scope the categories tightly. Legal, HR, anything involving money terms goes to the judgment tier, never the draft tier.
• Use the kill switch. Pausing an agent in Skopx kills queued runs. If a run looks wrong mid-flight, you can stop it there and then; parked approvals from a stopped run still execute nothing unless you approve them.

Success criteria round this out: you tell the agent what a good run looks like, for instance "every fetched thread appears in exactly one category, no drafted reply commits to new dates or amounts," and the run report evaluates against those criteria, so a run can flag itself as unsatisfactory instead of you discovering it later.

Where this approach breaks down

Candor section. An AI email triage agent is not a full replacement for reading your email, and some inboxes are bad fits.

High-stakes, low-volume inboxes gain little. If you get fifteen emails a day and half are sensitive negotiations, the agent will correctly route most of them to the judgment tier and you will have paid for a fancy sorting of a pile you would have read anyway. Triage pays off on volume with a large routine fraction.

Tone is learnable but not perfect. Expect to reject drafts in the early weeks. The agent will be slightly too formal with an old colleague or slightly too casual with a new client. The rejection loop plus memory narrows this, but a draft is a starting point, not a guarantee.

Categorization has an error rate. A model reading "just following up on our conversation" from a stranger will occasionally rank it above where it belongs, or misread genuine urgency as routine. The mitigation is structural: errors in categorization cost you a mislabeled email in a report, not a wrong action, because the send gate is downstream of everything.

Approval fatigue is real. If you find yourself approving twenty sends a day without reading them, the gate has stopped being a gate. Better to narrow the draftable category so approvals stay few enough that you actually read each one.

Email content is untrusted input. Messages can contain text that tries to steer any model reading them. The layered defense is the same one described throughout: the agent's write actions are gated regardless of what any email says, and budgets cap how far a run can wander. This is a good reason to keep grants minimal rather than giving a triage agent every toolkit you have connected.

Setting it up in Skopx

The short version of the setup path, end to end:

1. Open Create Agent and describe the agent in chat: the categories, the drafting rules, the schedule. The chat assembles instructions, trigger, grants, and budgets; the workspace shows this agent in a rail beside any others you run.
2. Connect Gmail or Outlook from the nearly 1,000 available integrations. Set the send action to ask-first, or start in drafts-only mode.
3. Pick a model. Skopx lets you choose per agent among Claude, GPT, Gemini, Kimi and others, bring your own key with zero markup, or use the $16/seat Team plan with included tokens. Triage is mostly reading and classifying, so you do not need the heaviest model; see multi-model AI agents for how to think about the choice.
4. Set budgets and success criteria, then run it manually once against your real inbox before enabling the schedule.
5. Review the first report and the parked approvals, edit the instructions where the categories missed, and let the schedule take over.

The full agent surface, including how triage sits alongside other agents you might run, is at skopx.com/agents, and pricing details are at skopx.com/pricing.

FAQ

Can the agent send emails without me?

Not if you configure it correctly, and in Skopx the recommended configuration makes it structurally impossible. With the send action set to "asks first every time," every outbound email parks as a pending approval showing the exact recipient, subject, and body. Approving executes that parked call once; rejecting executes nothing. In drafts-only mode the agent cannot send at all, it can only place drafts in your folder. The gate is enforced by the platform at the point of the call, not by the model's good behavior.

How is this different from Gmail's built-in smart features?

Gmail's categories and smart replies are generic: they apply the same model of "promotions" and "social" to everyone and offer three-word replies. A triage agent runs your rules: your definition of urgent, your senders who always get flagged, your tone in drafts, your prohibition on committing to dates. It also produces an auditable run report and an append-only history, which built-in features do not. The tradeoff is that you have to write and tune those rules.

What does a triage run cost?

It depends on inbox volume, model choice, and how much thread history each categorization needs, so there is no honest flat number. Structurally, costs are contained three ways: token budgets per run and per day cap the ceiling, memory cursors mean each run reads only new mail rather than re-reading the inbox, and you can pick a lighter model since triage is classification-heavy rather than generation-heavy. On Skopx you either bring your own API key with zero markup or use the Team plan's included tokens at $16/seat.

What happens if the agent miscategorizes an important email?

The email appears in the wrong section of the run report, and that is the extent of the damage, because categorization has no side effects. Nothing is deleted, nothing is sent, run history is append-only so you can see exactly what the agent saw and decided. The fix is usually an instructions edit: add the sender or the pattern to the urgent definition. Instructions are versioned, so tightening them is low-risk, and persistent memory lets repeated corrections stick between runs.

Should the triage agent also handle calendar scheduling and CRM updates?

Start with no. A triage agent with only Gmail grants has a small blast radius and is easy to audit. Once it is reliable, you can either widen its grants or, usually better, run a separate scheduling or CRM agent beside it in the workspace rail, each with its own narrow grants, budgets, and history. The tradeoffs between one broad agent and several narrow ones are covered in one agent vs. many.