There are two artificial intelligences in a factory
There are two artificial intelligences in a factory, and almost nobody tells them apart when they sign off a project. One gets bought with the other in mind, gets installed in the wrong place, and six months later the report says "the AI did not work". The AI was working. It was solving a problem on the wrong clock.
Sebastian J. Brau's blog
Enter your email and you will get an alert when something new is published. Unsubscribe anytime.
Short-cycle AI
It lives next to the machine. Its job is to look, decide and act in milliseconds or seconds: this tile has a pinhole, this label does not belong to this batch, this firing curve is drifting, this operator is reaching where he should not.
It does not reason. It reacts. And to react well it needs three things that rarely make it into the specification.
The first is that it cannot depend on the internet. If the decision to reject a part goes through a cloud, the day the connection drops the line stops or, worse, lets everything through. Short-cycle AI lives in a box at the foot of the machine and keeps working with the network cable unplugged.
The second is that it cannot have latency. A tile coming out of a kiln does not wait for someone to confirm it is good. At line speed, an extra two hundred milliseconds is a part that is already in the box.
The third is that it cannot ask for permission. It acts inside a margin someone has set for it, and that margin is the most important part of the design: what it may touch on its own, what it must flag, what it never does without a person present.
What short-cycle AI knows is what the best operator on the night shift knew. That knowledge exists in the plant, almost always in one or two heads, and the real project is getting it out of there without stopping the plant.
Long-cycle AI
It lives above the line. It does not look at a part, it looks at weeks: the full order book, the delivery calendar, twelve years of breakdown history, the gas bill of a kiln that cannot be switched off, who is actually available on each shift.
It can take two minutes to answer, and that is fine, because the decision it makes is worth far more than two minutes. Reordering next week's production, bringing a maintenance stop forward, deciding which product runs next to which so the kiln's thermal curve is not broken: these are decisions a person makes today with what is in front of them, and what is in front of them is almost never everything.
What long-cycle AI needs is context. Months of data, not seconds. And access to systems short-cycle AI must never touch: the ERP, the schedule, the costs.
The two ways they get confused
The first is asking long-cycle AI to catch a defect on the line. A powerful model is set up, connected to the cloud, fed the camera images, and the verdict comes back accurate and late. The defective part is already packed. The project closes with a 97 % accuracy report and a plant where nothing has changed.
The second is asking short-cycle AI to plan. A box goes in next to the line that sees very well what happens on that line and absolutely nothing of what happens outside it. It optimises today's shift and wrecks the week, because it does not know the order it just prioritised is not due for a month.
Both are the same mistake: the decision sat in one cycle and the intelligence was put in the other.
One shared memory
What makes the two work together is not that they talk to each other. It is that they share a memory.
Every short-cycle decision, every rejected part, every drift detected, every time an operator overrides an alarm, is a data point long-cycle AI needs to reason about next week. And every long-cycle decision, the sequence, the parameters for each product, the tolerance accepted on each order, comes down to the line as the margin inside which short-cycle AI is allowed to act alone.
Without that common memory you have two systems: one that sees a lot and decides little, and one that decides a lot and sees nothing.
In Marmaris, 1998, the system already had both parts before anyone had a name for them. The laser at the kiln exit reading the relief of every tile was the short cycle. The model that learned from the operators and moved the thermocouples half an hour before the defect appeared was the long cycle. And what held the two together was a memory built tile by tile, out of what the people who had spent years in front of that kiln already knew.
How to know which one you need
Start from the decision, not from the technology. Take one concrete problem in your plant and ask how long the decision has before it is no longer useful. If it is seconds, it is short cycle and it goes next to the machine. If it is days, it is long cycle and it goes above the line. If the answer is "both", congratulations: you have found the real project, and now you know the memory has to be designed before either of the two systems.