Can AI reduce dead mileage for bus and coach operators?

Yes, when AI drives an optimiser rather than writing schedules itself. Dead mileage comes from empty legs between jobs and depots. A solver working across every depot at once finds allocations and interworking that cut those legs, and AI agents keep the inputs and rules accurate.

Why not ask ChatGPT or Claude to build the rota?

A language model cannot guarantee that every job is covered, that every drivers' hours rule is met, or that no better plan exists. A constraint solver can. Language models are useful around the solver: reading booking notes, translating rules into constraints, explaining failures and proposing improvements.

What is the difference between an AI agent and an AI workflow?

In a workflow, models and tools follow steps defined in code. In an agent, the model decides its own next step. This build is mostly workflow on purpose: only rule translation and improvement proposals need a model's judgement.

What is an agent graph?

A way of wiring AI steps so the next step depends on the result of the last. Here, a duty that fails a rule check goes back to the constraint step with the reason, a solver bug stops the run for an engineer, and nothing reaches a driver until a planner signs off.

What is the difference between the network graph and the agent graph?

The network graph is the data: depots, stops, jobs, vehicles and drivers, and the travel and eligibility links between them. The agent graph is the workflow: which step runs next and under what condition.

Which drivers' hours rules does the agent apply?

Whichever applies to each job. Under GOV.UK guidance, coaches with more than eight passenger seats on private hire or tours follow the assimilated rules, and regular services on routes of 50km or less follow GB domestic rules. The constraint step classifies every job before solving, including days where one driver works under both.

What is a self-improving agent, and is it safe to let one change a schedule?

It is a system that proposes changes to its own rules or methods and keeps the ones that score better. It is only safe when the scoring is out of its hands. Here, every proposal is scored by replaying past weeks against the real rules, tested again on unseen weeks, and approved by a person before it goes live.

Does it replace the planner?

No. The planner approves every plan and every intraday change. The system removes the arithmetic and surfaces the choices.

AI driver and vehicle allocation: an open agent build

The Driver and Vehicle Allocation Agent is an open design for using AI to cut dead mileage and idle driver hours in bus and coach operations. Its core rule is that the AI never does the scheduling maths. A constraint solver plans; language model agents turn messy bookings and rulebooks into constraints, explain failures and propose improvements. A network graph models depots, jobs, vehicles and drivers, and an agent graph routes work on conditional edges. The system improves only against a replay of past weeks it cannot influence, and a planner signs off every plan.

What this is

A complete agent build for driver and vehicle allocation, given away. This page explains the architecture. The download is a build spec you can hand to your own developers, or to a coding agent, and start from.

Who it’s for: bus and coach operators, operations directors, planners and the teams that support them. It suits a single depot, and it pays most across a group with several.

The terms: free. No email gate. Use it, adapt it, build it in house.

One honest caveat: this is a design, not a product in a box. Your data, your rules and your planners decide whether it works. Allocation savings depend entirely on your network, so we don’t quote any. The 90-day test below is how you find your own number.

We build agents like this for a living. If you’re working through it and want a helping hand, or a second pair of eyes on your own version, get in touch with me directly.

Download the build spec (.md)

The problem, stated properly

Driver and vehicle allocation is two optimisation problems stacked together. Vehicle scheduling decides which coach covers which job, from which depot, meeting every time window. Crew scheduling decides which driver takes which duty within drivers’ hours, break and licence rules.

Dead mileage is empty running between jobs and depots. Unproductive hours are paid time with no passenger work. Both are outputs of the allocation, so both fall when the allocation improves.

The rules are harder than they look. Under GOV.UK guidance, a coach with more than eight passenger seats on private hire or a tour runs under the assimilated rules, the current name for the old EU rules: a 45 minute break after 4 hours 30 minutes of driving, and 9 hours of driving a day. A regular service on a route of 50km or less runs under GB domestic rules: a 30 minute break after 5 hours 30 minutes, 10 hours of driving, and a 16 hour spreadover. An operator mixing school contracts, private hire and local services can have one driver under both rule sets in one day. That mixed day is where manual planning breaks, and where a solver earns its keep. It is also where most generic scheduling demos go quiet.

A large language model is the wrong tool for that maths. It cannot guarantee a feasible schedule, and it cannot prove one plan beats another. A constraint solver can. So the design rule is simple: the solver plans, and the agents do everything a solver cannot. They read messy bookings, turn rulebooks into constraints, explain why a plan failed and propose how the system should get better.

Five steps, and which of them are AI

Anthropic’s guide to building effective agents draws a useful line. In a workflow, models and tools follow code paths you define. In an agent, the model directs its own steps. Most of this build is deliberately workflow. Only two steps need a model’s judgement, and calling the rest agents would oversell it.

The five steps of the Driver and Vehicle Allocation Agent, what runs each one, its job and its output.
Step	What runs it	Job	Output
Ingest	Code; a model only for free-text fields	Clean and join jobs, fleet, rosters, depots and maintenance holds	A validated snapshot and a data quality report
Constrain	Language model agent	Turn rulebooks, contract terms and booking notes into hard and soft constraints, each linked to the source text it came from	A constraint set with provenance
Solve	Constraint solver, no model	Build and solve the optimisation	Vehicle blocks, driver duties and the objective value
Check	Rule engine; a model writes the explanation	Re-test every duty against the rules from source, independently of the solver	Pass, or fail with a plain English reason
Learn and improve	Statistics, plus a model that proposes changes	Recalibrate journey times; propose changes to weights and heuristics, scored on replay	Corrected times and candidate improvements for sign-off

Provenance is what makes Constrain trustworthy. Recent research on language model agents for operations research, such as COOPA (2026), links every variable and constraint to quoted source text so a person can audit it. A planner who can click from a constraint to the contract clause behind it will trust the plan.

Check stays separate from Solve because a verifier that shares the solver’s code shares its bugs.

Graph one: the network

The network graph is the data model. Everything the solver needs to know about where things are, and what can do what, lives in it.

Nodes and edges of the network graph and what each carries.
Element	Type	What it carries
Depot	Node	Location, opening hours, fuelling and parking capacity, operator licence
Pickup or drop point	Node	Location, access limits such as low bridges or restricted streets
Job	Node	Time window, passenger count, vehicle spec, accessibility need, contract, drivers’ hours regime
Vehicle	Node	Seats, accessibility, home depot, availability, maintenance holds
Driver	Node	Licence category, home depot, hours already worked, rest due
Travel	Edge between places	Drive time by hour of day, distance, whether the leg runs empty
Eligibility	Edge from driver or vehicle to job	Can this driver drive this vehicle; does this vehicle fit this job

Dead mileage is the weight on the empty travel edges. Minimising it becomes a question the graph can answer, rather than a number a planner estimates.

The graph pays most across a group. When every depot sits in one graph, the solver can see interworking: a coach finishing near another depot takes that depot’s next job instead of running home empty. A planner looking at one depot’s board cannot see that move. Interworking only helps if it is legal, so every cross-depot move is checked against each company’s operator licence and operating centres, especially where depots in a group sit under different licences.

The graph can live in Postgres tables of nodes and edges, or in a dedicated graph database. Travel times come from a routing engine such as OSRM on OpenStreetMap data, then get corrected by the Learn step.

The solver formulation

The objective minimises empty running and paid idle time, with a heavy penalty on any job left uncovered so the solver never wins by dropping work.

Minimise: α × empty kilometres + β × paid idle hours + γ × uncovered jobs

The weights are set with the operator. α and β say whether a mile or a minute costs more in that business. γ is set high enough that covering a job always beats saving distance.

Hard constraints (never broken):

Every accepted job is met inside its time window
Seats and accessibility match the job
Licence category matches the vehicle
Drivers’ hours, breaks, rest and spreadover under the regime that applies to each job
Vehicles on a maintenance hold are excluded
Cross-depot moves stay within each company’s operator licence and operating centres

Soft constraints (penalised, not forbidden):

Drivers finish at their home depot
A minimum turnaround buffer between jobs
Driver preferences and route familiarity
Overtime spread evenly across the team

One simplification that matters for coach. On most coach work the driver stays with the vehicle all day, so the vehicle block is the driver’s duty. Put drivers’ hours directly on each vehicle’s route and solve once. Split into a separate driver pass only where drivers change over mid-block, as at bus relief points.

How it maps to Google OR-Tools: each vehicle gets its own start and end depot, which is how multi-depot is modelled. A time dimension carries the time windows, a capacity dimension the seats, and allowed-vehicle rules on each job the eligibility. Break intervals carry drivers’ hours. Optional jobs use disjunctions with a penalty, which is the γ term. Where a separate driver pass is needed, the OR-Tools CP-SAT solver handles the matching. For an intraday re-plan, the solver starts from the current plan, not from scratch, under a time limit.

Graph two: the agents

The agent graph is the workflow. Steps are nodes; edges say what runs next, and conditional edges choose the route from the result. A straight pipeline plans once and fails on the first exception. A graph routes each failure to the step that can fix it.

Conditional edges in the agent graph: the condition, where the run goes next and why.
From	Condition	Goes to	Why
Ingest	Data quality check fails	Human review; the run stops	No plan is built on guessed data
Solve	No feasible plan	Check, then the planner	Check names the blocking rule; the planner relaxes a soft rule or declines a job
Check	A rule was missed or mistranslated	Constrain, with the reason	Constrain can fix the constraint
Check	The rule was encoded correctly but still broken	Engineer alert; the run stops	It is a bug in the model code; the planner never sees it
Check	Every duty passes	Planner sign-off	Nothing reaches a driver without it
Planner	Plan approved	Issue, then Learn	Actuals feed back into journey times
Planner	Change rejected	Logged as a candidate soft constraint	Rejections become data for the improvement loop

Shared state, meaning the snapshot, the constraint set, the candidate plan and every check result, travels with the run, so every step is auditable. Start with the simplest build that works, as Anthropic advises: a short script or an n8n workflow with branches. Move to a stateful graph framework only when the routing outgrows it.

The three loops

The same agent graph runs on three clocks. What changes between them is the scope of the problem and how fast an answer is needed.

The three operating loops: when each runs, its scope and what it produces.
Loop	When it runs	Scope	What it produces
Plan	Overnight, for the next day or week	Every job, vehicle and driver	The baseline plan for planner sign-off
Re-plan	Intraday, on a breakdown, a sick call or a late-running job	Only the duties the event touches; the rest of the day is frozen	A minimal change with the reason attached
Learn	After each day closes	Plan against actual	Corrected journey times by hour and route, rule exceptions to review

The re-plan loop is where most of the operational value sits. Freezing untouched duties keeps the change small. Drivers on the road aren’t reshuffled to save a mile, and the planner reviews a handful of changes, not a new day.

The Learn loop closes the system. Planned journey times start from a routing engine, which knows roads but not your school-run traffic at 08:15. Each day’s telematics and tachograph data corrects them, so tomorrow’s plan starts closer to what will actually happen.

How it improves without marking its own homework

Self-improving AI is one of the most oversold ideas in the field. The research is clear on one point: a loop that grades its own work drifts. A 2026 survey of 1,250 papers ranks evaluation signals from formal verifiers, the strongest, down to a system’s own self-assessment, the weakest, and finds that real self-improvement tracks that ranking.

Allocation has a formal verifier built in: the rules and the solver. So the improvement loop can be honest.

One of the clearest public examples is Google DeepMind’s AlphaEvolve. It proposed changes to a scheduling heuristic for Google’s Borg cluster manager and scored each one with automated evaluators. The winning heuristic has run in production for over a year and recovers, on average, 0.7% of Google’s worldwide compute. DeepMind also points out that the result was human-readable code, which made it easier to debug and deploy.

Applied to allocation, the loop runs like this:

Propose. A model suggests a change: objective weights, a re-plan rule, how the solver searches, or a new soft constraint drawn from planner rejections.
Replay. Each candidate re-plans a library of past weeks it had no part in. The rules and the actual outcomes do the scoring, not the model.
Hold out. A candidate that wins is tested again on weeks it has never seen.
Promote. Only then does it reach the planner and operations lead, as a readable change with before and after figures. They approve or reject it, and every rejection is logged as data.

The proposer never touches the evaluator. That separation is the whole design, and it is the question worth asking any vendor who sells you a self-learning system: who marks its homework?

Guardrails, failure modes and the fallback

The planner approves every plan. The system proposes; a person with authority commits. Nothing reaches a driver without that sign-off.

Failure modes of the allocation agent, how you would know, and what happens.
Failure	How you’d know	What happens
Bad or missing input data	The data quality report flags it before solving	The run stops and routes to a human
No feasible plan exists	The solver returns infeasible	Check names the blocking rule; the planner relaxes a soft rule or declines a job
A plan breaks a rule	Check fails the duty	A missed rule goes back to Constrain; a correctly encoded rule that still breaks stops the run for an engineer
Re-plan can’t finish in time	The loop hits its time limit	The planner gets the best feasible partial fix and the manual board stays live
Journey times drift from reality	Learn’s variance report trends upward	Times are recalibrated; persistent outliers are flagged for review
An improvement games its own test	It wins on replay but loses on held-out weeks	It is never promoted
The system is down	The health check fails	The planner works the board as today; the agent is an addition, never the only route

Driver data is personal data. Build it with access control, an audit log on every plan change, and a clear retention policy. Use anonymised data for any proof of concept.

The 90-day test

Don’t start with a live rollout. Start with history, then shadow, then decide.

Weeks 1 to 4, replay. Take a past week of real jobs, vehicles and drivers. Run the Plan loop and compare its plan against what you actually ran: empty kilometres, paid idle hours, and duties that would have broken a rule.
Weeks 5 to 10, shadow. Run the Plan loop every night alongside your planners. They plan as normal and review the agent’s version. Log every case where they rejected a proposed change, and why. Those reasons become new constraints.
Weeks 11 to 13, decide. Compare shadow plans against actuals.

Measure four things: empty kilometres per operated kilometre, paid idle hours per duty, rule breaches caught by Check, and the share of agent proposals planners accepted. The last one matters most. A plan planners won’t use saves nothing.

The replay library from weeks 1 to 4 does a second job. It becomes the fixed evaluator for the improvement loop, so it is worth building carefully once. It is also exactly where we would start with you.

The build spec

The full spec is in the download. Hand it to your developers or a coding agent as the starting brief.

Want a second pair of eyes?

Every operator’s network, rules and data are different, so the right first step is different too. We’re happy to offer a free review for a specific operator. That could be a look at how you allocate today, a first pass over a sample of your data, or a sketch of how this design would fit your depots and rules.

If it turns into something bigger, The Practice can design and build it with you, with your data, your rules and your planners in charge.

If that’s worth 30 minutes, let’s get it in the diary.

Benjamin Ross. Practical application of AI in public transport. Founder, economAIcs. Benjamin Ross is the founder of economAIcs, the company behind YourTransportBrain.

The Driver and Vehicle Allocation Agent