AI on the factory floor

As AI starts making calls on the shop floor, what actually changes about MES? It stops being the thing that decides, and becomes the thing that records who was allowed to. A model output is advisory until something grants it authority. The published guidance splits that authority into three tiers. Advise: a human approves before any system action executes. Approve: the agent acts inside defined parameters and logs every decision for review. Execute: autonomous action within thresholds somebody set in advance. Each tier needs its own limit, audit log and escalation path - picked before deployment, not after the first disputed call. This lands on MES because MES already holds the pieces: the state model, the hold and disposition path, genealogy, the electronic signature. Gartner projects at least 15% of day-to-day work decisions made autonomously by 2028, up from none in 2024. Separately, it expects over 40% of agentic AI projects to be cancelled by the end of 2027 - attributed to cost, unclear business value and inadequate risk controls. To be fair, both of those are projections rather than measurements, and the cancellation figure is about governance and economics rather than the technology failing. What I keep coming back to is that those two numbers point the same way. The deployments that survive will be the ones that can answer who decided, under what limit, and on what evidence. That is an MES question, and it always was. Has anyone actually written decision rights into an MES workflow for an AI recommendation - or is it still a person quietly deciding whether to trust it?

If virtual metrology gives every wafer a measurement, can you stop measuring so many wafers? That is exactly the trap. Virtual metrology is inference, and its anchor is the sampling you were about to cut. Metrology is a tool, a queue and a cycle-time cost, so fabs measure a sample - scheduled audit sampling typically sits somewhere in the 1-5% range. Virtual metrology closes the gap by predicting the measurement from the process trace the tool already produces. Every wafer carries an inferred value. Cross-step models, which use upstream context rather than one step in isolation, report around 37% lower RMSE than single-step models, and hybrid physics-plus-ML is becoming the default build rather than a research curiosity. But every VM prediction is calibrated against real metrology. The sampling is not overhead the model removes. It is the reference the model depends on. Cut sampling because VM is working, and you have removed the only signal that would tell you it has stopped working. To be fair, the 37% figure is a single reported comparison rather than a fab-wide result, and RMSE measured against sampled metrology is not the same thing as accuracy against truth. What I keep coming back to is how quiet that failure is. A drifting VM model does not go blank or throw an error. It keeps producing a confident number for every wafer, and it produces it faster than anyone can check it. Has anyone actually reduced metrology sampling on the strength of a VM model - and how did you decide where the floor was?

Should a language model be allowed to draft a process flow? Draft, yes. Approve, never - because fluent and feasible are different properties, and only one of them is being checked. Reading the published work, the failure mode is consistent. These models reason over fab operations with real fluency. They will draft a flow and suggest an integration sequence that reads exactly like something an engineer wrote. Then the specifics fall over. Steps the installed toolset cannot execute. Sequences that violate thermal budget or contamination constraints. Parameters sitting outside the qualified process window. Nothing in the generation checks any of that. Plausibility and feasibility are simply not the same computation. The fix in the literature is to couple the model to a process-rule and process-window checker that filters its output inside the loop, not in a review meeting afterwards. The model supplies the search heuristic; the constraint supplies hard feasibility. On general planning benchmarks, success under hard constraints rises from 27.7% to 49.2% once feasibility is prioritised. To be fair, those two rates come from general LLM planning benchmarks rather than fab process flows - no public benchmark yet measures how often an unconstrained model produces an infeasible semiconductor flow. Read them as the shape of the problem, not as a number for your fab. And 49.2% is the honest part of that story. It is better. It is nowhere near release quality. Has anyone actually put a hard process-window check between a generative tool and anything that reaches an operator?

If you can predict the failure, have you solved maintenance? Not yet. Predicting it is the easy half. A prediction has to land inside a window. Too early and you throw away good remaining life on a part that was fine — a maintenance saving converted into a maintenance cost. Too late and it is not predictive maintenance at all, it is an unscheduled down that may have taken a lot with it. The width of that window is set by things the model cannot see: whether the spare is on site, whether the crew is free, and whether there is a slot where taking that tool down does not simply move the queue somewhere worse. The published ranges are worth holding onto. McKinsey puts predictive maintenance at up to 50% less equipment downtime and 10–40% lower maintenance cost. For semiconductors specifically, when it is applied to a bottleneck, roughly 70–80% of the improvement converts into overall fab effectiveness. To be fair: the McKinsey ranges are cross-industry, and the case studies quoting 70%+ downtime reductions are vendor-published. Directional, all of them. What I keep coming back to is that last figure being conditional. On a bottleneck, most of the gain reaches the fab. Off the bottleneck, a perfect prediction on a tool that was never the constraint buys a tidier maintenance calendar and very little else. Programmes get scoped by which tools have good sensor data, when they should be scoped by which tools are constraints. For anyone who has run PdM in a fab: which way did you scope it, and did you get to redo it?

If a recipe never changes, why does the process drift? Because the recipe is the only thing holding still. The equipment moves underneath it. Chambers season run after run. Consumables wear. Electrodes erode. Ambient conditions shift. Nobody changed a parameter, and yet the tool you qualified has slowly become a different tool. Run-to-run control is the answer, and it is almost embarrassingly simple in concept: measure the run that just finished, adjust the run that has not started. Usually through an EWMA filter, so it responds to a trend rather than chasing the last noisy measurement. The published results are worth knowing because they are specific rather than promotional. An APC system on poly-gate critical dimension took photolithography rework from 12% to 2%. A run-to-run controller on Si trench etch depth moved Cp/Cpk from 1.10/0.83 to 1.39/1.34. An EWMA controller on metal sputter deposition improved process capability by about 10%. To be fair: three separate deployments, each one process on one toolset, published by the people who did them. Examples, not an industry average. What I keep coming back to is that control does not remove variation — it stops variation accumulating. An uncontrolled process does not wander randomly around target. It walks, and every run inherits the last run's error. For anyone running R2R: what actually broke it for you? From what I have read, metrology delay seems to matter more than the controller.

How much of an AI dispatching result actually survives contact with a real fab? Reading through the published work, the honest answer looks like: not much. On the public benchmarks — Minifab, SMT2020 — reinforcement learning earns double-digit improvements in tardiness. Run the same class of method against a real industry fab dataset and it lands at up to 4% on tardiness, and up to 1% on throughput. The more I read about it, the less I think that gap is about the algorithm. A real fab is re-entrant. Hundreds of tools, qualification constraints, linked queue-time windows, hot lots reordering everything behind them. The benchmark models a fraction of that, so the policy that won it learned a much smaller world. To be fair: that is one 2025 study, one dataset, one set of objectives. A 2025 review of RL dispatching also finds the literature thin on validation and deployment guidance for real facilities. What I keep coming back to is that 4% on a real fab is not a failure. It might be a very good year. The failure is budgeting for the benchmark number and then calling a genuine 4% disappointing. Has anyone here taken an ML dispatcher past simulation and into a live dispatch path? I would like to know what the number looked like on the floor.

If a model can predict something in the fab accurately, should it also be the thing that decides it? Accuracy is the wrong test. The question is what happens when the model is wrong. Some fab decisions are cheap to undo. Dispatch ranking, maintenance ordering, a virtual metrology estimate between two real measurements - get one wrong and the next cycle corrects you. That is where a model earns its keep. Others are the record itself. A safety interlock has to reach a safe state on a single foreseeable fault - SEMI S2 asks it to be fault-tolerant, not usually right. Genealogy is what an audit and a recall containment get reconstructed from years later. Recipe release has to be reproducible by someone who was not in the room. And a model's output is a probability conditioned on its training data. Retrain it and you can no longer re-derive the answer it gave last March. Fine for a suggestion. Not fine for a system of record. The numbers: between 5% and 33% of AI initiatives reach real production value - 5% is MIT NANDA counting measurable P&L impact, about 33% is McKinsey counting anything past the pilot. Gartner expects over 40% of agentic AI projects cancelled by end-2027. To be fair, those are three different measures of three different things and none is fab-specific. SEMI S2 governs equipment safety, not MES software. The argument is from what these functions require, not from a standard saying no ML here - because none does. What I keep coming back to is that most failed industrial AI projects did not fail on model quality. They failed because a model got pointed at a decision that needed an audit trail. Has anyone actually got a model into a disposition or release path and kept it auditable - and how did you handle the retrain problem?