MANUFACTURING OPERATIONS AGENT
Schedules sit in the ERP, downtime sits in a spreadsheet, the next changeover is on a whiteboard, and the rest is in the heads of two long-serving supervisors. We build AI agents that read all of it and answer the question, without ever touching a machine.
THREE EXAMPLE QUESTIONS, ANSWERED FROM RECORDS
"Why did line 3 stop last night?"
Four stop events, 63 minutes, two coded as material wait, one uncoded with the note "blew a seal again". A CMMS work request was raised at 02:14.
"Where is job 41882?"
Operation 3 of 5, 220 of 500 pieces reported, at outside processing since Tuesday with no receipt against the purchase order.
"What moves if the casting is two weeks late?"
Three jobs consume that part. Two have promise dates inside the delay window. Here they are, in date order.
Worked examples, not results from a named plant. Every answer names the record it came from, so a supervisor can check it instead of trusting it.
THE SHORT ANSWER
A manufacturing operations agent is an AI agent that works on the information layer of a plant. It reads your ERP, MRP, CMMS, historian and written procedures, then answers questions, summarises shifts, drafts documents and routes issues to named people. It does not run equipment, and it is not part of any control or safety function.
Most small plants do not have a data problem. They have a retrieval problem. What you need to run the floor already exists, split across an ERP, a spreadsheet, a whiteboard, a maintenance log and two long-serving supervisors. Answering something as ordinary as “why did line 3 stop” means a person walking around asking other people. That walk is what the agent removes. Not the supervisor, not the judgement, not the decision. The walk.
WHERE IT SITS
The level names come from ISA-95, which is built on the Purdue Reference Model and defines the interface between control functions and the enterprise functions above them. Source: ISA, ISA-95 standards committee
THE LINE WE DRAW
This is the first thing we say on a call, because it is the first thing a good plant manager asks. Control belongs to the PLC and SCADA layer: deterministic, validated, in places safety-rated. A language model is none of those things. The agent lives above that layer and only reads.
MTConnect, the open standard for machine-tool data, is read-only. Data published over it cannot be modified and written back to the machine, which is exactly the shape an operations agent should have. Source: MachineMetrics, MTConnect vs OPC UA. OPC UA does support writes, which is precisely why we scope our OPC UA access as subscribe-only. The OPC Foundation describes it as a platform-independent, service-oriented architecture. Source: OPC Foundation, OPC Unified Architecture.
WHAT WE ACTUALLY BUILD
Each one reads from a source you already own and hands off to a person you already employ. None of them close a loop on their own.
Job status from the ERP, downtime entries from the MES or shift log, open requests in the CMMS.
Assembles a handover per line: what ran, what did not, what is set up next, what is still open.
The outgoing supervisor corrects and signs it. The incoming one reads it before the walk-around.
Stop events from the historian, the MES or an operator tablet, plus the free text the operator typed.
Maps messy text ("blew a seal again", "waiting on mats") onto your own reason codes, then rolls the week up by line, shift and asset.
A rollup a plant manager can read, with unmapped entries listed rather than quietly bucketed as Other.
Work orders, routers, operation steps and quantity complete from the ERP or MRP.
Answers "where is job 41882", "which operations are left", "is the outside process back yet".
The answer plus the ERP record it came from, so the person can verify rather than trust.
New work requests in the CMMS, history for the same asset, parts availability from the ERP.
Groups duplicate requests, attaches the last repairs and the last failure, proposes a priority from your rules.
A triaged queue the planner accepts or overrides. They still set priority, they just stop starting blank.
The nonconformance entry, the traveler, lot and supplier data from the ERP, and the relevant SOP.
Drafts the NCR narrative: what was found, on which lot, at which operation, against which spec.
A draft for the quality engineer to edit and own. It never dispositions material and never closes a CAPA.
The released and firm-planned schedule from the ERP or MRP, work-center load, job progress.
Answers "what runs on press 2 Thursday", "what moves if we pull job 5511 forward", "where is the constraint".
A read of the plan as it stands. Committing a date stays a scheduler decision, and the agent says so.
Purchase orders, promise dates and receipts from the ERP, plus the BOM and the jobs consuming the part.
Traces a late purchase order down to the jobs and customer orders it puts at risk, in date order.
An impact note the buyer and scheduler can act on the morning the delay lands, not the week it bites.
SYSTEMS AND STANDARDS
We integrate against the systems a small manufacturer already runs, using read-scoped accounts. Where a plant has modern connectivity we use it. Where it does not, we do not make that a prerequisite.
Work orders, routers and operations, quantity complete and scrap, BOMs, purchase orders and promise dates, item masters, work-center load and the released schedule. Read, never written.
How a question gets answered
A person asks in plain language, in a chat window, a Teams or Slack channel, or a tablet at the line.
The agent picks the sources the question needs: ERP, CMMS, historian, SOP library, or several.
Structured tool calls run against those systems through a read-scoped service account.
Retrieval pulls matching maintenance-log entries, SOP sections and shift notes as supporting text.
The answer is composed with the record identifiers and document sections it came from.
The audit log records who asked, what was read, what was returned, and when.
No step in that chain writes to a machine.
HOW IT DIFFERS
These are not competitors. They do different jobs, and the agent is worth least in a plant that has none of the others.
Read-only
The agent owns no records and controls no equipment. It reads what your other systems already hold and turns it into an answer a person can check.
| Operations agent | MES / SCADA | CMMS | BI dashboard | |
|---|---|---|---|---|
| Answers a typed question in plain language | Yes | No | No | No |
| Writes setpoints or commands to equipment | No | Yes | No | No |
| Reads ERP, CMMS, historian and documents in one answer | Yes | Partial | No | Partial |
| Drafts a handover, a work request or an NCR narrative | Yes | No | Partial | No |
| Is the system of record for work orders | No | Partial | Partial | No |
| Useful with no machine connectivity at all | Yes | No | Yes | Partial |
| Escalates to a named human when the data is thin | Yes | No | Partial | No |
| Logs every question, source and answer for audit | Yes | Partial | Partial | No |
| Part of a safety-rated function | No | No | No | No |
| Role-scoped answers for operator, planner and plant manager | Yes | Partial | Partial | Partial |
PERMISSIONS, AUDIT, ESCALATION
If an agent touches a quality record or a customer commitment, someone will eventually ask how it got there. We build the answer in from the start rather than retrofitting it during an audit.
BEFORE YOU SCOPE ANYTHING
Send us the one question that costs your supervisors the most walking around. We will tell you honestly whether the data to answer it already exists, and what reading it would take.
WHERE THIS FITS
The pattern is the same everywhere. The systems, the vocabulary and the questions are not.
Short runs, high job count, constant "where is my part" calls, answered from Epicor Kinetic, JobBOSS or Global Shop Solutions.
Multi-operation routers with outside processing. The agent traces where a job sits and flags jobs stalled between operations.
Tooling changeovers and mould maintenance. Repeat requests grouped by tool in MaintainX or Fiix, so problem moulds are visible.
Lot traceability and sanitation windows. Quality-escape narratives drafted against the lot, line and SOP section, disposition left to the quality lead.
Configured products with deep BOMs. A late purchase order traced through the BOM to the jobs at risk, from data already in NetSuite or Business Central.
Order-driven production with seasonal load. Schedule questions answered against the released plan, naming the constrained work center.
READINESS CHECK
You do not need a data lake, a unified namespace or a digital-twin programme. You need records that exist and people who will use the answers.
HOW WE BUILD IT
Plant-wide rollouts of things nobody trusts yet are how AI projects die. We start narrow on purpose.
We sit with a supervisor for a shift and list the questions they get asked, then find where each answer lives: which ERP table, which CMMS field, which binder.
One use case, one line. Usually shift handover or work-order status. Sources, permissions and the escalation owner are written down before any code.
Read-scoped service accounts, structured tool calls into the ERP and CMMS, retrieval over SOP and maintenance-log text, audit log from the first commit.
We replay real shift questions against what the supervisor knows to be true. Wrong answers get traced to the source, not patched with prompt wording.
Your team gets the code, integrations and runbook. Once one use case is trusted, the next is configuration and testing, not a new project.
MANUFACTURING OPERATIONS AGENT FAQ
The questions that come up on every scoping call, answered the way we answer them on the call.
Topics
Can’t find your answer?
Talk to the founderScope and limits
An AI agent that works on the information layer of a plant. It reads your ERP, CMMS, historian and written procedures, then answers questions, summarises shifts, drafts documents and routes issues. It does not run equipment and is not part of any control or safety function.
No. It never writes a setpoint, starts or stops equipment, or sits inside an interlock. Control stays with your PLC and SCADA layer. We enforce that with read-only accounts in the integration layer, not by hoping a prompt holds the line.
Not by default. Everything described here is read-only against the ERP and MRP. If you later want one narrow write, for example raising a CMMS maintenance request, that is scoped as its own decision with its own approval step.
No. An MES is a system of record for production execution. The agent owns no records, it reads what your MES, ERP and CMMS already hold. With no MES it still works, because most floor questions are ERP, CMMS and document questions.
No, and we would push back if someone told you otherwise. The agent reads whatever you run today: Epicor Kinetic, Global Shop Solutions, Odoo MRP or NetSuite. A replatform is a much larger decision and should not be bundled into this one.
Systems and data
NetSuite, SAP Business One, Epicor Kinetic, Infor CloudSuite Industrial, Acumatica Manufacturing Edition, Dynamics 365 Business Central, Odoo MRP, Fishbowl, Global Shop Solutions and JobBOSS. Where no API exists we read a reporting database or a scheduled export instead.
That is the normal starting point, not a disqualifier. Spreadsheets are readable, whiteboards are not, so the first build covers the systems that already hold records and names the whiteboard gap out loud instead of pretending to close it.
Yes. Retrieval over maintenance-log text, work-request notes, SOPs and work instructions is one of the highest-value parts of the build, because that is where the knowledge of two long-serving supervisors is closest to being written down.
No. Machine connectivity helps with downtime capture, but most of what a plant manager asks is answered from the ERP, CMMS and documents. If you already publish OPC UA, MQTT with Sparkplug B or MTConnect we subscribe to it. If not, we do not make you build it first.
A design pattern where plant data is published once to a central broker, usually MQTT, and any system subscribes to what it needs. It is useful, and it is also a multi-year programme for most small plants, so we do not make it a prerequisite.
No. A read-only account against SQL Server or an ODBC source is often the cleanest integration available, because the tables are stable and your own people understand them. We prefer a documented API where one exists, a read replica where one does not.
What it does daily
A short structured note per line: jobs run and quantities, jobs behind and by how much, downtime events with reasons, open maintenance requests, quality holds, and what is set up next. The outgoing supervisor corrects and signs it in a couple of minutes.
It can tell you what was recorded: stop events, durations, reason codes and operator free text, plus any maintenance request raised around the same time. If nothing was recorded it says so. It reports the record, it does not diagnose the machine.
It can tell you what the current plan and load look like, which work center is constrained this week, and what is already committed. The commitment stays a human decision. An agent that promises a date it cannot control is a liability, not a feature.
Operators keep entering reasons the way they already do, on a tablet, an MES screen or a paper log we digitise. The agent maps that free text onto your reason codes, rolls it up by line, shift and asset, and lists what it could not map.
It drafts the narrative: what was found, on which lot and operation, against which spec, with the relevant SOP section quoted. A quality engineer edits, owns and submits it. The agent never dispositions material and never closes a corrective action.
It says so, names what is missing, and routes the question to the human who owns that topic. Every use case gets a named escalation owner during scoping. A silent wrong answer on a factory floor costs far more than an honest "I do not have that".
Trust and security
Answers are grounded in retrieved records and tool-call results rather than generated from memory, each names the record or document section it came from, and unsupported questions are refused. In testing we replay real shift questions and trace every wrong answer to its source.
Not in the deployments we build. Data flows through the model to produce an answer and is not contributed to training. Where your customer contracts require it, we deploy against configurations that make that boundary contractual rather than a setting.
Working together
A single use case on a single line, usually shift handover or work-order status, is weeks rather than quarters. The integration work is the slow part, not the agent. We give a firm timeline once we have seen the systems.
Then you find out on one line, on one use case, with your data still exactly where it was. That is why we scope the first build narrowly. A pilot that fails cheaply beats a plant-wide rollout nobody trusts.
Each URL below was fetched and the claim confirmed on 2026-08-06.
The OPC Foundation describes OPC UA as a platform-independent, service-oriented architecture folding the older OPC Classic specifications into one extensible framework.
OPC Foundation, OPC Unified ArchitectureMTConnect is read-only: machine data published over it cannot be modified and written back to the machine.
MachineMetrics, MTConnect vs OPC UAISA-95 is built on the Purdue Reference Model and defines the interface between control functions and the enterprise functions above them, principally levels 3 and 4.
ISA, ISA-95 standards committeeRelated: AI agent development, AI workflow automation, and AI customer support agents. Written by Bhavesh Barot, founder of FactoryJet. Last reviewed 2026-08-06.
GET STARTED
Tell us what your supervisors walk around to find out, and which systems hold the answer today. We will scope a first build against one line, read-only, with the escalation owner named before any code is written.
Read-only against your systems. No PLC or SCADA control. Audit log on every answer. You own the code.