Short answer: the order matters more than the technology. First, fix the data foundations: stop codes people trust, the historian, MES, CMMS and LIMS joined, and one agreed definition of OEE. Second, pick one pilot by the value of the loss, on the lowest rung of AI that can solve it. On an illustrative line making 300,000 bottles a shift, one point of OEE is 3,000 bottles a shift and about 2.7 million a year on three shifts. Third, measure against a baseline in physical units before anyone converts it to money. Fourth, add generative AI for the text of the plant and agents that draft, not act. And treat AGI as news to follow, not a reason to wait.

A ROADMAP THAT STARTS WITH DATA AND ENDS WITH AGENTS (ILLUSTRATIVE TIMING) 1. Foundations months 0 to 3 stop codes people trust MES, historian, CMMS joined one OEE definition 2. Classic AI pilot months 3 to 6 chosen by loss value predictive maintenance or anomaly detection on SPC 3. GenAI for text months 6 to 9 shift handovers SOP answers with citations root-cause support 4. Agent at L2 months 9 to 12 drafts work orders drafts changeover plans a person approves ALL THE WAY THROUGH: MEASURE AGAINST A BASELINE · BRING THE FLOOR WITH YOU AGI is not a phase on this roadmap · everything here works without it
Illustrative timing for one site. The order is the point: each phase stands on the one before.

I have seen more plant AI projects stall than fail. They rarely die from a bad model. They die in month four, when the team discovers the stop codes are unusable, the maintenance system uses different asset names from the MES, and nobody agrees what counts as planned downtime. The model sits finished, waiting for data that was never going to arrive on its own.

This is the last post in AI for Operational Excellence in Beverage Plants. The first seven built the vocabulary: the AI ladder, LLMs, agents, OEE, classic AI, generative AI and agentic AI on the floor. This one puts them in order.

Phase 1: data foundations first

Nothing later in the roadmap works without these, so they go first, even though they are the least exciting to present to a board:

  • Stop codes people trust. Automatic stop detection from the PLC, plus a short list of reasons that map to the six big losses. Test it with the operators, not just the engineers.
  • Joined systems. The MES, historian, CMMS and LIMS linked on common keys: the same asset IDs, the same batch or order numbers, the same clock. This is usually the biggest job on the list.
  • One definition of OEE. What counts as planned time, what the ideal rate is for each product and format, written down and published.
  • A place for the data. A lakehouse or warehouse on the IT side, fed from a DMZ replica, where the data model can be built without touching the control network.

It is the same lesson as the winery data work in the Cellar Ledger: the definitions and the data model come before any assistant.

Phase 2: pick a pilot by the value of the loss

With the losses measured, the choice of pilot becomes arithmetic, not enthusiasm. For each candidate loss, ask four questions:

  1. How much is it worth? Minutes or bottles lost per week, times what a bottle or a minute is worth to you.
  2. Is the data ready? Does the signal exist, at the right frequency, joined to the stop log?
  3. What is the lowest rung that can fix it? A rule, SPC, a model, generative AI or an agent.
  4. What happens if it is wrong? A wrong suggestion on a changeover is cheap. A wrong call on a pasteuriser is not.

Scale helps focus the mind. On the illustrative filler line from post 4, the ideal output is 300,000 bottles a shift. One point of OEE is 3,000 bottles a shift. On three shifts for 300 days, that is 2.7 million bottles a year. Multiply by your own contribution per bottle and you know what a one-point improvement is worth before you have spent anything.

The pilot is usually classic AI: predictive maintenance on the asset behind the biggest breakdown loss, or anomaly detection on the process behind the biggest quality loss. It should be narrow: one line, one asset family, one loss.

Phase 3: generative AI for the text of the plant

Once there is a reliable data layer, generative AI has something to stand on. Shift handovers drafted from the stop log and notes, SOP answers with citations, root-cause support that proposes and never concludes. These tend to spread quickly because people feel the time saved every shift. They also expose any remaining data problems quickly, because a handover built on bad stop codes reads obviously wrong.

Phase 4: an agent that drafts

Only now does an agent make sense: the OEE loss agent from post 7, at autonomy level 2, reading replicated data, drafting work orders and changeover plans for a person to approve, with every tool call logged and no path to process control. It builds on everything before it: the stop codes to rank losses, the joined systems to connect a stop to an asset, and the handover to report what it did.

Honest ROI

AI projects in plants are prone to generous maths. A few habits keep it honest:

  • Measure the baseline before you start. Four to eight weeks of the loss as it is, recorded the same way you will record it afterwards.
  • Count in physical units first. Minutes, bottles, kilowatt hours, litres of water, kilograms of product lost. Convert to money only at the end, with the finance team.
  • Use a comparison where you can. A similar line that did not get the pilot shows how much of the change came from the season, the product mix or a new supervisor.
  • Count every cost. Licences and compute, yes, but also the data engineering, the operators’ time in design sessions and the ongoing care of the models.
  • Credit the whole team. Often the biggest gain comes from fixing the stop codes in phase 1, not from the model in phase 2. Say so.

Change management on the floor

The technology is the easy part. People decide whether any of this works:

  • Design with operators. They know which stop codes are nonsense and which alarms everyone ignores. Involve them from the first week.
  • Never use it to blame. If the handover summary or the loss agent becomes a tool for finding who to blame, the data will get worse within a month.
  • Give it an owner on the floor. A production supervisor, not only the data team, owns each tool and can switch it off.
  • Train for the failure modes. Teach people that the model can be confidently wrong, and that checking the citation or the evidence is part of the job.

AGI hype versus reality

Every few months there is a headline that AGI is close, and someone in a plant meeting asks whether it is worth investing now or waiting for the systems that will do everything. The honest answer has three parts.

AGI does not exist today. Nobody can say reliably when or whether it will. And every useful system in this series, from a vibration model to a work-order agent, depends on clean data, joined systems, clear definitions and approval processes. A future general intelligence would need exactly the same things to be trusted in a plant. The foundations are not wasted whatever happens. Waiting, on the other hand, has a known cost: every shift of losses you could have recovered.

Where this breaks

Phase 1 takes longer than planned. Joining systems and cleaning codes always does. Protect the time, and resist pressure to skip to the demo.

Pilots that never scale. A pilot on one line that needs a data scientist to keep it running will not reach the other five lines. Build the second line into the plan from the start.

ROI claims that cannot be checked. If a vendor’s savings cannot be traced to a measured change against a baseline, treat them as marketing.

Autonomy creeps. After a good year at level 2, there will be pressure to let the agent act on its own. Decide that deliberately, by the cost of a mistake, and keep process control out of it.

The bottom line

AI for operational excellence in a beverage plant is a sequence, not a purchase. Foundations first, then one pilot chosen by the value of the loss on the lowest rung that works, then generative AI for the plant’s text, then an agent that drafts for people to approve. Measure against a baseline in bottles and minutes, bring the floor with you, and do not wait for AGI. The losses are on the line today, and so is almost everything you need to recover them.

That closes the series. The full list is on the series page. For the winery version of the data foundations, see The Cellar Ledger; for distillery basics, AI Foundations for Distillers; and for the spirit and beer sides of GenAI and data engineering, The Still and the Model and The Brewer’s Agent.

Frequently asked questions

Where should a beverage plant start with AI? With the data foundations: reliable stop codes, the MES, historian, CMMS and LIMS joined on common asset and batch keys, and agreed definitions for OEE and the six big losses. Then pick one pilot on the loss worth the most, using the lowest rung of AI that can solve it. Generative AI and agents come after, on top of the same data.

How do you measure the ROI of an AI project in a plant? Against a baseline, in physical units first. Record the loss before the pilot, run the pilot, and measure the change in minutes, bottles, kilowatt hours or litres, ideally against a comparable line that did not get the change. Convert to money only at the end, and count all the costs, including the data work and the people’s time.

Should a plant wait for AGI before investing in AI? No. AGI does not exist, nobody can say when or whether it will, and every useful AI project today depends on clean data, joined systems and clear approvals. Those are exactly what any future system would also need. Waiting costs the losses you could have recovered in the meantime.