Here's the situation I was trying to fix.
My inbox had become a second job. Not the volume—I get maybe forty to sixty emails a day, which is unremarkable—but the decision cost. Every message required a judgment: reply now, reply later, ignore, delegate, archive. That's forty small decisions before I've done any real work, and by mid-morning my attention was already spent.
So I built an AI triage system. The premise was simple: let the model sort, tag, and draft, and let me only make the decisions that actually needed a human. I ran it for thirty days, under real conditions, with a full-time job and a family. This is what actually happened.
The System I Built
Before the failures, here's what it was, so you can judge whether your version would break the same way.
The Design
Three layers, running in sequence:
Classification. Every incoming email got tagged into one of five buckets: needs my reply, needs my decision, FYI only, delegate, or noise.
Drafting. For anything in needs my reply, the model generated a draft response, pulling from a short context file with my tone preferences and common replies.
Batching. Instead of a live feed, I reviewed everything twice a day—once at 9am, once at 4pm. The model surfaced a prioritized list, and I approved, edited, or killed each draft.
Setup took about four hours across two evenings. The maintenance was supposed to be near zero. That assumption was the first thing to break.
What Broke
Six failures, roughly in order of when they showed up.
Failure 1: The Classification Was Confidently Wrong
The model was right maybe 85% of the time. That sounds good. It isn't.
The problem: the 15% it got wrong was the 15% that mattered. Routine messages it sorted fine. The email from my manager that looked like an FYI but was actually asking for a decision got filed as FYI only, and I didn't see it for a day. The vendor message that looked like noise was a contract question with a deadline.
Worse, the errors were silent. A wrong classification doesn't announce itself. You just quietly miss something, and you find out later, usually when it's expensive.
What I changed: I added a rule that anything from a short list of key people—manager, direct reports, a handful of clients—never gets auto-classified. It goes straight to needs my reply. This cut the miss rate dramatically, but it also meant the system was doing less of the work than I'd hoped.
Failure 2: Drafting Was Faster but Not Better
Here's the honest accounting. The model's drafts were usable about 60% of the time. For those, I saved maybe ninety seconds each. For the other 40%, I spent more time editing the draft than I would have spent writing from scratch—because now I had to read someone else's version, decide what was wrong with it, and fix it.
The net effect was a small time saving with a real quality risk. Model drafts have a particular failure mode: they're competent and slightly off. They get the structure right and the tone wrong. They're too long when they should be short, too formal when the relationship is informal, too hedged when the answer is simply yes.
What I changed: I stopped drafting for anything with relational stakes—anything where tone was the point. Drafting stayed for purely logistical replies: scheduling, confirmations, simple information requests. That's maybe a third of my inbox.
Failure 3: The Context File Became a Maintenance Job
To make drafts sound like me, I built a context file: tone notes, common responses, phrasing preferences. This worked for about two weeks. Then it started drifting.
Every time I edited a draft to sound more like me, I thought about updating the context file. Sometimes I did. Mostly I didn't. And so the file slowly went stale, and the drafts slowly drifted back toward generic—except now I trusted them more than I should have, because I'd put work into making them mine.
What I changed: I stopped maintaining the context file as a living document. Instead, I write a fresh, short context note whenever I start a batch session. It takes two minutes, it's current, and it doesn't accumulate cruft.
Failure 4: The Batching Created Its Own Anxiety
The two-batch design was supposed to protect my attention. It did—for the first week. Then I noticed something: knowing there were unreviewed emails waiting made it harder to focus during the work blocks in between. The batching removed the notification, not the awareness.
And when I did open a batch, the backlog had a weight to it. A live feed of routine messages is oddly calming; it's always there and it's never urgent. A batch of twenty pre-classified messages with drafts attached feels like a decision pile, and decision piles are heavy.
What I changed: I kept batching for the drafting layer but reverted to a live feed for triage. Knowing what's coming in, in real time, turned out to be worth more than the attention savings.
Failure 5: Delegation Became a Reporting Job
The delegate bucket was supposed to reduce my work. In practice, it created a second inbox: forwarded messages with a note, then a follow-up thread to confirm it happened, then often a third thread when it didn't.
Forwarding is not delegation. Delegation requires context, expectations, and a way to check. The model could forward, but it couldn't establish the accountability, so I ended up doing that part manually—often for messages that, in retrospect, I should have just answered myself in two minutes.
What I changed: I deleted the delegate bucket. Delegation now happens out of the triage system entirely, in person or in a dedicated channel, where accountability actually lives.
Failure 6: Privacy and Trust Were Real Costs
This one is harder to quantify but was probably the most important. Even with a local-ish setup and careful handling, I found myself hesitating. Should this message go through the model? Does this attachment belong in the flow? Is this person okay with their email being processed this way?
That hesitation is a cost. It slows every message slightly and adds a low-grade ethical hum to the whole system. And the hesitation wasn't irrational—some of those messages genuinely shouldn't have gone through.
What I changed: I defined a clear exclusion list—anything with personnel details, legal context, or a sensitive relationship—and kept those out of the system entirely. That means the system handles maybe half of my inbox, not all of it.
The Honest Accounting
After thirty days, here's the real score.
What actually worked:
Classification for routine, low-stakes messages, when paired with an exclusion list
Drafting for purely logistical replies
The discipline of a defined triage policy, regardless of tooling
What didn't:
Auto-classifying messages from key people
Drafting anything with relational stakes
Maintaining a living context file
Replacing a live feed with batches
Automating delegation
Handling sensitive messages
Net time saved: roughly fifteen to twenty minutes a day. Not the ninety I'd imagined. Real, but modest—and it came with a setup cost of four hours and a maintenance cost of about ten minutes a day.
The honest math: the system paid for itself in about three weeks, then kept paying a small dividend. That's a "keep it, in reduced form" outcome, not a triumph.
What I Kept
The version that survived is smaller and less automated than the original:
A live feed for triage, with everything visible as it arrives.
An exclusion list—key people and sensitive messages never touch the system.
Drafting only for logistics. Scheduling, confirmations, simple requests.
A fresh context note per session, not a maintained file.
No delegate bucket. Delegation happens in person.
A twice-daily review habit, not a batching rule.
That's a system doing maybe a third of what I designed it to do. It works. The thirty-day version didn't.
What Still Needs You
The parts of inbox triage that never got automated, and shouldn't:
Deciding what's sensitive. The model can't know which messages carry relational or legal weight. That judgment is yours, and it has to be made before the message enters the system, not after.
Reading the room. Whether a reply should be short or warm, direct or soft, is a human call. Model drafts are structurally fine and tonally unreliable.
Owning the delegation. Forwarding is not assigning. Accountability lives in relationships, not in filters.
Knowing when to stop. Some inboxes shouldn't be triaged at all—they should be answered. The system's job is to protect the time for that, not to replace it.
The One-Week Version
If you want to test this before running a month:
Pick one layer, not three. Start with classification only.
Build a short exclusion list before you start—key people and sensitive categories.
Run it for a week. Count the confident errors, not the successes.
Add drafting only for logistics, and only if classification held up.
Keep whatever survives the week. Delete the rest without guilt.
The point of a field test isn't to prove the workflow works. It's to find out where it breaks, cheaply, before it's load-bearing. Most of my original design failed, but it failed in week one and week two, when the cost was small.
The workflow that survived isn't the one I designed. It's the one that earned its place.
Better work first. More options next.
Make the workflow earn its place.
No feedback yet — submit the first.