AI Route Optimization: What Is Actually Real in 2026

In the last two years every route optimization website acquired the same two letters. The word covers a dozen different things, some real capabilities and some a rebrand of math that predates smartphones.

A language model cannot plan routes, and the optimizer that can plan them cannot read your mind. The useful question is how the two of you split the work, and what each side is allowed to see and undo.

Five things "AI" means on a routing website

When a routing vendor says AI in 2026, they mean one of five things, in descending order of how often the claim survives a demo. Routing24 sells one of the five, so test every claim, ours included.

1. The solver, rebranded. The engine that assigns stops to vehicles and orders them is combinatorial optimization, built on decades of vehicle routing research: not machine learning, and not what most people mean by AI.

2. Machine learning around the edges. Predicted travel times by hour of day, learned service durations per stop type, arrival estimates tuned on history. Real machine learning, older than the current AI wave. Routing24 does not do this one. A tool that does should say what its predictions are trained on.

3. A language-model interface. A chat panel that turns "the pharmacy orders must arrive before 11 and chilled goods only go on the fridge van" into time windows and vehicle tags. New in the last three years, it attacks the most expensive part of routing software: getting the operation's rules out of the dispatcher's head and into the tool. This is the one we sell.

4. "The AI learns your routes." The claim that the system studies your drivers and plans like your best day, only better. At enterprise scale, learned preferences are a real research area. In small-fleet tools, press on it in a demo and it usually resolves to item 2, or to nothing.

5. Autonomous dispatch. An assistant can now trigger a dispatch that publishes routes to drivers and notifies customers. The confirmation step in front of it has not moved. Be suspicious of any vendor offering to remove it.

The part that changed: language in, structure out

One change is genuine: large language models are very good translators between how operators talk and how optimizers listen.

Every routing tool runs on structured fields: time windows, capacities, shift ends, tags, break rules, priorities. Every operation runs on sentences: "Marek cannot do the bakery run before six." A language model translates between the two well:

• Setup from plain English. "Two vans from the depot, drivers start at 7:00, the four pharmacy orders before 11:00, chilled only on the fridge van" becomes two vehicles, a shift, four time windows, and a tag pair, all visible and all yours to override.
• Data wrangling. A spreadsheet with addresses in three formats: a model converts it, reports the addresses the geocoder could not place and offers to repair them, and lists every row it had to guess about when you ask.
• Interrogating the finished plan. "Which routes finish after 16:00?", answered from the plan itself.

The part that did not change: the solver

A language model predicts text. It cannot search the space of a few hundred stops across a dozen vehicles. Ask a chatbot to sequence 40 stops and you get a list with no guarantee that a single time window holds.

So every honest "AI routing" architecture in 2026 is the same sandwich: AI at the edges, a real optimizer in the middle. The model captures the problem, the solver solves it, the model explains the solution, and every unserved stop has a stated reason.

How Routing24 is different

Several established route planners now publish a Model Context Protocol server, so the assistant you already use can call the planner directly. Most of those servers wrap the API the vendor already had: create, read, update, and delete orders, start planning, fetch the result. That is an integration, and a useful one, but the assistant on the other end can do only what the API did before: push data in, press Optimize, read routes out.

Routing24's 45 tools were built for the rest of the job, the part a dispatcher does between pressing Optimize and handing out the routes.

Creating the plan

From an email, a spreadsheet, or a description of the day, the assistant starts a new plan and writes the orders, vehicles, and depots. It geocodes every address and repairs the ones the geocoder could not place, turns the rules into constraints, and runs the optimizer.

Working on it with you, in turns

The plan the assistant edits is the one on your screen. It moves stops, splits and merges routes, swaps a vehicle, and re-sequences a route through the same edit engine as drag and drop, on the same undo history as your own changes.

After every edit it gets the comparison against the last full optimization and reports serious drift before doing anything else. When you change something by hand, a connected assistant's next edit is refused until it re-reads the plan, so it never writes over your work.

Analyzing conflicts and waste

Constraints interact: a time window, a shift end, and a break rule can each be satisfiable alone and impossible together. For every unserved stop the assistant gets the category, the blockers that stopped it, and the levers that would have to give, plus a quote for serving it anyway.

For the plan as a whole it queries eight live tables with SQL, runs scripted analysis on a draft, and compares full optimization runs: as it stands, with a third van, with the cutoff relaxed to 18:00. That is how it answers "why did these six drop", "what does the 16:30 cutoff cost me", and "route 3 looks light, what is it doing".

The session

All three depend on one piece of engineering. The optimizer runs in your browser, and when the solve finishes it does not exit: it stays open in the tab, holding the plan.

Every edit after that, yours by drag and drop or the assistant's by tool call, goes through that same session and is recalculated the moment it lands. ETAs, loads, distances, and the problems a move creates update at once, with no run restarted and no page reloaded. Re-optimizing is a separate, deliberate step, and re-sequencing one route is a single synchronous call.

The price of that design is the browser. The tools run inside the Routing24 tab you have open, so nothing runs unattended and the assistant works on the plan on your screen. A server-side wrapper on an API key can run overnight, and you cannot watch it.

Connecting your AI model

Connecting takes one URL. Ours is routing24.ai/mcp: add it as a custom connector in Claude or ChatGPT (developer mode, for ChatGPT) and approve it once on a Routing24 screen. There is no API key to paste. Trying it costs nothing: Routing24's free plan connects, Anthropic lists custom connectors on Claude's free plan, capped at one, and ChatGPT's developer mode is on its free plan. On Claude Team and Enterprise plans an owner adds the connector before members can enable it.

The same tools drive two assistants. The one built into the app opens from the header, spends an AI budget sized by your plan (a small demo quota on Free), and takes a file you attach. A connected Claude or ChatGPT spends your own subscription and also reaches your files, your mail, and your other systems.

What the assistant reads

The finding out only works if the assistant sees what you see. In Routing24 it reads the same things the screen shows:

• The refusals, with named causes. Why a stop went unserved comes back as a category, an explanation, the blockers that stopped it, and the levers that would have to give. Real failures are separated from alternatives that were not chosen.
• Insertion quotes. For an unserved stop, what it would cost to serve it after all.
• The cost comparison. Plan rollups, per-route statistics, and, after every edit, a comparison against the last full optimization. When the drift is serious the assistant reports it, leading with cost, and stops.
• SQL over the live plan, in both directions. Eight tables, from orders to the routing plan's own stops. Reads answer "how many afternoon stops breach their window". Writes update the writable columns and are validated first: a failure changes nothing, and everything that applies is one undo step.
• A sandbox for analysis. Scripted transforms run against a draft of the plan, and a run that writes nothing returns its findings.
• Its own audit log. Every tool call, with arguments, outcome, and the plan revision after it, readable by the next assistant that picks up the work.

Everything it does, on your screen, reversible

Whichever assistant is working, the plan on your screen is the one it edits:

• One undo history. A change the assistant made reverses exactly like one you made.
• A lock you can break. While a connected assistant edits, the app shows an Agent controlled overlay counting the changes so far, and a header badge names the client. Take control interrupts it at any moment.
• It can point at what it means. The assistant opens any page of the app and flies the map to the stop, depot, or address under discussion.
• You can overrule it and keep the receipt. Pin a placement by hand and the app badges it and reports what it violates, without moving it back.

The assistant built into the app adds a review layer:

• Bulk changes arrive as a review. A field change across many rows, an address repair, or a delete lists the rows before and after, and applies only when you confirm: "Apply 12 field changes to 8 sites?". A connected Claude or ChatGPT applies the same changes without that dialog, so set its write tools to ask for approval if you want the pause.
• Open questions come back as questions, asked in the pane, rather than the assistant picking for you.
• Revert to a point in the conversation. While the conversation is live, every transcript row that changed the plan carries a Revert here link back to the state before it. Edits you made by hand outside the assistant stay, and routes from a later optimization are not restored.

One boundary applies to both assistants. Tags, linked pickup and delivery, driver breaks, order sequences, and the other Pro constraints work in full during the 14-day trial every new account starts with. After it, on Free or Starter, the first five optimizations that use them apply them normally. From the sixth, an upgrade dialog appears, the optimization still runs without those rules, and the assistant is told which ones were dropped and says so instead of presenting the plan as complete.

Where the division breaks down

No unattended operation. Every call executes in your signed-in tab. Close the tab and the next call fails. A background tab in the same window as your chat sleeps too, so keep the app in its own window or in Chrome's split view. There is no headless mode, and system-to-system integration is a separate Pro arrangement, not a public endpoint you can sign up for.

One browser at a time serves the account. Approve the connection on your laptop and your desktop stops answering.

The assistant still cannot solve. It proposes, prices, and explains. Ask it to sequence the stops itself and a good one declines and runs the optimizer instead.

How to evaluate an "AI-powered" routing tool

Five questions, in the order that saves the most demo time:

1. What, specifically, does the AI do? Interface, travel-time prediction, or the solver itself? Only the first two are credible answers. Then ask what the interface can reach: an assistant that can only upload orders and press Optimize is an API with a chat window.
2. Can I see and override what it set? Every field the model fills should be visible and editable.
3. What happens to constraints it cannot honor? A named violation or an unassigned stop with a reason, never a silently bent rule. Ask this about tier limits too, not only impossible ones.
4. Can the assistant tell me why, and can I check it? Ask it why a stop went unserved, then find that answer in the interface. An explanation that exists only in the chat is prose, not a diagnostic.
5. What leaves my browser, and where does it go? Ask which model providers are involved, whose account they run on, and what exactly is sent.

FAQ

Is route optimization a form of AI?

Route optimization is operations research: algorithms that search enormous spaces of possible plans for a near-best one. Under the broadest definition of AI it qualifies, but it is not machine learning and it predates the current AI wave. What the wave added sits around the solver: language interfaces, data cleanup, and learned predictions.

Can I use ChatGPT or Claude to plan my routes?

Not on their own, because a language model cannot sequence stops reliably. You can connect them to a planner that can: Routing24 publishes a Model Context Protocol server at routing24.ai/mcp, which you add as a custom connector in Claude, or in ChatGPT with developer mode enabled. From then on the assistant operates the app in a tab you keep open, where you can watch it and take over, with tools to create the plan, edit it, and analyze it rather than only to upload orders and press Optimize. Every side of that has a free tier.

How do I check what the AI actually did to my plan?

Look for three things: a review you confirm before bulk changes are written, applied changes on the same undo history as your own edits, and a readable log of the assistant's actions. In Routing24 the built-in assistant gives you all three. A connected assistant gives you the undo history and the log, with the review step set in that assistant's own tool permissions.

Will AI replace dispatchers?

The translation layer of the job, retyping rules into forms and reading routes to answer questions, is disappearing. The judgment layer is not. Deciding which customer waits, when overtime is worth it, and whether the plan survives a specific Tuesday remains human work.

What happens to my data when an AI plans my routes?

In Routing24 the optimization itself runs in your browser. Addresses go to our servers for geocoding and travel times, and saved plans are stored in your account's data region. The assistant built into the app sends your message and the parts of the plan needed to answer it to the providers listed on the privacy page. An assistant you connect yourself runs on your own provider account under that provider's terms. Its calls reach us from that vendor's cloud rather than from your machine, and the work still happens in your tab.

What is the difference between AI route optimization and dynamic route optimization?

Dynamic, or live, re-optimization means recomputing routes mid-day when reality changes: a cancellation, a breakdown, a rush order. It is a solver capability and predates the AI wave. AI route optimization, as marketed in 2026, usually refers to the language and prediction layers around the solver. A tool can have either, both, or neither behind the label.

The takeaway

The solver was already good, the interface was already bad, and AI fixed the interface. What followed is a working division of labor: the solver decides the routes, you decide what matters, and the assistant does the finding out, in a tab where you can check every claim it makes. Whether an assistant can do that finding out is what separates a planner built for it from an API with a connector.

Judge any AI claim by where it sits in that arrangement. Ask to see the constraints, ask why something failed, and verify the answer in the interface. The fastest test is to describe your actual day, rules and exceptions included, and watch what ends up in the fields.