Classify the consequence before choosing the autonomy level
A shift summary, a maintenance recommendation and a production set-point change do not belong in the same risk class. The first can usually be generated from read-only evidence. The second may affect maintenance prioritization and cost. The third can affect product, equipment and safety.
Define the maximum consequence of a wrong answer first. Then decide whether the agent may only retrieve information, generate a recommendation, prepare a workflow, request approval or execute a bounded action.
- Read-only explanation
- Advisory recommendation
- Prepared action awaiting approval
- Bounded workflow execution
- Control or safety action
Keep deterministic control deterministic
PLC, DCS and safety logic are engineered for deterministic timing, interlocks and failure behavior. An AI model is not a replacement for those responsibilities.
An industrial agent can explain why a control condition exists, assemble evidence around a trip, recommend an operating procedure or prepare a maintenance action. The deterministic system should continue to own time-critical control and safety enforcement.
- No direct bypass of interlocks
- No hidden set-point writes
- No autonomous safety-function changes
- No model-only permissives for hazardous actions
Require evidence that a human can inspect
Confidence scores are not enough. A useful industrial recommendation should point to the evidence behind it: tag values, alarm timestamps, work orders, quality records, images, manuals or engineering documents.
The agent should also identify missing or conflicting context. In operations, “I do not have enough evidence” is often a better answer than a fluent guess.
- Source citation or traceable evidence
- Timestamp and asset identity
- Known data-quality state
- Conflict and uncertainty surfaced
- Reason for recommendation recorded
Separate permission to know from permission to act
A maintenance agent may need broad visibility across historian, CMMS, alarms and documents while still having no authority to create or close a work order. Access architecture should therefore separate read scopes, recommendation scopes and execution scopes.
When execution is permitted, use narrow, named tools with explicit parameters and policy checks rather than a generic write-anywhere capability.
- Least-privilege data access
- Named tools instead of generic writes
- Parameter validation
- Approval and dual-control where appropriate
- Immutable audit trail
Design the refusal behavior before the happy path
Production teams need to know what the agent will refuse to do when evidence is weak, authorization is missing, data is stale or the requested action crosses a safety boundary.
Refusal is a product feature. It should be visible, understandable and testable in the same way as a successful recommendation.
- Stale or poor-quality data
- Missing operating context
- Conflicting source systems
- User outside approved role
- Action outside defined operating envelope
Primary sources used for this perspective
Product names and trademarks belong to their respective owners. Delfers engineering perspectives are intended as architecture guidance; outcomes depend on site conditions, system design and implementation.