Support email triage with AI drafts

Support replies carry commitments: refunds, timelines, account changes. A model can misread intent or confidently state a policy that does not exist, and once an email is sent you cannot take it back. Saving a draft in the original thread keeps the speed benefit, because the agent edits instead of writing from scratch, while a person stays accountable for what the customer reads. It also gives us a clean quality signal: how much agents change each draft tells us whether prompts or help articles need work. Once we have evidence that a narrow category, say order-status questions, is reliably correct, we could consider auto-send for that category alone, but drafts are the right default.

A Gmail Trigger polls the support inbox and emits one item per new message with message ID, thread ID, sender, subject and body. A Code node cleans the body and checks the message ID against a Postgres triage log to skip anything already handled. A Text Classifier, using a chat model reached through Vercel AI Gateway, assigns an intent and a separate urgency flag. A Switch node routes on both and can send one item to several outputs. Urgent items page the on-call Slack channel with a link to the thread. Answerable items go to an AI Agent that retrieves help articles and writes a grounded reply. A Gmail node saves it as a draft in the original thread, labels it and logs the result. Retries and an error workflow cover failures.

The Gmail Trigger polls, and polling systems can surface the same message more than once. Executions can also be retried after a partial failure. Without a guard, one email could get two drafts or two Slack pages. The Code node takes the Gmail message ID, which is stable and unique per message, and looks it up in the Postgres triage log. If a row exists with a finished status, the item is dropped. If not, the workflow continues and later writes the category, model and draft status against that ID. The message ID is a better key than subject or sender because many customers send similar subjects and one sender sends many emails.

The main defence is that the model has no power to act. The classifier only outputs a label. The AI Agent's only tool is retrieval from the help-article vector store. It cannot send email, change accounts or issue refunds. Its output becomes a Gmail draft that a person reads before anything goes out. I would also put the email body in a clearly delimited user section and tell the model to treat it as data, not instructions. The worst realistic outcome is a bad draft or a wrong label, and a human catches both. I would log suspicious phrases so the team can spot attack patterns.

The agent is grounded. It must retrieve help articles from the vector store, and its system prompt tells it to answer only from that content. When the retrieved articles do not cover the question, it says the ticket will be escalated instead of guessing. I would keep the temperature low and ask it to reference the article it used, so the reviewer can check quickly. I would never let it state refund amounts, timelines or legal positions unless an article says so. The draft-only design is the final safety net. Edits that reviewers make show where grounding is weak, and those cases feed back into the articles and the prompt.

First, I classify urgency separately from intent and bias the descriptions towards recall, accepting some false alarms. Second, the Switch node sends urgent items to every matching output, so they are paged and drafted. Third, anything the classifier cannot place goes to a fallback output that a human checks, rather than being silently archived. Fourth, failures are covered: retry-on-fail on the gateway, Gmail and Slack nodes, and an error workflow that alerts Slack and leaves the email unlabelled so it stays visible in the inbox. Finally, I track re-labels by agents in Postgres to measure urgent recall over time and tune the category descriptions.

The gateway is OpenAI-compatible, so in n8n I use the OpenAI-style chat model sub-node with base URL https://ai-gateway.vercel.sh/v1 and a single AI Gateway API key. That one credential reaches several providers, so I can use a cheaper model for classification and a stronger one for drafting, and swap either by changing the model name, for example anthropic/claude-sonnet-4.5 or openai/gpt-5. Fallbacks help when one provider is degraded, which matters for an inbox that never stops, and spend tracking shows the cost per workflow. It also means no provider keys sit in n8n, which reduces credential sprawl.

No node in the workflow performs a send. The Gmail node uses the create-draft operation, and the AI Agent has no Gmail or email tool attached, only vector store retrieval. In review, I would check that no Gmail node uses a send or reply operation and add that check to change management, so any new send node needs explicit approval. Where the provider allows it, I would use a credential whose permissions are limited to reading, labelling and drafting. A test asserts that the Sent folder stays unchanged after a run on a test inbox. That layered approach removes the capability rather than trusting a prompt.

Intent and urgency are independent. A billing email can be routine or urgent, and so can a bug report. If 'urgent' were one more category, the classifier would have to choose between 'billing' and 'urgent'. An urgent billing email would then lose either its draft or its page. With a separate flag, every item carries both values. The Switch node can send it to the drafting path for its intent and to the Slack path for urgency at the same time. It also lets you tune urgency on its own, for example biasing it toward flagging, without disturbing intent accuracy.

One row per Gmail message, keyed by message ID with a unique constraint. I would store the thread ID, a received timestamp, the n8n execution ID, intent category, urgency flag, the model name used, the draft status, the Gmail draft ID, whether a Slack page was sent, and error details if any. This supports deduplication, audits and debugging. Logging the model name lets you compare quality when you change models behind the gateway. To limit exposure, I would avoid storing full email bodies; the message ID is enough to find the email in Gmail. A retention policy should clear old rows.

A read-then-write check has a race. Both workers can see 'no row' and both continue. The fix is an atomic claim: insert a row for the message ID with status 'processing', using a unique constraint and insert-on-conflict-do-nothing, and continue only if the insert actually created the row. The second worker's insert affects nothing, so it stops. On success, the row is updated to 'drafted' or 'paged'. On failure, the error path marks it 'failed', so a reprocess job or a person can pick it up. A stale-claim rule, such as treating old 'processing' rows as failed, stops a crashed worker from blocking an email forever.

The triage label is the visible signal that automation handled the email. If a failed email got the same label, a person scanning the inbox would assume it had been triaged and drafted, and it could sit unanswered. Leaving it unlabelled keeps it in the obvious 'needs a human' state. Meanwhile the Error Trigger workflow posts the execution details to Slack, so someone knows to look. This follows the rule of failing visibly rather than silently. It matters most for urgent emails, because a failure must never look like success. Some teams add a distinct 'triage-failed' label, but it must never match the success label.

Start from daily email volume and the peak hour, because support mail is bursty. Each email costs one or two classifier calls, plus an agent run with retrieval for answerable ones. Model latency dominates execution time, so concurrency matters more than CPU. On a single n8n instance, a burst can queue up behind slow model calls. Queue mode with Redis and several workers lets executions run in parallel. Gmail and Slack API rate limits then become the ceiling, so retries need waits between attempts. I would load-test with a replayed backlog and watch queue depth and the time from receipt to draft or page.

Build a labelled evaluation set from real past emails, with personal data removed, covering every category and plenty of urgent cases. Run it whenever you change the model, category descriptions or cleaning rules, and compare results. Track per-category precision and recall, and pay most attention to recall on urgent, since a missed urgent email is the costly error. In production, record when agents relabel emails or reroute tickets, and treat that as ground truth. Most fixes come from sharpening the written category descriptions and adding edge cases. Logging the model name per row lets you compare models behind the gateway.

Support emails carry names, contact details, account and payment information. Sending them through Vercel AI Gateway to a model provider creates a processing chain that must be covered by contracts and your privacy notice, and in India it falls under the Digital Personal Data Protection Act. To reduce exposure, send only the cleaned, truncated body, not full threads or attachments. Consider masking obvious identifiers such as card or phone numbers in the Code node. Check the data retention and training terms for the gateway and the providers you route to. Avoid storing bodies in the triage log, and keep n8n execution data retention short.

Usually not. Classification is a short, constrained task, so a smaller, faster and cheaper model often does well. You can confirm that with the evaluation set. Drafting needs better reasoning and writing, and it uses retrieved context, so a stronger model is worth the cost there. Because both go through Vercel AI Gateway with one credential, switching models is a change to the model name in each chat model sub-node. The gateway's fallbacks help availability. Record which model produced each result in the triage log, so you can compare quality and cost when you change them.

Measure time from email receipt to Slack page for urgent items, and from receipt to draft for the rest. Track execution failure rate, retry counts, and the number of unlabelled emails older than a threshold. That last one directly catches silent misses. Also track category distribution, the urgent rate, the share of drafts that say they will escalate, and how many drafts are sent, edited heavily or discarded. Alerts should fire when errors spike, when no executions run during working hours, which suggests a broken trigger or an expired credential, and when a sudden category shift suggests classifier drift.

Mostly yes. For urgent paging, a duplicate is far cheaper than a miss, so I would accept occasional duplicates rather than weaken retries. To limit them, record the paged status in the triage log right after a successful post, and skip the Slack node on reprocessing when that flag is already set. A timeout after Slack actually received the message can still cause a duplicate, and that is fine. Retries should wait between attempts so a brief Slack outage does not burn all the tries. If every retry fails, the error workflow alerts through another path, so the page is not lost.

It must not be dropped. The Text Classifier can be set to send unclear items to an extra 'other' output instead of discarding them, and that is the setting I would use. Those items should go to human triage. Apply a 'needs-triage' label, skip the AI draft, and log the case. If the urgency judgement is uncertain, treat the email as urgent and page, since a false page costs less than a miss. Reviewing the 'other' bucket regularly shows which new categories or clearer descriptions are needed.

A shorter interval means urgent emails reach Slack sooner. The cost is more Gmail API calls and more executions that find nothing. A longer interval saves calls but adds delay for urgent tickets, and that delay counts against your response target. Since urgent paging is a hard requirement, I would pick the shortest interval the API quota comfortably supports and measure end-to-end latency. Push-based options, such as Gmail notifications through a webhook, cut latency but add setup and their own failure modes. I would keep polling as a backstop even then, because deduplication makes overlap harmless.

Raw support emails contain quoted earlier messages, signatures, disclaimers and HTML markup. Quoted history can mislead the classifier, because an old billing thread quoted under a new bug report may pull the label toward billing. Signatures and legal footers add tokens and noise. HTML wastes tokens and can hide text. Stripping these gives the model the customer's actual new message, which improves accuracy and lowers cost per call. It also cuts how much personal data, such as phone numbers in signatures, goes to the model. The cleaning rules need tests, because aggressive stripping can remove real content.

The risk is cutting off the important part. A customer may explain background first and say 'my account is locked and payroll runs today' at the end. To reduce this, truncate after cleaning, so quoted history and signatures are already gone. Keep the subject line, which often carries intent. If the body is cut, consider keeping both the start and the end. Log a 'truncated' flag in the triage log. For urgency, I would also run cheap keyword checks on the full text before truncation and treat a match as urgent. The human reviewer always has the full email in Gmail.

n8n stores credentials encrypted and nodes reference them by name, so secrets never appear in node parameters or exported workflow JSON. This workflow needs Gmail, Slack, Postgres and the AI Gateway key. Because of the gateway, there are no individual provider keys. In review, I would check that each credential has least privilege. The Slack bot should post only to the needed channels, and the Postgres user should touch only the triage tables. I would also confirm the n8n encryption key is backed up and protected, sharing of credentials is limited to the right users, and keys are rotated when people leave.

A reply needs to stay in the customer's conversation. Using the thread ID means the draft sits under the original message in Gmail, the reviewer sees full context in one place, and the sent reply threads correctly in the customer's mail client. A draft created without the thread would start a new conversation. The customer would see a disconnected email, and agents could reply twice because they would not notice the existing draft. The thread ID is also stored in the triage log, so the Slack page and any audit can link straight to the conversation.

They should get no draft and no Slack page, but they must not disappear silently. I would apply a spam-triage label, log the classification, and leave the message in place for a periodic human glance rather than deleting it. Classifiers produce false positives, and a real customer, perhaps an angry one with odd formatting, could be misfiled. Never auto-delete. If the urgency flag is set on something classified as spam, I would still page, because the urgency rule takes priority over the category. Tracking spam volume over time also shows whether upstream filtering needs work.

Modern chat models generally handle Hindi and Hinglish, but I would verify that with an evaluation set of real multilingual emails rather than assume it. Category descriptions can stay in English, but the prompt should say that emails may arrive in other languages. Drafts should reply in the customer's language, which means retrieval must work across languages. Either the help articles exist in those languages, or the embeddings model handles cross-lingual search. Reviewers must be able to read the draft. I would log the detected language to find gaps, such as a category whose accuracy drops for Hindi emails.

Run a separate ingestion workflow, triggered on a schedule or by a webhook when articles are published or edited. It fetches changed articles, splits them into chunks, embeds them and upserts them keyed by article ID. Deleted or retired articles must also be removed, otherwise the agent may cite outdated policy. Store the article URL and last-updated date as metadata, so drafts can link to the source and reviewers can spot stale content. Use the same embeddings model for ingestion and query. Changing the embeddings model means re-embedding everything.

Vercel AI Gateway provides spend tracking in one place across providers, which is the first view I would use. To reduce spend, clean and truncate inputs, use a cheaper model for classification, and skip the agent for spam and for categories that only need a page. Deduplication also prevents paying twice for the same email. I would watch cost per email and total daily spend, and alert on sudden jumps. A jump can mean a mail loop, a spam flood or a retry storm. Combining spend with volume from the triage log shows whether a jump comes from more email or more cost per email.

Compare what was sent with what was drafted. A scheduled workflow can look up sent messages in threads with a logged draft ID and record whether the draft was sent unchanged, edited or discarded, along with a rough edit size. Agents could also add a label such as 'bad-draft' or 'wrong-category' to give explicit signals. These results go into the triage log. Grouping them by category shows where help articles are missing or the prompt is weak. Reviewed examples can join the evaluation set. This feedback loop is how drafts get better without removing the human check.

The new message has its own message ID, so deduplication correctly lets it through. The question is the stale draft. The new reply might change the question or add urgency. I would classify the new message on its own, including urgency, so a frustrated follow-up can still trigger a page. For drafting, the agent should see a short context of the thread and produce a new draft. The workflow should then replace or flag the older unsent draft for that thread, which is possible because the triage log records the draft ID. Otherwise the reviewer could send an outdated answer.

Point it at a test Gmail inbox with a separate credential and a test Slack channel. Seed the inbox with realistic emails, personal data removed, covering every category, urgent cases, spam, long threads, HTML-heavy emails and injection attempts. Check the classifications, routing, draft content, labels and log rows. Then force failures, such as a bad gateway key or a blocked Slack call, to confirm retries, the error workflow and the unlabelled state. Re-run the same emails to prove deduplication. Finally, run in shadow mode on real mail with drafts and pages going to the team for review before relying on it.

By default, I would not send attachments to the model. They may contain sensitive documents and add cost, and most triage decisions come from the text. The Code node can note that attachments exist, and that fact can go into the classifier input, for example 'customer attached a screenshot'. The draft prompt should not claim to have read them. If screenshots prove important for bug triage, a later version could pass images to a vision-capable model through the gateway. That needs a privacy review first. The human reviewer can always open attachments in Gmail.

When parts become reusable or complex enough to test on their own. The drafting path, with retrieval, the agent and draft creation, is a good candidate. So is the paging path, which other workflows might reuse for different alert sources. Sub-workflows give clearer execution logs, smaller units to change and test, and easier ownership by different people. The cost is more moving parts, plus data passed between workflows that must keep a stable shape. Each sub-workflow also needs error handling that reaches the error workflow. For a small first version, one workflow is fine.

1. AGmail message IDCorrect answer
2. BThread ID
3. CSubject line
4. DSender address

Why: The message ID is unique per message. Subjects and senders repeat, and one thread holds many messages.

1. ASend a new message
2. BCreate a draft in the original threadCorrect answer
3. CSend a reply
4. DForward to the support lead

Why: Replies are saved as drafts so that a person must approve and send them; nothing is sent automatically.

1. AAtomically claim the message ID with a unique constraint and insert-on-conflict before processingCorrect answer
2. BRead the log, then write after the draft is created
3. CLengthen the polling interval
4. DRun only one Switch output at a time

Why: An atomic insert under a unique constraint lets only one worker win. Read-then-write leaves a race window.

1. AAsking the model politely to ignore instructions
2. BUsing a larger model
3. CGiving the agent no action tools beyond retrieval and keeping human approval of draftsCorrect answer
4. DRemoving all punctuation from emails

Why: If the model cannot act and every output is reviewed, injected instructions cannot cause sends or account changes.

1. AMerge node
2. BLoop Over Items node
3. CWait node
4. DText Classifier nodeCorrect answer

Why: The Text Classifier node uses a chat model to assign items to categories you define and gives each category its own output, which suits intent routing.

1. AUse an OpenAI-compatible chat model with base URL https://ai-gateway.vercel.sh/v1 and an AI Gateway API keyCorrect answer
2. BStore each provider's API key in a Code node
3. CCall the gateway only from a Webhook trigger
4. DInstall a separate n8n instance per model provider

Why: The gateway exposes an OpenAI-compatible API, so one credential with that base URL reaches many providers by model name.

1. AChat Trigger
2. BWebhook node receiving Slack events
3. CGmail Trigger polling the support inboxCorrect answer
4. DSchedule Trigger running a Postgres query

Why: The workflow begins with a Gmail Trigger that polls the inbox and emits one item per new message.

1. AIn a Postgres triage logCorrect answer
2. BIn n8n's static workflow memory only
3. CIn a Google Sheet
4. DIn the Slack channel history

Why: The Code node checks the message ID against the Postgres triage log, which also stores category, model and draft status.

1. AThe Postgres row ID
2. BThe sender address
3. CThe thread IDCorrect answer
4. DThe subject prefixed with Re:

Why: The thread ID attaches the draft to the original thread, so it threads correctly for the reviewer and the customer.

1. ArefundCorrect answer
2. Bspam
3. Cbilling
4. Dhow-to

Why: The categories are billing, bug, how-to, account and spam. Refund questions fall under billing.

1. AWrite a draft saying the issue will be escalatedCorrect answer
2. BAnswer from general model knowledge
3. CSend the customer a link to the help centre home page
4. DSkip creating a draft and delete the email

Why: The agent cites only retrieved content and says it will escalate when the articles do not cover the question, which avoids invented answers.

1. AWebhook
2. BWait
3. CExecute Workflow Trigger on a schedule
4. DError TriggerCorrect answer

Why: An error workflow begins with an Error Trigger, which receives details of the failed execution.

1. AUnlabelled, for manual triageCorrect answer
2. BMoved to spam
3. CLabelled as triaged
4. DDeleted from the inbox

Why: Leaving it unlabelled keeps it visibly unhandled, while the error workflow posts details to Slack.

1. AMerge node
2. BRetry on fail in the node settingsCorrect answer
3. CLoop Over Items
4. DSet node defaults

Why: Per-node retry-on-fail re-attempts transient failures before the error workflow takes over.

1. AThe Switch node cannot read HTML
2. BIt is required for the thread ID to work
3. CGmail rejects long bodies
4. DOlder quoted messages can mislead the classifier and waste tokensCorrect answer

Why: Quoted earlier messages add noise and tokens, so the label might reflect old content instead of the new message.

1. AA false negative, to avoid noise
2. BDropping the email
3. CA false positive, paging when unsureCorrect answer
4. DWaiting for the next poll

Why: A missed urgent email is the costly failure, so extra pages are the cheaper error.

1. AThe whole mailbox for context
2. BThe full thread with all attachments
3. CThe cleaned, truncated new messageCorrect answer
4. DThe customer's account record from the CRM

Why: Sending only the cleaned, truncated message limits personal data exposure and cost while keeping what triage needs.

1. ARoute it to an 'other' output for human triageCorrect answer
2. BDiscard it silently
3. CSend an automatic reply asking for details
4. DDraft a generic answer

Why: Unclear items must not be lost, so they go to an extra output and a person decides.

1. AGmail allows only one label per thread
2. BSo unlabelled emails clearly mark those that still need a humanCorrect answer
3. CLabels trigger automatic sending
4. DLabels cost API quota

Why: The label signals that automation handled the email, so failures stay visibly unlabelled and are not mistaken for success.

1. AUse a Merge node before the trigger
2. BEnable sending data to all matching outputsCorrect answer
3. CSet the Switch to stop after the first rule only
4. DReplace the Switch with a Wait node

Why: With all matching outputs enabled, an item that satisfies several rules goes down each matching branch instead of only the first one.

1. AA regular expression per category
2. BA trained model uploaded to n8n
3. CThe Gmail label already on the email
4. DWritten category descriptionsCorrect answer

Why: The classifier assigns categories based on the written descriptions supplied for each one.

1. ABy running Code nodes in Python
2. BBy raising the Gmail polling interval
3. CQueue mode with Redis and worker processesCorrect answer
4. DBy adding more trigger nodes

Why: Queue mode uses Redis to hand executions out to multiple workers.

1. AMerge
2. BCodeCorrect answer
3. CSet/Edit Fields
4. DIF

Why: The Code node supports JavaScript or Python for custom transformations such as stripping HTML and signatures.

1. ASender, subject, category and a link to the Gmail threadCorrect answer
2. BOnly the email body
3. CThe AI draft text only
4. DThe customer's full account history

Why: Those fields give enough context to prioritise, and the link goes straight to the conversation.

1. AIn the Switch node's rules
2. BAs plain text in node parameters
3. CEncrypted in n8n credentials and referenced by nodesCorrect answer
4. DIn the email body of a config message

Why: n8n stores credentials encrypted, and nodes reference them, so secrets stay out of workflow definitions.

1. Aanthropic/claude-sonnet-4.5Correct answer
2. Bclaude-sonnet-4.5@anthropic
3. Cprovider:model:version
4. DA numeric model ID

Why: Gateway models are named provider/model, such as anthropic/claude-sonnet-4.5 or openai/gpt-5.

1. ALoop Over Items
2. BText Classifier
3. CWait node waiting for a form or webhook approvalCorrect answer
4. DMerge node

Why: The Wait node can pause an execution until a form submission or webhook call resumes it.

1. AFaster urgent paging but more API calls and empty executionsCorrect answer
2. BLower accuracy for the classifier
3. CDrafts are created outside the thread
4. DDeduplication stops working

Why: Polling more often cuts latency but uses more quota and runs more executions that find no mail.

1. AAbout 24
2. BAbout 60
3. CAbout 1Correct answer
4. DAbout 10

Why: A day has 1,440 minutes, so the average is about one per poll. Real traffic is bursty, so peaks will be higher.

1. ATo compare quality and cost when models change behind the gatewayCorrect answer
2. BGmail requires it on drafts
3. CSlack needs it to post
4. DIt replaces the message ID as a key

Why: Model identity per result supports evaluation, debugging and cost comparison across model changes.

1. AMemory sub-node
2. BA vector store tool with embeddingsCorrect answer
3. CThe Switch node
4. DThe Gmail Trigger

Why: The agent searches an embedded help-article vector store and grounds its reply in the results.

1. AIF
2. BLoop Over ItemsCorrect answer
3. CInformation Extractor
4. DChat Trigger

Why: Loop Over Items splits items into batches, which helps respect API rate limits during backfills.

1. AInformation ExtractorCorrect answer
2. BEmbeddings node
3. CSummarisation node
4. DText Classifier

Why: The Information Extractor returns structured fields from text, while the Text Classifier only assigns categories.