Route inbound mail to the right agent automatically

Most "AI email agent" demos run one model against one mailbox: every message that lands gets the same prompt, the same context, the same handler. That's fine for a toy. It falls apart the moment your inbox is actually doing several different jobs — a billing question, a security report, and a sales lead all arriving at [email protected] within the same minute, each wanting a different specialist.

The naive fix is to make the one agent smarter: a giant system prompt that classifies, then branches into sub-behaviors. You end up with a monolith that's hard to test, hard to rate-limit per concern, and impossible to scale independently.

Here's the thing most people miss: one mailbox can feed several agents if you route mail into per-specialty queues before the agent ever sees it. You don't need a smarter agent. You need a smarter inbox. With a Nylas Agent Account the triage splits along one clean line. When you can route by sender — who the mail is from — inbound Rules do it server-side, sorting mail into per-specialty folders before it even reaches the mailbox. When you need to route by subject or content, a Rule can't see that, so your own worker classifies the message after a message.created webhook fires and moves it. Either way, a different worker drains each folder. The billing agent only ever sees billing mail. The security agent only ever sees abuse reports. Clean separation, no central classifier to babysit.

This is deliberately different from agent-to-agent handoff, where one agent emails another to delegate. This is fan-out: one inbound stream, split by rule into parallel queues, each consumed by a specialist. Mail arrives once and lands in exactly the right place.

What you get

• 
  Triage in the platform, not in your code. Rules evaluate on receipt. By the time your worker polls, the mail is already in billing or security or sales. No classifier service to deploy, scale, or pay an LLM bill for.


• 
  Independent workers. Each specialist is its own process. Restart the sales agent without touching billing. Give the security agent a tighter SLA. Scale the busy one horizontally.


• 
  One mailbox, one domain reputation. Customers still write to a single address. The fan-out is invisible to them.


• 
  Nothing new on the data plane. An Agent Account is just a grant with a grant_id. Folders and messages are the same grant-scoped endpoints you'd use against any connected mailbox. (Webhooks are the one exception — they're application-scoped: one subscription for every grant, filtered by grant_id.) If you've listed messages before, you already know the API.

Why this beats one mega-agent

A single agent that classifies-then-branches couples three things that should be separate: the routing decision, the specialist logic, and the scaling unit. When sales volume spikes, you scale the whole thing. When the billing prompt regresses, you redeploy everyone. And every message pays the classification tax — an LLM call just to decide which LLM call to make next.

Rule-based fan-out moves the routing decision to the platform, where it's deterministic, auditable, and free. from.domain is stripe.com is not a judgment call. It either matches or it doesn't, every time, and Nylas records why it matched so you can answer "where did this go?" without log spelunking. Your agents shrink to one job each, which is exactly the size that's easy to test.

The honest tradeoff, stated plainly because it shapes the whole design: inbound rules match on sender fields only — from.address, from.domain, from.tld, with operators is, is_not, contains, and in_list. They do not read the subject line or the body. (Recipient fields and outbound.type exist, but only for outbound rules — they're useless for inbound triage.) So you get two routing modes:

• 
  Sender-based routing → Rules. Deterministic, server-side, evaluated before the mail hits the mailbox, and free. This is Steps 1–3.


• 
  Subject- or content-based routing → your app. A rule can't classify "is this an angry customer?" or "does the subject say INVOICE?" For that you receive the message.created webhook, fetch and classify the message yourself, then move it into the right folder (or dispatch it to a worker directly). This is Step 4's content path.

Most teams use both. Lean on rules for the cheap, unambiguous cases — your payment processor, your bug-bounty platform — and reserve app-side classification for the genuinely fuzzy ones.

Before you begin

You'll need a Nylas application, an API key, and an Agent Account on a registered domain. If you haven't provisioned one yet, the — every inbound condition field, operator, and action, plus Lists for in_list matching