A few months ago, I built an email agent for a friend who spends most of her workday driving between client sites. Healthcare job. Constant emails. No time to check her inbox at a desk.
So I built something in Lindy that would let her call a number, have the agent read her emails out loud, and respond by voice. “Archive that.” “Draft a reply.” “Snooze until tomorrow.”
It worked. But here's what I learned building it: the routing logic is where most people get stuck. Not the voice part, not the AI writing part. The part where you tell the agent what to do with an email.
Most people build conditions. And conditions cause problems.
The Condition Problem
When you're new to email agents, the natural instinct is to build rules. One condition for refund requests. One for scheduling. One for support issues. One for partnership inquiries. You think: if I cover every type, the agent will handle everything correctly.
The problem is how conditions work.
They process sequentially. The agent checks condition one, then two, then three. In order, every time. So if your first condition is “check for refunds,” and someone sends you an email that says “I bought a shirt last week and ended up returning it, but by the way I'm having trouble downloading your app” — the agent sees “refund” first. Flags it as a refund request. Routes it to the wrong bucket.
The person needed help with the app. But you're looking at a refund queue item.
This is what I call a false positive. And the more conditions you have, the more false positives you get. I've seen people with 12-15 conditions whose agents still misfire on a regular basis. They keep adding more conditions trying to patch it. It doesn't work. The logic just gets more fragile.
The Fix: One Agent Step
The better approach is to delete all your conditions and replace them with a single agent step.
Instead of a rule-based flowchart, you give the agent one job: read the email, understand what's actually being asked, and output one of three decisions.
Archive. Nothing needed. The email is informational, automated, or doesn't require a response. File it away.
Draft. Something requires a response. The agent writes a draft, and you review it before anything goes out.
Snooze. You need to handle this, but not right now. Set it aside to come back to.
Three options. That's the whole framework.
The AI handles this much better than keyword-based conditions because it's reading the email, not scanning for triggers. It understands context. An email that mentions “refund” in passing but is really asking about an app issue will get correctly classified as a support question — because the agent read the whole thing and understood the actual intent.
Why the Draft Bucket Matters
The middle option, draft, is the one most people underestimate.
There's a real temptation to let the agent send emails automatically. And for some things, that's fine… automated acknowledgments, scheduling confirmations, simple responses to low-stakes messages.
But for most business email, you want a human in the loop before anything goes out. Reputation, relationships, nuance. These aren't things you want to fully delegate.
The draft bucket solves this. The agent writes the reply. You review it — takes 30 seconds usually. You hit send. You still get the time savings (no starting from scratch, no staring at a blank compose window) without the risk of the agent saying something you didn't intend.
Editing is faster than creating. That's the real value here.
How to Set This Up
After your email trigger in Lindy (or whatever agent platform you're using), add a single agent step with this instruction:
“Read this email and decide how to handle it. Output one of three options: ARCHIVE if no response is needed, DRAFT if a response should be written (then write the draft), or SNOOZE if this needs attention later. Base your decision on the full content and intent of the email, not just keywords.”
That's the whole thing. You can add specifics for your situation — “always draft if the email is from a client,” “always archive order confirmations from Shopify” — but start with the simple version and tune from there.
The results are almost always cleaner than what people get from a 10-condition flowchart.
The Bigger Lesson
This pattern applies beyond email. Any time you're building an agent to triage or categorize things, the rule-based approach hits a wall fast. Real-world inputs don't fit into neat buckets. Language is messy. People are messy.
An agent step that reads for intent is almost always more accurate than a chain of conditions checking for keywords.
Start with the simple version. Three options. One agent step. See how it works. Then layer on specifics where you actually need them.
Want to build your own email agent from scratch? The 4-Day AI Sprint covers this workflow in detail, including how to set up the three-bucket system and personalize it for your inbox.
