Short answer: the most useful agent in a beverage plant is not a robot operator. It is a patient analyst that, at the end of every shift, reads the stop log, ranks the OEE losses, notices that the labeller glue unit has stopped the line six times this week, checks the maintenance system, finds no open work order and drafts one with the evidence attached for a planner to approve. The same agent can draft a changeover sequence that cuts flush time. What makes it safe is not the model. It is the architecture: read-only access to replicated OT data on the IT side of the Purdue model, no path to PLCs or SCADA, write tools that only create drafts, an audit log of every tool call and replay tests before it goes live.
Every plant has a list of losses everyone knows about and nobody has time to chase. The labeller that stops for thirty seconds a dozen times a shift. The changeover that always runs twenty minutes long. The pump that trips when the ambient temperature passes 35 degrees. Each is small. Together they are often the biggest bar on the OEE waterfall.
The third post in this series explained how agents work. This one, the seventh, puts one to work on those losses and spends at least as long on the fences around it.
The OEE loss agent, step by step
Here is what a well-scoped agent does at the end of each shift. Every step is a tool call to a tested query or a controlled system.
- Rank the losses. Pull the shift’s stops from the MES replica and group them by the six big losses and by asset. The labeller glue unit accounts for 31 minutes across six stops.
- Check for recurrence. Look back over the last two weeks. The same fault code appears 23 times, rising.
- Look at the asset. Query the CMMS: the last work order on the glue unit was closed four weeks ago, “cleaned nozzles”. No open order now.
- Look at the signals. Pull the glue temperature tag from the historian replica around each stop. It dips below its setpoint band just before most of them.
- Draft the action. Create a draft work order in the CMMS: asset, symptom, the 23 stops, the temperature pattern with a chart link, the previous work order, a suggested priority. Status: draft, awaiting planner.
- Report. Add one line to the shift handover: “Draft WO raised for L2 labeller glue unit, recurring temperature dips, see link.”
A planner reviews the draft the next morning, adjusts the priority and releases it. The agent did in two minutes what would have taken an engineer an hour, and it did it every shift, not just when someone had time.
Changeover plans, drafted not scheduled
The same pattern works for changeovers, the second of the six big losses. Given the week’s production plan from the ERP and the known changeover times between products and formats, an agent can draft a run sequence that reduces flushes and format changes. Dark beer after pale, not pale after dark. Group the 330 ml runs together. It can also flag where the plan forces an avoidable changeover.
It hands the draft to the planner, who knows things the agent does not: the customer order that has to ship on Thursday, the operator who is on leave, the tank that will not be ready. The planner edits and publishes. The agent never touches the live schedule.
Guardrail 1: the Purdue model
Most beverage plants organise their networks along the lines of the Purdue model, and OT security standards such as IEC 62443 build on the same separation. At the bottom, levels 0 to 2 hold the process, the PLCs, SCADA and HMIs. Level 3 holds site operations: historian, MES, CMMS, LIMS. Levels 4 and 5 are enterprise IT. Between operations and IT sits a demilitarised zone, the DMZ, where data can be shared without opening the control network.
An agent belongs on the IT side. It reads a replica of historian and MES data published into the DMZ. It never opens a connection down into levels 0 to 2. If your architecture would require it to, the architecture is not ready for an agent.
Guardrail 2: no writes to process control
This one deserves its own line. Nothing an agent does should change a PLC, a SCADA value or a process setpoint. Not through a tool, not through a script, not “just for this one low-risk parameter”. Process control is engineered, validated and interlocked for good reasons, and a language model that is right 98 percent of the time is not acceptable in a loop where the other 2 percent is a caustic line or a pressurised vessel.
The simplest way to enforce this is to never build the tool. If there is no set_value function on any MCP server the agent can reach, and its service account has no write rights anywhere near OT, the question never comes up.
Guardrails 3 to 8: drafts, approvals, logs, evals, limits, off switch
- Write tools create drafts only. The CMMS tool can create a work order in draft status. It cannot release one, close one or change a released one.
- A person approves every draft. With the evidence shown, not just the conclusion. Track edit and rejection rates, because a rate of zero usually means nobody is reading.
- An audit log of every tool call. Which tool, which inputs, what came back, what the agent drafted. When someone asks why a work order exists, the answer is in the log.
- Replay evals before go-live. Run the agent over the last one or two months of shifts, with the data as it was at the time, and compare its drafts with what planners and engineers actually did. Count the real issues it caught, the noise it raised and the drafts that would have been wrong. Repeat whenever the model, the prompts or the tools change.
- Step, cost and rate limits. A cap on tool calls per run and drafts per shift, so a confused agent cannot flood the CMMS.
- One switch turns it off. Someone in operations, not only in IT, can stop the agent immediately.
On the autonomy ladder from post 3, this agent sits at L2: it reads freely and drafts, and a person approves. That is where it should stay.
Where this breaks
The agent inherits every data problem. If stop codes are vague, the ranking is vague. If the CMMS asset hierarchy does not match the MES, the agent cannot link a stop to a work order. Fix these first. They are cheaper than any model.
Too many drafts kill trust. An agent that raises fifteen drafts a shift will be ignored within a week. Start with one loss type and one line, and tune for precision over coverage.
Prompt injection through plant text. The agent reads operator notes and old work orders. Treat all of that as data, never as instructions, and keep every write tool behind approval so a strange note cannot become an action.
Replica lag. If the DMZ replica runs hours behind, the agent works on stale data. Show the data timestamp on every draft.
Approval fatigue. Oversight that consists of clicking approve forty times at the end of a shift is not oversight. Keep volumes low and evidence clear.
The bottom line
A good plant agent is an analyst, not an operator. It reads the losses every shift, connects the stop log, the historian and the maintenance history, and drafts the work order or changeover plan a busy engineer never gets to. It is safe because of where it sits and what it can touch: the IT side of the Purdue model, read-only OT data, draft-only write tools, a person approving, every call logged, tested by replaying history. The model will sometimes be wrong. The architecture makes sure that being wrong costs a rejected draft, not a batch.
Next, and last: the roadmap and where it breaks. For the predictive side of line downtime, see Predicting Packaging Line Downtime and Lifting OEE. The full list is on the series page.
Frequently asked questions
What can an AI agent safely do in a beverage plant? Read production, maintenance and quality data, work out which losses matter, and draft actions for people: maintenance work orders, changeover plans, shift summaries, messages to a planner. Each draft carries its evidence and waits for approval. It should have no path to write to PLCs, SCADA or process setpoints.
What is the Purdue model and why does it matter for AI agents? The Purdue model is a reference architecture that separates a plant’s networks into levels, from the physical process and its controllers at the bottom to business systems at the top, with a demilitarised zone between operations and enterprise IT. An agent belongs on the IT side, reading replicated data from the DMZ. It should never open connections down into the control levels.
How do you test an AI agent before letting it loose on a plant? Replay history. Run the agent over the last month or two of shifts, using the data as it was at the time, and compare its drafts with what planners and engineers actually did. Measure how many real issues it caught, how many drafts were noise, and how many would have been wrong. Repeat the replay whenever the model, the prompts or the tools change.