Route optimization keeps improving. It still can’t see what drivers see.

One morning this summer, a box truck was idling at the curb outside our office, so I asked the driver what he thought of the route plan he’d been given. He told me he doesn’t follow it. His run includes a hospital where traffic backs up early and parking runs out, and handoffs there drag in the morning in a way they don’t later in the day. So he does his other stops first and circles back to the hospital. None of that is in the plan he gets each morning.

His plan wasn’t one of ours, but we hear some version of that answer from fleet after fleet. The driver is doing what the plan can’t: reading the road, adjusting, and remembering for next time. At Nash, autonomic is our word for a system that does all three on its own. It acts, learns, and acts better tomorrow than it did today, against the goal you set and inside the rules you define.

The solver is rarely the problem

Modern routing solvers are good at the math. Give one accurate inputs and you’ll get back near-optimal routes that respect every constraint. When a plan falls apart on the road, it’s usually because nobody told the solver something the driver or planner already knew.

The starting point: what our plans know, and what the driver knows

In our experience, what’s missing falls into three gaps: some rules never reach the solver, travel and service times are only estimates, and some patterns only drivers ever see. We’ve been working through them in that order.

Past plans show which constraints bend

Customers hand us their operating rules at onboarding: stop limits, start times, vehicle zones. Then we look at their past plans and often find those same rules broken, usually for good reason. Planners know which constraints are hard and how far the soft ones stretch. The rules file doesn’t.

When we pointed an AI agent at a customer’s spreadsheets, it turned their rules into 59 constraints in 13 minutes, each traced to the cell it came from. Then we check them against the customer’s past plans and go through every difference with their team. That conversation is usually where the real rules come out.

The rules file, the record, and the rule that holds

A second agent builds a route plan from those constraints and flags anything that breaks one. A person still approves every plan it proposes before it goes out.

Recorded drives show where the map is wrong

Timing is the second gap, and his hospital run hits it twice. Our plans start from a road-network travel-time matrix, which knows the distance to the hospital and typical road speeds. It can’t see that the drive jams up before 9am, and no map is going to tell you the morning handoff drags.

To check the map against the road, we trained a model on recorded drives. It compares each actual drive time with the map’s prediction and learns where the two diverge by hour, day of week, and area. The map turned out to underestimate short hops and overestimate long drives, so no single fudge factor was ever going to fix it. On held-out drives the model cut typical travel-time error from 29% to 24%, and the map’s habit of predicting drives too short nearly disappeared. The biggest gain came on the shortest hops, where the map was furthest off. The model also held up on a second customer’s drives.

The map is most wrong on the shortest hops

Service time needs its own model, because a stop is a lot more than the handoff.

Instead of a flat service time, our models predict each delivery’s duration from that address’s history, so a site that is always slow gets planned that way. His hospital is trickier, because it’s slow in the morning and quick later in the day, and an average hides exactly that. To get it right, the model needs the hour of the visit, not just the address.

Every new model has to survive a replay before it gets anywhere near a live plan. The replay is a backtest: it reruns a real week of one customer’s orders at production’s 15-minute planning cadence. With nothing changed, it assigned the same orders as production on all 112 shifts we tested.

The replay also showed us what caution costs. That customer pads its planned drive times on purpose, so plans assume vans drive slower than they actually do. It’s a sensible margin, but it also means turning away orders the vans could have carried. We replayed the week with the padding trimmed step by step. Once vans were planned 28% faster, the plans fit 29.7 orders per van-shift instead of 25.0, with no rise in unassigned orders. Push further and unassigned orders did rise, but only on quiet evening shifts. A near-empty route always looks like it has room, so order intake kept saying yes until the shift ran out of hours.

Planning closer to real speeds carries more orders

Next, the plan learns from the road

Most fleets already record taps and timings at every stop. The data is noisy, and it needs real cleanup before it can teach a plan anything. But if a hospital like his is slow to serve before 10am most mornings, the plan should learn that from recent visits. It can then schedule the hospital later, the way he already does.

The autonomic cycle: how the road reaches the plan

Next we put the travel-time model into every plan, one replayed week at a time, with stop timings close behind. We keep learning new things about this problem, and it’s not one anyone solves alone. If any of this sounds familiar, reach out and tell us what you’ve learned. And when a plan finally knows about his hospital mornings, maybe the driver outside our office will actually follow it.