Introduction The headline framing — “AI is replacing operations research” — gets the relationship backwards. In the production stacks we actually see in retail, logistics, and manufacturing, AI is not displacing the optimisation core. It is feeding it. Machine learning produces sharper demand forecasts, anomaly signals, and parameter estimates; operations research (OR) takes those inputs and makes constrained, auditable decisions about routing, inventory, pricing, and labour. This pairing is where the deployable-now ROI sits. Retailers worrying about shrinkage, planogram compliance, and traffic-to-conversion analytics live in exactly this world: a forecasting layer feeding a constrained decision layer, with humans on the override path. The naive failure mode — selecting a model for a use case without first quantifying the business value of the information the model produces — applies just as much to operations research deployments as it does to computer vision ones. AI and operations research: what each side actually contributes Operations research is a mathematical discipline. Linear programming, integer programming, mixed-integer solvers, queuing models, stochastic optimisation — these methods produce provably optimal or bounded-optimal solutions under stated constraints. Crucially, they come with guarantees: feasibility, bounds, dual prices. Pure machine-learning policies do not. AI contributes where OR has historically been weakest: the inputs. Demand forecasts, lead-time distributions, defect-rate estimates, customer-segment behaviour, sensor-derived equipment-health signals. Classical OR used to take these as fixed parameters supplied by an analyst. With learned models in the loop, the parameters update as new data arrives, and the optimiser re-runs against fresher inputs. The division of labour is consistent across the credible production stacks we see in 2026: gradient-boosted or transformer models for demand prediction, then a Gurobi, CPLEX, or OR-Tools solver for the constrained decision, and increasingly a reinforcement-learning component handling rolling re-optimisation between full solves. The OR core does not go away. It gets better inputs. What is the actual production pattern? Three categories dominate the deployments that survive a year past launch: Large-fleet logistics — route planning, last-mile dispatch, container repositioning. ML forecasts demand and travel times; OR solves the vehicle routing problem under capacity and time-window constraints. Inventory and replenishment — omnichannel retail and CPG. ML forecasts SKU-level demand; OR sets reorder points, safety stocks, and allocations under service-level and budget constraints. Workforce scheduling — airlines, hospitals, contact centres. ML forecasts call volume, patient flow, or absenteeism; OR produces shift schedules under regulatory and skill-mix constraints. The cases that fail tend to share a structural mistake: they treat the AI model’s output as a decision, rather than as an input to a decision. Where this connects to retail computer vision For retail specifically, the same AI-plus-OR pattern is what makes computer vision payback measurable. A shelf-monitoring camera is not the deployment — it is a sensor whose output becomes an input to an inventory and replenishment optimiser. A loss-prevention model is not the deployment — it is a classifier whose outputs feed staffing and intervention policies. We develop this framing in depth in our Computer Vision R&D practice and in the parent piece on what ROI computer vision actually delivers in retail. The discipline matters: quantify the business value of the information first, then choose the model that produces that information at acceptable cost. The hybrid stack: where each component lives Layer Component Role Typical tooling Ingest Data pipeline Sensor, transactional, and external signals Kafka, Spark, dbt Forecast ML models Demand, lead time, defect rate, anomaly score XGBoost, LightGBM, transformer models in PyTorch Decision OR solver Constrained optimisation under business rules Gurobi, CPLEX, OR-Tools, Pyomo Adaptation RL / re-solve loop Rolling re-optimisation between full solves Ray RLlib, custom policies Override Human workflow Boundary-case approval, exception handling Workflow tooling, dashboards Each layer fails in a recognisably different way, which matters for monitoring. ML failures look like silent drift in the input distribution. OR failures look like infeasibility, unbounded solutions, or solutions that violate unstated business rules. RL failures look like over-confidence on out-of-distribution events. These need different alarms. Applications in the retail and adjacent supply chain Retail and its upstream supply chain are where this pattern compounds most visibly. Demand forecasting and replenishment. ML models ingest point-of-sale data, weather signals, promotional calendars, and macro indicators. They produce SKU-store-day forecasts — ideally distributional, not just point estimates. The OR layer then solves the multi-echelon inventory problem: where to hold safety stock, when to trigger replenishment, how to allocate constrained inbound capacity. The combined system reduces holding cost and stockout rate simultaneously, not one at the expense of the other. Last-mile and store-delivery routing. AI estimates time-of-day-dependent travel times and service durations. The OR layer solves a vehicle routing problem with time windows, driver-hour limits, and vehicle-capacity constraints. Re-optimisation happens on a rolling horizon as the day progresses. Loss prevention and intervention staffing. A computer-vision model in store flags potential shrinkage events. The OR layer schedules security and prevention staff so that response capacity is positioned where the expected event rate is highest — not where the historical average says it was last quarter. These are not speculative. They are the deployments behind the credible ROI numbers, and they are the ones that survive scrutiny in our retail computer-vision engagements. Predictive maintenance, dynamic pricing, and workforce planning The same pattern recurs across adjacent operational domains. Predictive maintenance. Sensor-fed ML models classify equipment health and forecast failure windows. The OR layer schedules maintenance windows, parts procurement, and labour against production constraints. The cost saving comes not from the prediction itself but from the optimised response to the prediction. Dynamic pricing. ML models estimate demand response by segment, time, and channel. The OR layer solves for prices that maximise revenue (or margin, or some weighted combination) subject to margin floors, inventory caps, and contractual obligations. Real-time price adjustments work when the OR layer respects the business rules; they fail when the model is allowed to set prices directly. Workforce planning. ML models forecast absenteeism, skill availability, and demand by skill type. The OR layer produces schedules that satisfy regulatory constraints (rest periods, certifications, union rules) while meeting service-level targets. The schedule is the deployment, not the forecast. In every case, the prescriptive layer is OR. The forecasting layer is AI. Mixing them up — letting the forecast act, or letting the optimiser run on stale parameters — is the common failure mode. Where AI-plus-OR deployments fail Four failure modes account for most of what we see go wrong: Forecast-optimisation mismatch. The OR model is built to consume distributions (means and variances, or scenario sets), but the ML team delivers point forecasts. The optimiser then makes confident decisions based on a single number, when it should have been hedging against the spread. Silent input drift. The ML model continues to produce outputs that look reasonable, but the underlying data distribution has shifted. The optimiser, which has no way to know, produces confidently wrong answers. Monitoring on inputs — not just on optimiser outputs — catches this earlier. Over-fitted RL policies. Reinforcement-learning components trained on historical disruptions over-fit to those specific patterns. The first genuinely novel disruption — a new port closure, a regulation change, a competitor exit — produces nonsense actions. Override friction. The system produces a recommendation. A human can see it is wrong, but the workflow does not make overriding easy, so the wrong action runs. Or the opposite: humans override correct recommendations because they cannot see why the solver chose them. The fix is not more AI. It is distributional forecasts where the solver supports them, input-side monitoring, RL retraining on broader distributions, and explicit override workflows with audit trails. Challenges and mitigations Hybrid systems need clean data. Poor training data harms both prediction and optimisation. The alignment between ML outputs and OR-model inputs has to be designed explicitly — the data scientists and the operations researchers cannot work in separate sprints. We see the strongest results when one person owns the contract between the two layers. Model monitoring in production has to cover both sides: drift detection on the ML inputs, feasibility and constraint-violation monitoring on the OR outputs. Cloud-side controls — encryption, audit logs, access controls on the optimiser inputs — protect against tampering and accidental contamination. Domain rules have to be encoded as hard constraints, not learned preferences. An RL policy that “usually” respects a regulatory limit is not acceptable in pharmaceutical logistics or aviation crew scheduling. This is exactly why the OR layer remains the decision authority. Benefits of the combined approach Faster, mathematically grounded decisions under real-time conditions Lower total cost across supply chain, inventory, and operations Continuous improvement through feedback into both the forecasting and the optimisation layers Scalability across geographies and product lines Higher forecast accuracy where it matters: at the level the optimiser consumes Reduced waste in inventory, routing, and staffing decisions Auditable decisions, because the OR layer produces solutions with traceable constraint satisfaction For the broader engineering thread on where this slots into our work, see our Computer Vision R&D practice and the parent article on what ROI computer vision actually delivers in retail. How TechnoLynx can help We design and deliver hybrid AI-plus-OR systems for clients in retail, supply chain, logistics, and manufacturing. We build the data pipelines, train the forecasting models, integrate the optimisation engines, and design the override workflows. We are explicit about which layer owns which decision, and we instrument both sides so drift and infeasibility surface early rather than late. The work tends to start with a hard look at the business question first: what decision are we trying to make better, and what is the information value of getting it right? Then we choose the models — not the other way around. FAQ How do AI and operations research work together in data analytics? Operations research provides the mathematical optimisation backbone (linear and integer programming, queuing models, mixed-integer solvers, stochastic optimisation); AI provides the demand forecasts, anomaly signals, and learned policies that feed those solvers. A typical 2026 hybrid stack uses gradient-boosted or transformer models for demand prediction, then passes those predictions as inputs to a Gurobi or OR-Tools optimiser, and increasingly uses reinforcement learning for rolling re-optimisation as new signals arrive. Where is AI-augmented operations research actually deployed in production? Three categories dominate the credible production footprint: large-fleet logistics (route planning, last-mile dispatch, container repositioning); inventory and replenishment for omnichannel retail and CPG; and workforce scheduling for airlines, hospitals, and contact centres. The pattern is consistent: the AI piece improves the input quality of forecasts, the OR piece does the constrained decision-making, and humans approve or override the boundary cases. Can AI replace classical operations research? No, and the framing is wrong. Classical OR methods produce provably optimal or bounded-optimal solutions under stated constraints, with guarantees that pure ML methods do not provide. AI replaces some hand-tuned heuristics and improves the inputs (forecasts, parameter estimates), but the optimisation core remains classical. End-to-end neural decision policies exist in research and a few narrow production niches, but they have not displaced the OR core for high-stakes operational decisions. What goes wrong with AI-plus-OR deployments? Four recurring failure modes: forecast-optimisation mismatch (the optimiser is fed point forecasts when it needs distributions); silent drift in the ML inputs causing the optimiser to confidently produce wrong answers; over-fitted RL policies that fail on out-of-distribution disruptions; and organisational reluctance to override the optimiser when humans see something it does not. The fix is monitoring on the inputs (not just the outputs), distributional forecasts where the solver supports them, and explicit override workflows.
