AI Email Response System: Human-in-the-Loop Draft Automation
Built Dec 2025
Most "AI email" builds end with the same trick: a bot reads a message and fires back a reply on its own. This one does the opposite. It does the tedious part, the reading, the sorting, and the first draft, then stops and lets a person decide what actually goes out. It was built for Sushi One's inbox, where the sender on the other end is a customer relationship, not a support ticket.
The design reasoning behind this build is written up here: The inbox that answers itself, almost.
Challenge
Sushi One's inbox mixes reservations, catering leads, general questions, and the occasional complaint, all landing in the same place and all waiting on a human to read, sort, and reply. The goal was to remove the tedious part of that work, the reading and the blank-page first draft, without handing a customer relationship to a bot that might confidently answer the wrong question in the restaurant's name.
Method
The workflow runs in four stages, and each stage exists to solve a specific failure mode of naive email automation.
Stage one, a relevance gate. Every message that clears the Gmail trigger hits a Gemini step that answers one question: does this actually need a human response? Marketing, newsletters, receipts, and automated confirmations are marked and left alone. Filtering first is what keeps the system from generating review work for mail that never needed a reply.
Stage two, intent classification. Anything that clears the gate goes to a second Gemini step that reads for intent and drops the message into one bucket: reservation, catering, general, or complaint. Categorizing before writing is deliberate. A single generic "reply to this email" prompt produces generic, hedging drafts. Knowing the category up front lets the next step use a prompt written for that exact situation.
Stage three, a writer per lane. Route by Category sends each message to its own Gemini writer: reservation, catering, general, or complaint. Each writer has its own instructions. The reservation writer confirms details and offers next steps. The catering writer asks the questions a catering lead actually needs answered. The general writer stays short and helpful. The complaint writer prepares language for the ownership team, not for an auto-send to the customer. Brand voice stays consistent: family-owned, quality-first, made from scratch.
Stage four, two exits. Reservation, catering, and general land in Gmail Create Draft inside the original thread, addressed to the original sender, ready for a person to read, adjust, and send. Nothing on those lanes auto-sends to the customer. The complaint lane skips Create Draft. After Generate Complaint Reply, the workflow sends an internal Gmail notice to the GM with the original message and suggested language so a person handles the customer from the first word.
Results
This is a design and build engagement, not a performance-metrics one. The workflow runs on a human gate, so there is no auto-send volume to report, and no accuracy or time-saved figures are claimed here. What the build delivers is structural, and every row below maps to a node in the workflow itself.
| By design | What it guarantees |
|---|---|
| Relevance gate before any generation | Newsletters, receipts, and no-reply noise never become review work |
| Intent classification before drafting | Each message routes to a writer built for that exact situation, not one generic prompt |
| Draft lanes with zero customer auto-send | Reservation, catering, and general replies land as Gmail drafts in the original thread for a person to edit and send |
| Complaint: generate, then notify GM | Generate Complaint Reply feeds an internal Gmail notice to the GM; no Create Draft to the customer |
| Thread-aware, sender-aware drafts | Customer-facing drafts attach to the correct conversation and recipient, so review is one click from send |
The complaint path is the important break in the pattern. The canvas still runs a Gemini complaint writer, then routes to Notice Complain Message to GM instead of Create Draft. Suggested language supports the owner; it never becomes a customer-facing draft waiting to be rubber-stamped. Unhappy customers get a person from the first word.
Tools Used
n8n (workflow orchestration), Google Gemini (relevance, classification, and drafting), Gmail API (trigger, draft creation, and escalation alerts).
How I'd Extend This
The honest next step is measurement. The system is built and wired but runs on a human gate, so the useful metric is not volume, it is draft quality: how often a reviewer sends a draft with light edits versus rewriting it. Activating the workflow against a live inbox and logging edit distance between the drafted reply and the sent reply would turn this from a design build into a measurable one, and would tell the classifier which lanes need better prompts.
Bottom Line
The whole system is built around one line you can draw through it: the AI drafts, a person sends. Full auto-send saves a few seconds per email and risks the restaurant's reputation on every one of them. Draft-and-review saves the real cost, the reading, sorting, and staring at a blank reply box, while keeping a human accountable for anything that leaves the building. For an inbox that is a customer relationship and not a ticket queue, that trade is not close.