If you ask a logistics ops manager how they pick the carrier for a parcel, the honest answer is usually some combination of "the contract rate spreadsheet" and "vibes." The spreadsheet is the easy part. The vibes are doing more work than anyone wants to admit. The carrier routing agent in Polluxa exists to turn the vibes into code.
This post is about what went into that code, and the three times we got it wrong before getting it right.
The naive objective
Our first version was simple. For each parcel, compute the per-parcel price across every available carrier given the contracted slabs, the parcel weight and the destination pincode. Pick the cheapest one. Ship it.
This worked, in the sense that it produced answers. It also blew up our delivery quality scores in week three. The "cheapest" carrier on paper turned out to be the slowest in monsoon, the worst at addressing in tier-2 cities, and to lose 0.4% of parcels — a fee we'd then absorb on insurance, customer support and replacement shipments. The net cost was worse than the slightly more expensive competitor.
The lesson is the one every optimization engineer eventually learns: if your objective function is wrong, more optimization makes things worse, not better.
What we picked as the actual objective
The right objective is "expected total cost to the brand per delivered parcel." That's a longer phrase but it captures the thing we actually care about.
Expanded out, it's the sum of: the carrier's per-parcel price, plus the probability-weighted cost of a delay (lost revenue from churn + customer-support contact + brand damage), plus the probability-weighted cost of a loss (replacement product + shipping again + reputational risk), plus the probability-weighted cost of a complaint (support agent time + escalation overhead), minus any contractual rebates earned by hitting volume slabs.
That's a lot of probabilities to estimate, but they're not magic. Each carrier has historical performance on each pincode-pair, each weight class, each time-of-day, each weather regime. We compute the probabilities from that history, weighted to the recent month. The agent re-fits them every Sunday on the past 90 days of data.
What broke (round one)
The first production model had a fatal flaw: it was right on average and wrong at the tails. The average parcel got better service. The high-value parcels — VIP customers, fragile electronics, expensive returns — sometimes got bumped to a cheaper carrier because the math said the expected cost was lower.
The fix is the "customer score" override. Every customer has a tier (computed from LTV, return rate, complaint history). High-tier customers always get the top quartile of carriers, regardless of marginal cost. This is a business decision, not a math decision. We exposed it as a setting and asked the customer to configure it. They appreciated being asked.
If your objective function is wrong, more optimization makes things worse, not better. We learned this with a 0.4% loss rate that ate the savings from every cheap parcel we ever shipped.
What broke (round two)
The second issue was volume commitments. Carriers offer better rates if you ship N parcels per month with them. The agent, busy optimizing per-parcel, was leaving these on the table. By the third week of the month, we'd be 200 parcels short of a slab that would have unlocked a 14% rate cut on the next 5,000.
The fix is a slab-aware bias. The agent now knows where each carrier sits relative to its next rate slab, and biases marginal decisions toward carriers approaching a threshold. The bias decays as the month progresses — so by the last day, it's effectively zero and the agent is purely optimizing per-parcel.
This added one parameter per carrier per slab. It captured roughly $40k/month of value the previous model had been quietly ignoring.
What broke (round three)
The third issue was the prettiest one. The agent picked the right carrier on the right day, and the carrier proceeded to fail because of weather, strike, vehicle breakdown, or generic chaos. We were re-optimizing every 15 minutes, but the parcel was already in their hands. By the time we knew the carrier had broken down, it was too late.
The fix: predictive re-routing. We now ingest weather, traffic and carrier-fleet signals continuously. If conditions for a parcel deteriorate beyond a threshold while it's in flight, the agent talks to the carrier's API to recall the parcel and reships via a different carrier. This is finicky — carriers don't all support recall, and the cost of an in-flight recall is non-trivial. But for the 0.8% of parcels where it matters, it matters a lot.
The human override
Every routing decision has a "why" log. Any operator can override any decision with one click and a reason code. The agent records the override and trains on it. Over time, the manual override rate has dropped from ~14% in the first month to ~1.4% now. The remaining overrides are real — usually a customer-specific carrier preference that hadn't been captured in the data.
The point isn't that the agent gets to a perfect decision rate. It's that the agent gets to "good enough that humans only check the unusual cases" — which is the only sustainable shape for this kind of work.
What's next
Three things on the roadmap. Multi-leg routing — picking different carriers for different legs of long-haul parcels. Sustainability-aware routing — adding emissions to the objective function with configurable weight (some customers want it, some don't, both should be able to set it). And a simulator that lets brands try a hypothetical carrier mix before signing the contract.
If you've got carrier contracts coming up for renewal, the routing agent can model what your unit economics would look like across different mixes. Talk to logistics — we'll run the numbers on a sample of your last quarter's parcels.