My team and I spent 10 years doing route optimization as a service for companies like DPD, GLS, and JCDecaux: they'd send us their data, we'd configure a solver, they'd get routes back. It worked, but it meant months of sales calls before anyone could tell if it actually fit their case.
Today we're opening that same engine as a self-serve REST API.
The problem we kept running into
Somewhere in the last year, most of our new integration requests stopped coming from ops teams and started coming from developers wiring an AI agent into their logistics stack. That tracks with the broader shift: across Mintlify-hosted docs, humans went from 85% of technical documentation readers in February to 33% by August, AI agents making up the rest. That changed what "good documentation" actually means.
An agent working alone against docs written for a human produces code that compiles, API calls that succeed, and a model that's wrong. Not wrong in a way that throws an error, wrong in a way that looks fine on paper and falls apart on the road.
Here's a real example. In bulky goods delivery, a plan can look perfectly optimized on a map and be physically impossible to run, because a large customer return (a sofa, a bed) picked up early in the route ends up blocking the vehicle's loading space for every delivery that follows. Nothing in the API response flags this. The request was valid. The model just didn't capture the constraint that mattered.
This isn't new. It's the same gap that's always existed between how an operation actually runs and how someone translates that into a solver. What's new is the speed: an agent produces a plausible-looking model in seconds, with no instinct telling it something's off. A human integrator eventually notices the plan doesn't match reality. An agent, left alone, usually doesn't.
What we changed
We rebuilt our interfaces around that specific failure mode, not around adding features. A typed SDK that makes certain mistakes impossible to write instead of just documenting them. A CLI built the way agents actually work, not a wrapper around the API. Docs that explain when to use a parameter and why, not just what it accepts. Guides built around the hard, real cases we've hit over ten years, not the one clean textbook example most routing docs lead with.
On our internal benchmark, that work took agent modeling failure rate from over 80% down to under 5%. That's our own protocol on our own reference cases, not an independent study, happy to go into more detail on methodology if anyone's curious.
Next up: when a delivery plan doesn't hold up, the API response will explain why and what to try next, so an agent can keep reasoning instead of getting stuck.
What it does, concretely
Send your stops and vehicles, get optimized routes back in under 2 seconds. Out of the box it handles 149 real-world constraints pulled from actual client cases, not synthetic test data: time windows, multi-depot, driver breaks under EU 561, cold chain, pickup-delivery pairing, heterogeneous fleets. If a truck breaks down mid-route, re-optimization from live state runs in under a second, free, no matter how many times you need to recompute within a 24-hour window.
We also published an open benchmark comparing 11 route optimization APIs on those same 149 constraints. Even Google Maps Route Optimization only covers about 57% of them. Full methodology and data: benchmark.
Try it
- Free tier: 1,000 stops, no sales call, no quote → console.kardinal.ai
- Docs: developers.kardinal.ai
Would love feedback, especially from anyone who's tried wiring routing into an agent workflow and hit a wall, or fought with a routing engine on constraints it didn't fully support.
Top comments (0)