Kardinal has rebuilt a route optimization API for a reader it did not have a year ago. In Kardinal opens a route optimization API designed to be driven by AI agents, the last-mile specialist, building optimisation software since 2015, launches self-serve access and names the problem precisely: an agent working from API documentation “produces code that compiles and calls that succeed, but almost always formulates the wrong problem, one that cannot be executed in the field.” The gap between a real operational problem and its optimisation model always existed, and agents, “non-deterministic by nature, amplify it: they quickly produce a plausible formulation, without the signal that would tell them it is wrong.”
The figures are attributed and caveated, which is the right way to publish them. Agent share of documentation readers, from Mintlify’s data, rose from 15 percent in February 2026 to 67 percent by August. Kardinal’s own result, from “an internal evaluation protocol applied to modeling cases drawn from industrial projects,” is that the modelling failure rate drops “from over 80% to under 5%,” with the protocol available on request. The method is what the post calls harness engineering: documentation written for agents that explains when to use each setting, a CLI and an SDK that “catches mistakes early,” and next, guidance inside the API itself, so that “when a delivery plan doesn’t hold up, the response will explain why and what to try next.” Pricing is per optimised stop, billed once however many times a plan is recalculated within 24 hours, from 0.012 euros, with the first 1,000 stops free.
The catalog holds the API the post describes. The Kardinal provider page lists 8 API pages, and an agent’s loop runs through the Kardinal Plan API and the Kardinal Simple Plan API to submit a problem, the Kardinal Solution API to read the result, and the Kardinal Order API and Kardinal Resource API for the stops and vehicles being modelled. On the Agent Readiness score, the MCP server, agent skills, idempotency, error semantics and OpenAPI examples are all lit, a good fit for a product whose pricing lets an agent re-optimise freely.
The Kin Score is 47.4, developing band, with discoverability at 75.0 and developer ergonomics at 71.4 against operational transparency at 2.6 and contract governance at 4.5. The Agent Readiness score is 34.2, agent-ready. Error semantics is already lit, and the post’s next step, responses that explain why a plan fails and what to try, is that dimension taken from status codes to domain reasoning. What is unlit is the event surface, for plans that take time to solve, and the identity layer. Kardinal has made the API tell an agent when its model of the problem is wrong. The operational transparency facet at 2.6 says the record cannot yet tell an agent much about the service itself.