AI agents that resolve manufacturing exceptions across ERP, MES, CMMS and supplier systems, with an authority boundary defined per action and a reversal path for everything they change.
An agent that reads production data and summarises it is a dashboard with a conversation attached. The value appears when it can change something: move a job, release a replenishment, raise a work order, chase a supplier. That is also the point at which somebody has to decide what it is allowed to do.
These are in order of increasing authority. Most manufacturing agent programmes get stuck between the second and the third row, because that is where the agent stops suggesting and starts changing.
ERP, MES, PLM and the shop floor disagree
So the first job is deciding which one is right.
Planning done in a spreadsheet beside the ERP
Because the ERP cannot represent the real constraint.
Exceptions found at the morning meeting
Hours after the condition occurred.
A planner chasing five systems
Which is coordination work, not planning work.
Real-time visibility that is a daily report
And a decision window measured in minutes.
Shift handover as a verbal account
With the important detail depending on who is on.
Repetitive administrative work absorbing shifts
Form filling and status chasing, every day, by everybody.
Automation that stops at the system boundary
The step between two systems is still a person.
No agreed limit on what software may change
So the safe answer becomes nothing.
Ask a planner to list everything they touched yesterday that was not in the plan. The list will be exceptions, and most of them will have involved looking something up in a second system and telling somebody. That is the work worth automating, it is measurable today in hours, and it produces a business case that does not depend on anybody losing their job. Thirty minutes with one planner is enough to size it.
The technical work in a manufacturing agent is integration and judgement under uncertainty. The work that determines whether it reaches production is the agreement about what it may change, and that agreement involves operations, engineering, quality and safety rather than only IT.
So we settle the authority boundary early, on one workflow, and prove the reversal path before anybody discusses scaling.
Step 1
Discover the workflow as it is actually performed
Step 2
Measure where the time goes, by exception type
Step 3
Identify the automation candidates and the ones to leave
Step 4
Establish the system of record for each piece of state
Step 5
Agree the authority boundary per action, with operations
Step 6
Design the reversal path for every action the agent takes
Step 7
Design the human approval and escalation points
Step 8
Build the integrations to ERP, MES, CMMS and WMS
Step 9
Build the agent with its tools and permissions explicit
Step 10
Pilot on one workflow at one plant, with a measured baseline
Step 11
Validate: exception resolution time, intervention rate, errors
Step 12
Roll out by workflow and by plant, then improve continuously
For the first agent, write the authority boundary on one page and have operations sign it. Which actions, in which systems, up to what limit, with what approval, and what it may never do. One page, signed before the build starts. Every programme that skips this has the same conversation later, with a working agent waiting and an operations director who was not consulted, and that conversation is considerably harder.
Grouped by the work each one does. Every agent below is specified with its authority boundary, its approval points and its reversal path, which is what makes it deployable rather than demonstrable.
Planning and production
Production planning and scheduling agents: exception-driven rescheduling within stated limits, with the previous schedule restorable
Schedule impact assessment, so a proposed change arrives with its consequences for promised dates rather than as a bare recommendation
Production reporting and shift handover generation from the systems of record, which removes an assembly job rather than a judgement
Order processing and fulfilment automation across the steps that currently sit between systems
Materials and suppliers
Inventory and material management agents: shortage detection, replenishment within limits, and reconciliation of what the system says against what the floor says
Procurement and supplier coordination agents: follow-ups, acknowledgement chasing, and delivery confirmation, within content limits you set
Supplier response handling, including the escalation when the answer does not arrive
Maintenance and quality
Maintenance coordination agents: work order creation and scheduling around production, with safety-related work excluded by rule
Breakdown response coordination, which is the case where minutes matter and five people need the same information
Quality nonconformance workflow agents: routing, evidence gathering and status chasing, with the quality decision left to the quality function
Hold and release coordination, so a quality decision reaches the schedule without somebody carrying it
Platform and orchestration
Manufacturing operations copilots for supervisors and planners, answering from the systems of record with the source shown
Multi-agent orchestration where several agents touch one workflow, with one named owner for that workflow and one stop
Tool and permission design per agent, so capability is granted explicitly rather than assumed
Human approval and escalation interfaces built into the tools people already use
Each of these is a coordination problem across systems. What differs is how much authority the agent needs to be useful, which is also what determines how long it takes to get approved.
Production schedule exception handling
A breakdown, a shortage or a late changeover invalidates part of the schedule, and somebody has to decide what moves.
Material shortage identification and resolution
Detect the shortage before the job is due to start, establish what is available, and propose the resolution.
Automated supplier follow-ups
Chasing acknowledgements, confirmations and late deliveries, which is work that never gets done consistently.
Maintenance work order coordination
Creating, scheduling and chasing maintenance work around production, and coordinating the breakdown response.
Quality nonconformance workflows
Routing a nonconformance, gathering the evidence, chasing the disposition and connecting the outcome back to the schedule.
Inventory replenishment automation
Acting on reorder conditions within limits rather than producing a report somebody actions.
Production reporting and shift handover
Assembling what happened, what is open and what the next shift must know.
Ask who would have to agree before software could change tomorrow’s schedule. Collect the names now. In most plants it is operations, planning, quality and sometimes engineering, and several of them have never been asked. Getting their conditions in advance takes a week and it is the difference between an agent that reaches production and a successful pilot that stops at the authority conversation.
We work within your existing systems and your OT and IT separation. The architecture is unremarkable by design: what matters is that every capability the agent has is granted deliberately and that the boundary to the control layer is absolute.
Orchestration
The workflow, its steps, its state and its owner. One stop per workflow.
Tools and permissions
Each action the agent can take, declared, scoped and logged.
Enterprise integration
ERP, MES, PLM, CMMS and WMS through supported interfaces.
Operational data
Industrial IoT and historian data, read-only, through a defined boundary.
Event integration
So the agent reacts to a condition rather than polling for it.
Knowledge retrieval
Procedures and reference material, with the source shown.
Approval and escalation
In the tools people already use, with the reason visible.
Audit trail and decision traceability
Every action, its input, the authority it relied on and its outcome, reconstructable later.
We use the supported interface of each system. Where only a direct database route exists, we say so and treat it as a risk to be accepted explicitly rather than a shortcut
Operational technology data is read through a defined boundary, in one direction. Nothing we build writes into a control network
Event-driven where the system can emit events, polled where it cannot, with the polling budget agreed with whoever owns that system
Where a plant system cannot support the integration at all, that is a finding about the estate rather than a problem to engineer around quietly
Before any discussion of autonomy levels, one boundary has to be stated plainly, because it determines what the rest of the governance is for.
Role-based access
The agent has an identity, with permissions reviewed like a person’s.
Approval checkpoints
Where authority ends, with the reason visible to the approver.
Autonomy and action limits
Enforced in the tools, per section 6.
Industrial cyber security
Segmentation, one-way data flow, no inbound path to OT, reviewed with your OT security function.
Audit trail
In the system of record, not only in the agent.
Exception handling
What it does when it cannot complete, with an owner.
Reversal
A way back for every action, per section 3.
Change control
Agent changes through your change process, like any other system change.
Agent dashboards fill with task counts and completion rates. Two numbers determine whether the agent survives contact with a plant, and both are about the people around it.
HUMAN INTERVENTION RATE. How often a person has to step in, and what for. Falling with stable quality means the agent is learning the real workflow. Rising means something changed and nobody told it
EXCEPTION RESOLUTION TIME, against the baseline measured before the agent existed. This is the business case, and it is the number an operations director will ask for first
Task completion and success rate by workflow and by exception type, since an agent that is reliable overall can be useless on one class of case
Agent accuracy on the cases where it proposed and a person decided, which is the equivalent of an override rate
Workflow cycle time end to end, including the waiting that nobody counts
Unauthorised action attempts, which should be zero and which tell you the limits are enforced rather than described
Reversals performed, with the reason, which is the clearest signal of where the agent is wrong
Operational cost and productivity, against the baseline rather than against a projection
Volume of work arriving at each approval point, because an approval queue that nobody can keep up with becomes a rubber stamp
Measure the exception resolution time before the agent exists. Afterwards it is an argument. Beforehand it is a number, and it takes a week of asking a planner to note start and finish times. Every agent programme that cannot demonstrate value has this missing, and no amount of task-completion reporting substitutes for it.
Outcomes depend on your systems, your plants and how much coordination currently happens by phone. These are the changes the work is aimed at.
Exceptions are detected when they occur rather than at the morning meeting
Resolution time falls against a baseline you measured, which makes the business case evidence rather than projection
Planners spend their time on planning rather than on chasing five systems, which is the workforce productivity gain stated honestly
The plant responds faster to the conditions that change, because detection and coordination no longer wait for a person to notice
Supplier follow-up happens consistently rather than when somebody has time
Shift handover starts from the same facts every time
Every agent action has an authority behind it, a record in the system of record, and a way back
Nothing the agent does touches a control system or a safety-related function
And the plant still has one system of record, which is the test in section 3
Bring us one exception workflow, and we will map it as it is actually performed, measure where the time goes, draft the authority boundary for operations to sign, and build the first agent on the part where it cannot do damage.
CaliberFocus builds manufacturing agents that resolve exceptions across ERP, MES, CMMS and supplier systems within an authority boundary your operations team signs. Every action has a limit, an approval point and a way back, decisions are written to the system of record, and no agent actuates a control system or touches a safety-related function.
- An authority boundary per action, agreed and signed by operations
- A reversal path for every action, or approval before it happens
- Limits enforced in the tools, not in the agent’s instructions
- No agent actuates a control system or a safety function
Security & Compliance
