Let a solver plan routes. Let an agent explain the exceptions.

A logistics blueprint that separates constraint solving from conversational coordination, so proposed plans remain feasible and inspectable.

A source-linked editorial perspective. Research findings are attributed below; deployment blueprints and evaluation plans are Stellitron proposals, not customer case studies or promised outcomes.

The objective changes the route

PUBLISHED RESEARCH / DOCUMENTATION

Google’s OR-Tools routing documentation describes the vehicle routing problem as assigning routes to multiple vehicles visiting locations. It discusses objectives such as minimising the longest route and extensions including capacity and time-window constraints. A route therefore depends on a defined objective and constraint model, not just a list of addresses.[1]

Start with tomorrow’s planning review

PROPOSED BLUEPRINT

Choose a bounded dispatch problem: one depot, a known fleet and orders with agreed service windows. Collect travel-time estimates, vehicle capacities, service durations and restrictions. Identify which constraints are mandatory and which can be relaxed only by a dispatcher.

Use a constraint solver for candidate plans. A language agent can gather missing inputs, invoke the solver through a narrow interface, explain the results and prepare questions about unscheduled stops. It should never claim that a route is feasible simply because its narrative looks sensible.

Make infeasibility a useful output

PROPOSED BLUEPRINT

When no acceptable plan is found, show the status returned by the planning system and the constraints that the team should investigate. Avoid asserting a definitive cause unless the solver or a diagnostic procedure establishes it. Offer explicitly labelled alternatives, such as using an additional vehicle or changing a service window, for dispatcher review.

Version the input data and the accepted plan. Keep dispatch messages as drafts until approval; do not silently reroute drivers when a model proposes a change. A production workflow needs current location and operational data, an exception policy and a way to reconcile updates with the dispatch system.

Compare feasibility before efficiency

PILOT EVALUATION

Replay cases involving overloaded vehicles, missing travel times, inaccessible stops and late orders. Check capacity and time-window violations with independent validators. Measure unscheduled stops, dispatcher changes, planning time and the objective value on a comparable baseline.

Do not advertise a mileage reduction from a demonstration built on synthetic travel times. The pilot question is whether the combined workflow produces understandable, executable proposals under the organisation’s actual constraints. A solver and an agent have different jobs; evaluating them separately reveals which part needs improvement.

Sources & publication dates

Primary papers and official documentation consulted for this perspective. Source publication dates differ from the date of this article; undated documentation is identified explicitly.

  1. Vehicle Routing Problem — Google OR-ToolsDocumentation — publication date not specified · Consulted 3 October 2026

Test a first direction.

Bring your own constraints into the demo. Explore an initial workflow, then discuss the evidence, integrations and evaluation a pilot would need.

Explore this workflow

Browse architecture concepts and decks

Let a solver plan routes. Let an agent explain the exceptions. | Stellitron