The first pattern I wrote about was an industrial company that wanted to use generative AI to control how its equipment stretched and printed on packaging material. A deterministic control problem handed to a probabilistic system. The version of that mistake I have run into most often since is less obviously mathematical, which is exactly why it survives longer. It is scheduling.
The setup is familiar in any field service operation. A few hundred technicians, a service territory, several hundred jobs a week, and a dispatch team building tomorrow's plan in a tool everyone agrees is fifteen years old. Someone proposes the obvious thing: the model is good at planning, we have all the data, let it build the schedule. A demo gets built in a fortnight, and it produces a day plan that looks entirely reasonable.
It looks reasonable because a language model is very good at producing something that resembles a schedule. Names, time slots, an order that reads sensibly. What it cannot do is guarantee that the plan is feasible, and feasibility is the entire content of the problem. Every job needs a technician who holds the right certification. Every customer has a window that was contractually agreed. Every van carries some parts and not others. Travel time between two sites is a fact rather than an opinion. Shift lengths, mandatory breaks, and overtime rules are written down in an employment agreement somewhere. A plan either satisfies all of that or it does not, and the difference is not visible by reading it.
That last point is what makes it expensive. A dispatcher can look at a plan covering two hundred jobs and see nothing wrong, because a violated constraint does not appear anywhere on the screen. The failure surfaces in the field the next morning, when a technician arrives without the qualification the asset requires, or without the part, or at a site whose access window closed an hour earlier. The cost lands as a wasted visit and a second truck roll, and it lands on a different team than the one that ran the pilot.
This class of problem has a mature answer that predates the current wave by about fifty years. Constraint solvers, the same family of tools behind vehicle routing, employee rostering, and job-shop scheduling, take the constraints as explicit declarations, distinguish the ones that cannot be broken from the ones that merely cost something, and search for the plan that minimises whatever you told them to care about. Two things come out of that which a language model does not provide. The plan is feasible by construction. And it carries a number, so tomorrow's plan can be compared with today's, and with the one a dispatcher would have built by hand.
There is a second benefit that has nothing to do with software. Writing the objective function forces an argument most service operations avoid having: what are we actually optimising for? Kilometres driven, technician utilisation, SLA penalties avoided, overtime, first-time fix rate. All of them matter, and they trade against each other. In a solver, the weights are written down and somebody signs off on them. In a spreadsheet-and-instinct process the weights exist too, but they live in the heads of three senior dispatchers, and they can change but are rarely documented.
None of this means there is no work for a language model in a field service operation. It means the model is not the scheduler. The fuzzy work sits on either side of the solver, and there is a lot of it.
Upstream is intake. Jobs do not arrive as structured constraints. They arrive as an email from a facilities manager saying the big compressor by the loading bay is making that noise again and can someone come before Friday, because the plant is shut the week after. Inside that sentence is an asset, a probable fault class, a skill requirement, a likely parts list, and a hard deadline. Turning it into fields is judgement work over incomplete information written by someone in a hurry, which is the thing language models are genuinely good at. Every job that arrives structured is a job a dispatcher does not have to interpret by hand, and a solver cannot schedule what nobody has described.
Downstream is explanation. A solver's output is not self-evident, and dispatchers override plans they do not understand. When the plan sends a technician past a nearer job to reach one forty kilometres away, somebody will want to know why, and "the objective function" is not an acceptable answer. A model that reads the solver's own reasoning, which constraint bound and what the alternative would have cost, and puts that in a sentence is doing interface work. It is also the difference between a plan that gets followed and one that has been edited into uselessness by the end of the morning.
The interface between the two is where this gets dangerous, and it is the problem I wrote about in Pattern 2. If a model extracts the constraints and gets one wrong, the solver will faithfully produce an optimal schedule against the wrong facts, and that schedule will be feasible, confident, and incorrect. So the extracted fields get checked against records the model did not produce: the asset register says what that compressor is, the contract says what the response window is, the parts system says what is on the van. The solver helps here as well, since a badly extracted constraint often shows up as an infeasibility or an implausibly expensive plan. Those are the cheap failures, because they announce themselves.
The test for telling the two kinds of work apart is easier than the architecture discussions it replaces. Try to write down what makes one answer better than another, as a formula with weights. If you can, and the terms are kilometres and hours and penalties and utilisation, you have an optimisation problem and it should be solved by something that optimises. If you cannot, because the answer depends on reading a situation somebody would have to explain in a paragraph, that is model work. Most real operations contain both, and the boundary between them is where the real action is.
This is rarely decided by the people who would get it right. "AI for scheduling" arrives as a mandate, and by the time it reaches an engineer, "AI" has quietly come to mean a language model, because that is what the word has meant in every board deck since ChatGPT arrived three years ago. A whole class of problems that operations research settled decades ago is now being pointed at a chatbot, and the teams doing the pointing are working from a vocabulary that does not distinguish between the two.