Deterministic rules vs. AI for email recipient classification in dispatch automation
When a dispatch workflow has to decide "is this email thread internal-only, or does it already include the external carrier?", that decision should be a deterministic rule, not an LLM call. The recipient list is structured data you already have; inferring from it with a model adds non-determinism, variable cost, and audit gaps you do not need.
It feels like a judgment call. It is not. It is a business rule with a clear input (the recipients on the latest message) and a clear output (reply here, or start a new thread). Treat it like one.
What is recipient classification?
Recipient classification is the step in an email-driven workflow that decides who a given message is between, so the workflow knows what to do next. In dispatch, the common version is: look at the most recent message in a load's email thread and determine whether it contains an external party (the carrier) or only internal staff. That answer drives the next action: reply to the existing thread, or go back and reply to the original message that included the carrier.
The classification itself is mechanical. Every message carries a structured list of senders and recipients. "Does this list contain an address outside our domain?" is a set-membership check, not an inference.
Why not just let the agent decide?
Because the moment you hand that decision to an LLM, you have turned a reliable lookup into a probabilistic one. The model has to read a thread, find the right message, parse a recipient list that changes from message to message, and reach the correct conclusion every single time. A long thread where each reply has different people CC'd is exactly the input that produces inconsistent results.
The same prompt that works on the threads you tested can fail on threads you have not tested. You will not know which threads until one fails in production. Defining this in a prompt is more vulnerable to error than defining it in a condition, because the prompt has no guarantee it is looking at the right message or reading the list the same way twice.
Deterministic rule vs. LLM inference
| LLM inference | Deterministic rule | |
|---|---|---|
| Decision basis | Model reads the thread and infers | Read recipients off the latest message, check against a list |
| Consistency | Same input can yield different output | Same input always yields the same output |
| Cost | Per-call tokens, scales with thread length | Negligible, fixed |
| Audit trail | No decision trace to reconstruct | Explicit condition you can point an auditor to |
| Failure mode | Silently picks the wrong recipients | Fails loudly on a rule you can read |
| Adding an edge case | Reword the prompt, re-test everything | Add a branch to the condition |
The failure mode that should end the debate
If recipient classification gets the call wrong in the leak-prone direction, you reply to a thread that includes an external carrier with content meant only for internal staff, leaking internal communication to an outside party. That is not a quality regression you smooth over later. In supply chain, where the external party is a separate company, it is a confidentiality incident.
A deterministic rule makes that outcome auditable: you can state exactly which condition fired and why. An LLM that "decided" the thread was internal gives you nothing to point at after the fact. When the controlling question is "can I prove what happened," inference is the wrong tool.
What the deterministic version actually looks like
The rule is small. On the latest message in the thread:
- Collect the full recipient list (To and CC).
- Check whether any address falls outside your organization's domain.
- If an external address is present, reply on the existing thread.
- If the message is internal-only, reply to the original message that included the external party instead.
Expose the result as an explicit variable, a plain "is external: yes/no" flag, and branch on it with a conditional. The logic is readable, testable, and the same on the thousandth load as it was on the first. New edge cases (a changed carrier, a different relationship type) become new branches, not a prompt rewrite that risks regressing the cases that already worked.
One caveat worth flagging: email platforms thread differently. The classification rule is the same regardless of platform, but the mechanics of targeting a specific message to reply to vary by platform, so the workflow handles that detail rather than exposing it to the logic layer.
When does an LLM belong in the loop?
When the input is genuinely unstructured and the decision is genuinely judgment. Reading the body of a carrier's reply to extract a driver name and phone number, or interpreting freeform text, is model work. The data is not structured and the variation is real. Classifying a recipient list is the opposite: the data is already structured, and the rule is fixed. Use the model where there is ambiguity to resolve, not where there is a list to check.
Frequently asked questions
Is deciding who belongs on a thread a judgment call? It looks like one, but the inputs are structured (the recipient list) and the rule is fixed (external party present or not). That makes it a deterministic business rule, not a judgment call.
Why is non-determinism a problem if the agent tests fine? Because passing on the threads you tested does not guarantee passing on the ones you did not. Threads with varying CC lists per message are exactly where an LLM produces inconsistent results, and you only find out in production.
What is the real risk of getting it wrong? Replying to the wrong recipients can leak internal communication to an external party. With a deterministic rule you can prove which condition fired; with model inference you cannot reconstruct the decision.
Where should we still use an LLM? For unstructured judgment, such as extracting details from message bodies or interpreting freeform text. Not for checking a structured recipient list.
The test is simple: if the decision runs on structured data against a fixed rule, make it deterministic. If you want to see how Moneiva keeps the judgment calls auditable and the rules out of the model, talk to us.