questions
Each of these is a reasonable idea and most operations have tried one. What it is good at, what it costs, and the question it leaves open.
It is free and it answers in seconds. It also cannot be wrong in any way you can detect, so you would be committing the capital on the strength of a confident sentence.
And if you point it at an ordinary simulation package and ask it to write the simulation instead, the same problem moves rather than goes away. That one has been measured: see “Why not have an AI write the simulation?” below.
Capacity divided by hours gives you the place on average, and averages never make you late. Pile-ups do, and late is expediting, overtime and penalties.
29% more work, five times the queue. Take one machine with work arriving unevenly from 70% busy to 90%, and the standard single-queue result, busy squared divided by one minus busy, goes from 1.63 jobs waiting to 8.10. A row of averages cannot show you that, and it is the difference between hitting your dates and missing them.
Your plant is not one queue but dozens feeding each other, with breakdowns, changeovers and shared crews. Some of that makes the curve steeper and some of it gentler, and which way yours goes is what the simulation is for.
It gets the most out of what you already own, this week. It cannot price the machine, the bay or the crew you do not have yet, so every capital question falls outside it.
A twin is a capital programme in its own right: instrumentation, integration, a data model, and a team to keep it current. It earns that back by telling you what is happening now.
The licence is the small number. The specialist, the months, and owning the model afterwards are the large one, and they recur with every question you ask.
Then it writes the physics as well as your process, and a mistake in the physics does not crash. It produces a confident, plausible, wrong number, which is the most expensive output a tool can give you.
Measured, and by people trying to make it work rather than to debunk it: SimLLM (arXiv 2601.06543) scored 600 AI-written queueing simulations and at best 76.8% got the mechanism right, while 86% ran cleanly.
One of the two failures they name is one we deliberately break our own engine with. They describe generated code that “does not always maintain a correct record of the remaining service time at the moment of interruption”, so a job that is interrupted quietly redoes work it had already done. Our test suite carries that exact defect as a planted mutation, and a release is refused if the tests fail to notice it. An independent benchmark naming a failure we already hunt for is the best evidence we have that the hunting is aimed at the right thing.
You run that experiment once, you pay for it either way, and the result lands months after the money is gone. Lost output during the trial is the real invoice.
A good one does exactly this analysis and does it well. You pay a fixed price for a fixed set of questions, and the answer ages as the business moves.
Two cases cost real money and look identical beforehand: the machine that was never the constraint, so the queue re-forms one station along, and the change that cost nothing and was never tried.
Built for decisions, not forecasts. It is at its strongest doing the thing the decision actually needs: putting two options side by side and telling you, with evidence, which one wins and by how much.
None of these are bad ideas. Every one is the right tool for some question, and every one stops at the same place: the operation that does not exist yet. That is the one this was built for.