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-254 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 teams choosing a transactional API
Judged purely as an API. What the request contract guarantees on retry, how complete the webhook event coverage is, whether suppressions are readable and writable programmatically, and how much the message log retains when something needs debugging in production.
Applied to agent mailbox routing, that means weighing idempotency keys, webhook coverage, event stream, and operating track record ahead of the rest, against high-frequency programmatic sends where a missed delivery is a product failure.