agent email routing logic: dispatch patterns compared

Your system has five agents. A customer emails about a refund. The billing agent should handle it, but the message lands on the general-purpose agent instead. It generates a vague response. The customer replies, frustrated. This time the security agent picks it up because the subject now says "possible fraud."

This is a routing problem. The agent email routing logic dispatch pattern is the decision layer that classifies incoming messages and forwards them to the agent best equipped to respond. It can rely on rule-based matching, LLM intent classification, a skill registry, or some combination of all of them.

Four dominant patterns exist today, and picking the wrong one leads to silent misroutes or a bottleneck that brings down your entire pipeline.

The rest of this article breaks down each pattern, covers the failure modes that most guides skip, and walks through how email metadata should actively shape dispatch decisions.

Static routing: pattern matching at the edge#

Static routing is the simplest dispatch pattern. You define explicit rules. If the sender is billing@vendor.com, route to the billing agent. If the subject contains "password reset," route to the security agent. The system matches inbound messages against those rules and dispatches accordingly.

This works when your email volume is low and the categories are predictable. A support agent that handles email might use static routing to separate refund requests from shipping inquiries based on subject-line keywords.

The limitation is brittleness. A customer who writes "I got charged twice" instead of "refund request" hits no rule and either gets dropped or routed to a catch-all. There's no understanding of intent, just string matching.

Static routing fits internal automation with consistent formatting: transactional notifications from known senders, structured webhook-triggered emails, or any flow where the message format doesn't vary.

LLM-based dynamic dispatch#

Dynamic dispatch replaces pattern matching with intent classification. An LLM reads the incoming email, determines what the sender needs, and routes to the agent with the right capability.

Most agentic frameworks are converging on this model. AWS Bedrock Agents use a classifier to interpret user intent and delegate to sub-agents. LangChain's routing chains do the same, with the LLM acting as a switchboard. Cloudflare's routeAgentEmail function takes a similar approach for Durable Object dispatch, dynamically classifying inputs and directing them to specialized handlers based on content analysis.

The advantage is flexibility. You don't need to anticipate every possible phrasing. The LLM understands that "my account got charged twice" and "process my refund" should route to the same agent, even though the words share nothing in common.

The cost is latency and reliability. Every routing decision requires an inference call. If the model hallucinates a classification (routing a legal complaint to the billing agent), the downstream agent either fails silently or generates a response that shouldn't exist. At scale, even a 3% misclassification rate compounds into real damage.

If you're building something like an agent that triages your support inbox, LLM-based routing is probably the right starting point. Just plan for the failure modes covered below.

How email metadata should shape dispatch#

Most routing guides treat emails like plain text to classify. That misses half the signal. Email carries structured metadata that should influence dispatch decisions before the LLM ever touches the body.

Thread headers like In-Reply-To and References tell you whether this is a new conversation or a follow-up. A follow-up should route to whichever agent handled the original thread, not get reclassified from scratch. Breaking thread continuity is one of the fastest ways to frustrate a sender.

Authentication results matter too. SPF, DKIM, and DMARC outcomes arrive as headers on every inbound message. A failing DKIM signature on a "wire transfer" request is a strong signal to route to a security-review agent rather than the finance agent, regardless of what the body says.

The SMTP envelope MAIL FROM can also differ from the visible From: header in the body. Mismatches happen legitimately in forwarding setups, but they're common in phishing attempts too. Your routing logic should flag the discrepancy and factor it into the classification score rather than ignoring it.

Using metadata as a pre-filter reduces load on your LLM classifier and catches edge cases that pure content analysis misses entirely.

Multi-agent handoff chains#

Real email workflows rarely end with a single agent. A billing question might require escalation to legal review, which might hand off to compliance. This creates a handoff chain where each agent processes the email, adds context, and passes it forward.

The pattern looks clean on a whiteboard, but email-specific failure modes make it tricky. You typically choose between two approaches:

1. Internal routing, where the email stays within your system and agents pass context objects between themselves.
2. Email forwarding, where one agent literally forwards the email to another agent's inbox, preserving the thread.

Internal routing is faster but couples your agents tightly. Email forwarding preserves loose coupling (each agent just processes its own inbox) but adds delivery latency and the risk of bounce-induced chain breaks.

We covered the coordination patterns for this in multi-agent email: when agents need to talk to each other. The short version: if your chain is longer than two hops, internal routing with explicit state passing is more reliable. If agents are independently deployed on different infrastructure, email forwarding keeps them decoupled at the cost of some added complexity.

Failure modes most routing guides miss#

Dead-letter queues for unroutable messages#

When no agent matches an incoming email, the message needs somewhere to go. Without a dead-letter queue, it disappears. Your DLQ should capture the original message, the classification attempt, a timestamp, and the routing decision that failed. Review it daily during early deployment. You'll find your routing gaps there.

Misclassification recovery#

When an LLM routes an email to the wrong agent, the receiving agent needs a way to reject it and trigger a re-route. Agents should signal "this isn't mine" back to the router, ideally with a reason. Without this feedback loop, misclassified emails get answered badly instead of answered correctly.

Bounce handling in dispatch chains#

If agent B's inbox bounces (full, misconfigured, or temporarily down), the routing layer should catch the bounce notification and retry or escalate. Treating bounces as terminal in a multi-agent chain means losing real emails at the worst possible moment.

Observability#

Attach a trace ID to every routing decision. Log the sender, subject, classification result, destination agent, and latency. When someone says "I emailed you three days ago and nobody responded," that trace log is the only way to figure out where the message actually went.

Picking the right pattern#

Start with the simplest approach that covers your volume. Three agents handling 50 emails a day? Static routing with a catch-all fallback works fine. Ten agents processing varied inbound from unknown senders? LLM-based dynamic dispatch is worth the inference cost.

For most teams building agent email systems today, the practical path looks like this: give each agent its own inbox, use LLM classification at the routing layer, pre-filter with metadata to reduce inference calls, and set up a dead-letter queue from day one. If you want each agent to hatch its own address without manual provisioning, LobsterMail handles that part.

You can always layer skills-based routing on top as your agent registry grows. The routing pattern is the plumbing. Get it right early, and you won't rebuild it when you go from five agents to fifty.