Building an AI agent that triages 200 emails a day

One of the most common requests is some version of "drowning in email." A support inbox, a sales inbox, or a shared operations address taking 100 to 300 messages a day, with someone reading every single one to decide what to do with it.

An agent built for exactly this reads incoming email, classifies it by topic and urgency, routes it to the right person or queue, and drafts responses for the straightforward ones. Below: how it works, what tends to go wrong, and what the team's day looks like afterward.

A walkthrough of a typical email triage build. The volumes below are representative of this kind of project rather than a single named account.

What the workflow looked like before

A shared support inbox like this receives around 200 emails per day. These range from password reset requests to urgent billing disputes to partnership inquiries to spam. Typically one person spends roughly three hours every morning reading, tagging, and forwarding each email to the right team member.

Three hours of human time, every single day, just to sort mail. That's 15 hours a week of pure triage, not even counting the time spent actually responding.

How the AI agent works

The system has four stages, running as a Rails background job that processes new emails every two minutes:

Stage 1: Intake. New emails are pulled via IMAP (or a webhook from the email provider). Each email is stored with its sender, subject, body text, and any attachments. HTML, signatures and quoted replies are stripped to get at the actual message content.

Stage 2: Classification. The cleaned email text is sent to a current GPT model with a carefully written system prompt. The model classifies each email across two dimensions: topic (billing, technical support, partnership, general inquiry, spam) and urgency (high, medium, low). The prompt includes examples of each category drawn from actual emails the team had previously tagged.

Stage 3: Routing. Based on the classification, the email is automatically assigned to the right queue and team member. Billing goes to the finance team. Technical issues go to the support queue. High-urgency items get flagged in Slack immediately. Spam gets archived.

Stage 4: Draft response. For common request types (password resets, invoice copies, status updates), the agent drafts a response using templates seeded with the customer's actual data from the CRM. The team member reviews and sends with one click, or edits as needed.

The edge cases that almost broke it

The first version worked well on clear-cut email. Real inboxes are messier. What had to be handled:

Multi-topic emails. A customer writes: "Hey, my invoice is wrong AND I can't log in." The agent initially classified this as "billing" and routed it to finance, who could not help with the login issue. The fix was to allow multiple tags, routing to the primary category and CC'ing the secondary team.

Emotional tone. An email that says "I've been waiting THREE WEEKS for a response" is technically a general inquiry, but it needs to be treated as high-urgency. A frustration detector in the classification prompt bumps urgency when the language signals an unhappy customer.

Reply chains. When customers reply to their own thread with new information, the agent would sometimes re-classify on the latest reply alone, losing context. The last three messages in the thread are now included in the classification.

Internal emails. Team members occasionally forward emails to the shared inbox with notes like "can you handle this?" The agent would classify the forwarded email rather than the internal request. A rule detects internal sender domains and routes those differently.

What the results look like

After a couple of weeks of tuning, the agent handles the full triage automatically. Typical numbers for a build like this:

• Classification accuracy: 94%. Out of 200 daily emails, about 12 get mis-categorised. The team corrects these with one click, and those corrections feed back into the prompt examples.
• First-response time: dropped from 4 hours to under 30 minutes. The draft responses for common requests go out almost immediately after review.
• Human triage time: dropped from 3 hours/day to 20 minutes. The team now reviews flagged items and edge cases instead of reading every email.
• Spam filtering: 99%+ accuracy. The agent catches spam that the email provider's built-in filter misses.

What the tech stack looks like

The whole system runs on a standard Rails application. Email processing is handled by Sidekiq background jobs. The AI classification calls go to OpenAI's API. Customer data lookups hit the CRM via API (in this case, HubSpot). Notifications go through Slack's webhook API.

There's no exotic infrastructure. No vector databases. No fine-tuned models. It is a well-structured prompt, good error handling, and careful logging, so a mistake is visible and the prompt can be corrected. If you're considering workflow automation like this, the tech stack matters less than the prompt engineering and feedback loops.

When this approach makes sense

Email triage is one of the workflows worth automating first when volume is high and categories are stable. At low volume, a person can sort the box in a few minutes and a build is usually the wrong spend. At roughly 100+ messages a day with categories that do not thrash every week, the hours saved are large enough that a fixed-price agent is worth scoping against your real volume, not a generic payback claim.

The other key factor is whether draft responses are useful. If every email requires a completely custom reply, the agent's value is limited to classification and routing. But if 60-70% of emails fall into known categories with standard responses, the draft feature is where the real time savings happen.

What to do differently next time

Build the feedback loop from day one. The first version had no easy way for the team to flag a mis-classification; a "wrong category" button arrived after the first week, and the correction data turned out to be the single most valuable input to accuracy. Start with the feedback mechanism, then launch the automation.

Invest more upfront in the email parsing step. Stripping HTML, removing signatures and handling forwarded messages cleanly is what decides your classification accuracy: a quoted reply chain the parser failed to strip reads to the model as a fresh enquiry about whatever the original thread was about. This is the edge-case work that separates a Zapier-level automation from a custom integration that survives contact with a real inbox.