An AI automation for Gmail that clears repetitive email before the team has to touch it.
A shared Gmail inbox, several thousand emails a month. Employees answer the same simple questions over and over, resend missing links, confirm deadlines, and forward threads to each other instead of doing the work you pay them for. We built an AI automation: it connects to the Gmail inbox, reads new mail, recognizes intent and urgency, and closes the routine by approved policy. Anything that touches money, a contract, or a complaint, it stops for a human.
For whom
This is for you if a shared inbox eats employee time, and the same simple questions keep blocking people who should be doing higher-value work.
Message → policy → reply
- 01Routine cases finish without another team click
- 02Exceptions stop for human review
- 03The reason stays attached to the thread
- Sector
- Operations / service desk
- Channel
- Shared Gmail inbox
- Volume
- ~3 000 emails / month
- Boundary
- Exceptions and sensitive cases go to a human
- Trace
- Full decision log
Operating loop
The inbox does not decide alone. Every case passes through policy first.
The system reads the thread, classifies intent with a model that has no tools, and checks the answer boundary. Only then does policy route the case to a draft, a send, or a human escalation.
Gmail inbox (~3 000/mo)
Read intent, urgency, and thread context
Routine → approved draft or reply
Exception → human review with reason and context
Decision and reply trace kept for review
System architecture
Inbox, classification, policy, and trace.
The system reads every new thread, classifies it with a model that has no tools, checks the process policy, and only then acts or escalates. Every step is recorded in the log.
- 01
Intake
The Gmail inbox, in a queue that drops nothing.
The system connects to a selected Gmail inbox and works only inside the approved message scope. Every email enters a durable queue with a deduplication key and retries, so no message is skipped or handled twice.
- 02
Classification
The model recognizes intent, but takes no action.
Message content is treated as data, not as a command. The model receives bounded thread context and returns a structured result: intent, confidence, risk signals, and whether the case is routine-answerable. It has no access to any tools, and low confidence or an unusual signal routes the case to a human automatically.
- 03
Policy
Process rules decide what may close without a human.
A routine reply is allowed only where an approved rule, a matched FAQ, and enough context exist. Confidence thresholds, allowed intents, and stop rules are set per process. Anything outside them, such as money, contracts, complaints, and negotiation, stops for review.
- 04
Consent and trace
A validated draft, a decision on one screen, proof in the log.
A routine draft passes deterministic validation before it can be sent. An exception arrives as a decision card in Telegram: the stop reason, the next step, a ready draft, and a thread excerpt, with approval buttons. Every action leaves an auditable trace you can replay: the decision reason, the policy version, the hash of the reply text, and the model and cost of the query.
Why this is automation, not a chatbot or an agent
The system runs every message through a fixed pipeline: it reads context, classifies it with a model that holds no tools, checks policy, prepares a reply, and acts only inside approved boundaries. It is not a chatbot, because it does not wait for a question and closes the case itself. It is not an agent, because the model reaches for no tools and does not pick the action; policy does. The rest waits for a human.
- Policy picks the next step, not the model: draft, send, or escalation
- Combines the inbox, the process policy, and the decision channel in one loop
- Acts only in allowed categories and stops sensitive cases
- Every decision leaves a trace: reason, policy, content hash, and cost
Agent work
The automation runs routine work, but does not improvise on sensitive cases.
Problem
Every day the same simple questions landed in the shared inbox: where's the invoice, is the deadline still on, can you resend the link. The team answered them over and over, instead of doing the work you pay them for, and a large share of that mail should never reach a specialist. The trouble was never the count itself; it was the few genuinely sensitive cases hiding inside the routine, the ones you can't afford to miss.
How it works
The system reads every new email, closes out the routine ones itself, and hands a person only the cases that genuinely need a decision. It works out what each message is about and how urgent it is, and answers the repetitive ones using rules approved up front. Anything that touches money, a contract, or a complaint goes to a human with the reason and the relevant context already pulled out, instead of sitting unread in the queue.
Boundaries and escalation
The automation is not a free-form inbox assistant. It works inside a narrow permission model: routine answers are allowed only when the policy says so, while money, contracts, complaints, negotiation, unusual requests, and low-confidence classifications stop for review. A human sees why the case was stopped instead of reading the thread from zero.
Automation, not autopilot
The system does more than label messages, but it is not an inbox autopilot. The model only classifies the message and reaches for no tools. The next step, whether a draft, a send, or an escalation, is decided by deterministic process policy, not by the model. Routine closes without clicking through every obvious email, and every decision leaves a trace: the reason, the policy version, and the cost of the query.
What broke
Early versions answered short, ambiguous emails too eagerly and confused neighboring intents, for example a simple question versus a request for details. We tightened the confidence thresholds so an unclear case goes to a human rather than getting an automatic reply, added deterministic validation of the draft before any send, and quarantined messages that try to inject instructions before they ever touch the working inbox.
Result
At ~3 000 emails a month the automation closes repetitive cases inside policy, and only a narrow stream reaches the human inbox: money, contracts, complaints, and low-confidence classifications, each with the reason and context already prepared. The team stopped answering the same questions over and over and got back the time you actually pay them for.
Work surfaces
How the system routes mail: a draft, a send, or an escalation.
At ~3 000 emails a month the automation closes repetitive cases inside policy, and only a narrow stream reaches the human inbox: money, contracts, complaints, and low-confidence classifications, each with the reason and context already prepared. The team stopped answering the same questions over and over and got back the time you actually pay them for.
Inbox
The system watches a selected Gmail inbox and works only inside the approved message scope, with no access to the rest of the account.
Policy
A routine reply is allowed only where an approved rule, a matched FAQ, and enough context exist. You set the thresholds and allowed intents for your own process.
Review
A human receives the stop reason, urgency, and extracted context, ready to decide, instead of reading the thread from zero.
Deployment screenshots
Decision view from the running inbox automation.
Screenshots from the running inbox automation, with client data redacted for publication.
Telegram on mobile
The decision fits on one operator screen.
A Telegram frame in a phone mockup, with client data anonymized. The operator approves, edits, or takes over a case without leaving the chat.
01A routine email closed automatically once it matched an approved policy rule.
- Screen 01email-triage
01The queue of cases stopped for review, each with its escalation reason. - Screen 02email-triage
02A reply draft next to the policy and FAQ that allowed it. - Screen 03email-triage
03The decision trace on a message: intent, confidence, next step.
Automation boundary
Boundaries and escalation
The automation is not a free-form inbox assistant. It works inside a narrow permission model: routine answers are allowed only when the policy says so, while money, contracts, complaints, negotiation, unusual requests, and low-confidence classifications stop for review. A human sees why the case was stopped instead of reading the thread from zero.
Early versions answered short, ambiguous emails too eagerly and confused neighboring intents, for example a simple question versus a request for details. We tightened the confidence thresholds so an unclear case goes to a human rather than getting an automatic reply, added deterministic validation of the draft before any send, and quarantined messages that try to inject instructions before they ever touch the working inbox.
Recognize your own process here? Let's see what an agent could take over.
- 30 minutes with the engineer who would build it, not a salesperson.
- A review of the processes that cost you the most time and money.
- A written summary: what to automate, in what order, with cost ranges.
No sales deck and no obligations. If automation doesn't make sense, we'll write that too.