An email agent needs a routing layer before model work starts. Routing decides which mailbox, tenant, policy, agent skill, and fallback queue owns the message. Without that layer, shared inboxes create duplicate replies and dropped threads.
last updated 2026-08-134 sections
section 01
Routing models
Routing can be rules-based, round-robin, skill-based, or classifier-assisted. Classifiers are useful for ambiguity, but deterministic rules should handle tenant, mailbox, suppression, and security decisions first.
model
fit
failure mode
Rules-based
Known aliases, tenants, and inboxes.
Rules drift as teams add mailboxes.
Round-robin
Simple human review queues.
Wrong assignee when messages need skill.
Skill-based
Support, billing, recruiting, or sales routing.
Skill tags become stale.
Classifier-assisted
Ambiguous inbound mail.
Low-confidence routes need fallback.
section 02
Deduplication and claim locks
Inbound providers can retry webhooks. Mailboxes can forward the same thread to several aliases. The router should dedupe by provider event ID, message ID, thread ID, and mailbox before assigning work.
okCreate a unique key from provider event ID when available.
okTrack Message-ID and thread references.
okUse a claim lock when an agent starts processing.
okExpire stale locks and route to review instead of sending twice.
section 03
Escalation paths
Good routing includes a planned failure route. Ambiguous intent, sensitive content, missing permissions, and high-risk outbound replies should move to human review.
condition
route
Low classifier confidence
Human triage queue.
Billing, legal, or security topic
Specialist queue.
Attachment cannot be scanned
Quarantine queue.
Reply would affect account access
Approval queue.
section 04
Assignment state
Every inbound message should have an assignment state that can be inspected. Unassigned, claimed, processing, waiting for approval, escalated, closed, and failed are enough for most systems.
okRecord who or what claimed the message.
okStore the current state and last state transition.
okKeep a link to the source email and audit log.
okMeasure queue lag by mailbox and route.
reading this as developers picking email infrastructure
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to agent mailbox routing, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.