Skip to content
StrataHub

Manufacturing · February 23, 2026 · 6 min read

AI Scheduling for High-Mix Low-Volume Manufacturing

High-mix low-volume shops are where naive scheduling AI goes to die. What actually works: constraint solvers for the core, ML for the inputs, and agents at the edges.

High-mix low-volume (HMLV) manufacturing is the hardest scheduling environment there is. Hundreds of active part numbers, lot sizes from one to fifty, shared machines with sequence-dependent setups, tooling constraints, operator certifications, and a customer who just called to expedite an order that touches four work centers.

Most shops in this world still schedule on a spreadsheet maintained by one person who has been there fifteen years. That person is brilliant and irreplaceable — which is exactly the problem.

We have built scheduling systems for HMLV job shops and machine shops, and the biggest lesson is architectural: this is not one AI problem. It is three different problems that need three different tools.

Problem 1: The core schedule is optimization, not ML

The temptation is to point a learning model at historical schedules and have it imitate the planner. Resist it. The planner's history encodes yesterday's constraints, not today's, and imitation learning cannot explain why job B goes before job A — which matters the moment someone challenges the schedule.

The core sequencing problem is combinatorial optimization, and the right tool is a constraint programming or MILP solver (CP-SAT has been our workhorse). Solvers give you three things ML does not:

  • Hard constraint guarantees. A certified-operator requirement or a tooling conflict is never violated, full stop.
  • Explainability by construction. The schedule is the output of explicit objectives — minimize tardiness, minimize setup time, respect priorities — with tunable weights the shop controls.
  • Fast, deterministic re-solves. When a machine goes down at 6 a.m., you re-solve in seconds against the new reality, rather than hoping a model generalizes to a state it never saw.

On one 40-machine shop, moving from manual sequencing to a solver-based schedule cut sequence-dependent setup time by roughly 20% and improved on-time delivery from the low 80s to the mid 90s percent. No neural networks were involved in that layer.

Problem 2: The solver is only as good as its inputs — and that is where ML earns its keep

A solver fed with fantasy processing times produces fantasy schedules. In every HMLV shop we have entered, routing standards were wrong in predictable ways: setup times set a decade ago, run times that ignore operator differences, and "standard" times for parts that have never been run twice the same way.

This is the ML problem. We train regression models to predict actual processing and setup times from job features — part family, material, machine, operator, batch size, time since last run of that family — using shop-floor execution data from the MES. Even modest models routinely beat the routing standards by 25–40% on mean absolute error. Those predictions, with uncertainty bands, feed the solver, which schedules buffer time where prediction variance is high instead of padding everything uniformly.

Data quality check before anything else: if operators clock jobs in batches at the end of a shift, your timestamps are fiction. Fixing MES capture discipline is often week one of the engagement, and it pays for itself regardless of what AI comes later.

The same applies to demand. Quoted lead times, expedite probability by customer, and scrap rates by part family are all learnable, all uncertain, and all better handled as probabilistic inputs than as constants.

Problem 3: The edges are where agents help

There is a third layer that is neither optimization nor prediction: the constant conversational churn around the schedule. Can we pull order 4471 in a week? What happens if the Mazak is down until Thursday? Which jobs are at risk if the titanium shipment slips?

Historically, only the veteran planner could answer these, because answering requires querying the schedule, the MES, and the ERP simultaneously and reasoning over the results. This is where we deploy an agentic layer: an assistant with tool access to the solver (for what-if re-solves), the schedule database, and order data. A planner asks the question in plain language; the agent runs the counterfactual re-solve and reports the delta — which orders slip, by how much, and what it costs.

The agent never publishes a schedule. It proposes; the planner disposes. That boundary keeps the failure modes contained and the trust intact.

What we measure in production

Production-or-nothing means agreeing on the scoreboard before go-live. For HMLV scheduling we track:

  • On-time delivery percentage, weekly, against the pre-deployment baseline.
  • Schedule stability — how much of tomorrow's plan survives to execution. A schedule that reshuffles hourly is technically optimal and practically useless.
  • Planner override rate. Early on, planners override often; if the rate is not falling month over month, the model of the shop is wrong somewhere and we go find it.
  • Time-prediction accuracy drift, monitored continuously, because new parts and new operators shift the distribution constantly.

Sequencing the engagement

A realistic path, mapped to how we work: a 4–6 week pilot that connects to the ERP/MES, audits data quality, and produces a shadow schedule for one cell or work-center group, scored against what the shop actually ran. Then a co-build phase to expand coverage, integrate the prediction models, and put the what-if agent in planners' hands. The veteran planner is not replaced at any point — they are promoted from human solver to system owner, and their exceptions become the most valuable training signal in the building.

HMLV scheduling rewards the boring virtues: honest data, explicit constraints, measured trust. The shops that get this working do not just ship on time more often. They quote with confidence, because for the first time, they know what their capacity actually is.

Work with us

Shipping something like this?

We co-build production AI systems with enterprise teams — pilots in 4-6 weeks.