How Shipsy’s AI-native route optimization actually works
Most routing engines optimize a map. Shipsy optimizes the job. That means micro-cluster routing, parking-spot detection from the driver’s phone, and 20 years of courier tribal knowledge encoded as routing heuristics — the reason DPD Poland recovered $37M in unit economics and the reason express couriers on Shipsy consistently see materially more stops per route than on their prior stacks.
This post is for heads of last mile at courier (CEP) and postal operators who already have a TSP solver and are still losing the last 500 metres.
Why we built this
Traditional route optimization solves the Travelling Salesman Problem. But a real route is not a graph of addresses — it’s a graph of buildings, gates, lifts, security desks, unreliable lift keys, “leave with the concierge” memos, and the one apartment block where the driver always parks on the south side because the north side is tow-only after 11 a.m.
Courier operations teams have known this for decades. Their best drivers outperform routing software meaningfully because they carry that knowledge in their heads. The moment those drivers leave, the route quality leaves with them.
We built Shipsy’s route optimization to treat tribal knowledge as a first-class input — and to keep learning it from every GPS trace, every successful delivery, and every failed attempt.
How it works
Shipsy’s routing engine runs four layers, orchestrated by Astra, our planning agent inside AgentFleet.
1. Micro-cluster routing (not address-level)
Instead of optimizing one stop at a time, Shipsy groups stops into micro-clusters — typically a building, a gated community, or a 50-metre walk radius. The solver assigns a single park-and-walk anchor per cluster rather than routing van-to-door-to-van. This alone strips out a meaningful share of dead driving and is especially powerful for vertical buildings in dense CEP and postal routes.
2. Parking-spot detection from GPS + accelerometer
Every Shipsy-driven delivery app streams GPS + accelerometer data from the driver’s phone. Sudden deceleration, door-open motion signatures, and dwell time collectively identify where drivers actually parked for a successful delivery — not where the address geocodes to. Over weeks, Shipsy builds a proprietary parking-spot layer per postal code, per route. New drivers inherit that parking intelligence on day one.
3. Tribal-knowledge heuristics, encoded
Supervisors can tag routes with operational rules that the solver treats as hard or soft constraints — “Building 14 accepts parcels 10:00–14:00 only,” “Use gate 3 after 6 p.m.,” “Route 22-B requires a 2-person lift for big-bulky.” Combined with historical successful-delivery patterns, these become routing heuristics that survive driver churn.
4. Real-time re-planning
Routes are not static. When a delivery fails, when a pickup is added mid-shift, when traffic spikes, Astra re-sequences the remaining stops within seconds and pushes the new sequence to the driver app — without breaking the shift’s SLA windows or time-of-day constraints.
Together, the four layers move routing from “which address next?” to “which job next, from which parking spot, under which constraints, for which driver profile?”
Here’s the flow at a glance:
Early results
DPD Poland recovered $37M in unit economics through AI-native routing on Shipsy — a combination of fewer kilometres per stop, higher stops-per-hour, and lower failed-delivery cost. Aramex unlocked $27M in cross-border CEP throughput on the same routing stack. IKEA runs 95% first-attempt delivery rate on big & bulky. Teleport (SEA) logs a 75% planning-time reduction and 20% driver productivity lift. Postal customers running Shipsy route optimization report material gains in stops-per-route during the first quarter of operations, and Qatar Post now runs 90% first-attempt delivery rate with 12–18% cost reduction.
The pattern is consistent: the productivity gains don’t come from a better solver. They come from feeding the solver what real drivers already knew.
What’s next
The next frontier is driver-specific routing — matching route complexity to driver experience profiles — and tighter integration with Clara for proactive customer-slot negotiation so routes reflect what customers actually said yes to, not what the original SLA implied.