# Deterministic rules vs. AI for email recipient classification in dispatch automation

Deciding whether a stakeholder belongs on an email thread looks like judgment, but it's a business rule. Why deterministic logic beats LLM inference.

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](/contact#contact-form-section).

## Related reading

- [Check driver availability via API before you dial: smarter outbound calls in dispatch automation](/insights/api-driven-driver-availability-outbound-calls)
- [Email thread complexity in dispatch automation: keeping carrier communication in one thread](/insights/email-thread-complexity-dispatch-automation)

Source: https://www.moneiva.com/insights/deterministic-rules-vs-ai-email-classification