AI agents already participate in the work of building conventional software: examining requirements, proposing an implementation plan, editing code, running tools, and returning changes for review. An agent-led workflow can assign architecture, implementation, and testing to different agents, while people validate important decisions and supervise the result. As more of the implementation becomes automated, the human contribution increasingly concentrates on specifying what should be built and judging whether it meets that intention.
SCADA engineering can follow the same pattern. The output is an industrial application built on an established platform, with device connections, data models, processing logic, and operator interfaces. But AI-assisted SCADA also has a second meaning. After commissioning, an operational agent can use that application to investigate conditions and carry out permitted supervisory actions. Engineering produces the application; operations uses it to supervise the physical process. Each role requires its own evidence of correct behaviour.
From Requirements to an Accepted Architecture
An industrial project begins with an understanding of the installation and the required outcome. An RFI or RFP may start the conversation, but implementation needs detailed, agreed requirements. Someone must establish what equipment exists, how the process works, which signals are available, and what the customer expects. Visiting the site, resolving incomplete documentation, and understanding operational practices can still require substantial human work.
Once that information is available, an architectural agent can propose how to implement the application. In Iotellect, the proposal can be grounded in the platform’s architecture and low-code practices: which objects represent the equipment, how signals connect to those objects, where calculations belong, and how the application exposes information and actions to its users. The agent works with the capabilities of the platform it will actually use.
The first substantial human decision is accepting that architecture. A low-code architect reviews the proposal, challenges its assumptions, and makes corrections, potentially together with the customer. The review connects the requirements to an implementation that the partner can understand and maintain. Uploading a document is easy; establishing that the proposed system represents the customer’s intended behaviour remains engineering work.
Generating the Backend and the HMI
After architectural approval, the development agent can build the application across both backend and frontend. On the backend, this includes configuring device connections from the supplied addresses and settings, creating equipment models, binding properties to PLC values, and defining calculated tags. It can also create processing functions, configure historical retention, and assemble alerts, event filters, and event correlators according to the requirements.
On the frontend, it can construct dashboards and human–machine interfaces, alarm screens, event logs, and other application views. In Iotellect, agents access the unified model through tools exposed by our Model Context Protocol, or MCP, server. MCP provides a standard way to expose executable tools and contextual information to AI applications; the engineering capabilities depend on the tools and model the platform makes available. The agent therefore needs knowledge of both those capabilities and appropriate ways to use them.
We describe this as spec-to-code, although the output includes platform objects, configuration, and low-code logic rather than only text in languages such as Java or Python. The result remains an application that engineers can inspect through the platform. Our MCP-based workflows are already being used in our proofs of concept and partner projects, including production projects. Agent access through MCP and the availability of a particular packaged agent are separate things.
Reviewing and Testing the Generated Application
Human review still has a clear purpose. An architect examines the backend and frontend for consistency, maintainability, and appropriate use of platform functionality. A calculation can produce the right result while being implemented awkwardly; a screen can display the requested information while presenting it poorly. Low-code review addresses these issues in much the same way that code review examines conventional software.
The agent can also generate and execute tests. Backend tests can be implemented using the platform’s own rules and logic to exercise other application logic. Frontend tests require interaction with the running HMI, using a browser engine, including a headless browser. A test can click a button, inspect the resulting application state, and trace the action through backend processing to the value sent through a device connection. Observing the rendered application complements inspection of its configuration.
Automating these checks makes repeated verification and regression testing practical. The human test review must still examine what the tests assert, which requirements they cover, and which relevant conditions are missing. An implementation and its tests can share a mistaken assumption. Linking requirements to expected results and recorded test evidence helps reviewers assess coverage; a large test count alone does not establish correctness.
This is the first testing scope: the application within the platform and its exposed interfaces. The agent may follow the complete software path from an HMI action to an outgoing command. Evidence that the command was sent, however, has a different meaning from evidence that the physical process achieved the intended result.
Testing the PLCs and the Physical Process
The second scope combines SCADA with controller software. Consider a pump-start command. A broader agent with access to both the SCADA platform and the relevant PLC tools could check that the command reaches the controller, examine the conditions governing its execution, and verify the expected output. An interlock may correctly prevent the pump from starting. The test needs to assess that behaviour against the approved design, including the feedback presented by SCADA.
For Iotellect, this broader orchestration would involve an external agent with access to both environments. Our platform can remain accessible through MCP, while access to controller logic depends on the PLC vendor’s engineering or testing tools. Such an agent might also have participated in developing the controller software. Where the tools permit changes, it could also correct implementation errors and repeat the tests through the agreed review process. This is a wider integration scenario, beyond what a SCADA-platform agent can establish on its own.
The third scope is the physical installation. A changed PLC output does not establish that a motor is powered, connected, mechanically sound, and rotating. Commissioning must connect software observations to physical outcomes. A person can inspect the equipment; an automated test can also use suitable feedback, such as measured rotational speed. Even at the protocol layer, OPC UA distinguishes a write accepted by an intermediate system from one verified at the data source. Each observation has a defined limit.
The same principle extends to a conveyor or production line. Starting individual components is one result; observing products arrive at the intended destination is another. Sensors or machine vision can make that outcome available to an automated test. Commissioning can therefore combine physical inspection with increasingly extensive automated checks. The scope of automation expands as the installation provides trustworthy observations of the outcomes that matter.
Operating Through the Industrial Model
Once the installation is commissioned, the role of AI changes. Traditional SCADA presents much of its information through interfaces designed for people: HMIs, alarm lists, trends, and reports. Applications can already contain substantial automatic logic, but humans commonly provide the broader interpretation of events and decide how to respond. An operational agent can take on part of that supervisory work.
The agent needs knowledge of the process, the particular installation, and the application through which it interacts with the plant. That context can include equipment documentation, the approved architecture, the current application model, live measurements, historical data, and maintenance records. An agent involved in engineering may reuse its design context during operations, provided it can also inspect the system as it exists now. General knowledge of concrete production, for example, becomes useful when connected to the equipment and conditions of a specific concrete plant.
The technical starting point is available today: an agent can receive events, query equipment state, examine trends, and invoke permitted actions directly. It does not need to navigate an HMI to obtain information that the platform exposes through its model. During normal operation, it may recommend or make approved setpoint adjustments. When an anomaly appears, it can investigate the surrounding evidence and determine whether a permitted response is appropriate or a person needs to become involved.
For an illustrative conveyor incident, the agent might connect a loss of product flow with equipment feedback and a recent maintenance record, then request a targeted physical inspection. Its escalation can explain the observations, the suspected cause, and what remains uncertain. Existing deterministic alarms can continue to operate, while the agent adds contextual investigation and more specific requests for attention.
This creates the possibility of substantially headless routine supervision. The agent works through data and actions, while people use interfaces when they need to investigate, intervene, or oversee its work. The operational team may spend less time continuously watching screens and more time responding to situations that require physical action or judgment. The extent of that change depends on the process and on the tasks the agent has demonstrated it can perform.
Keeping the Plant’s Knowledge Current
An operational agent can only make appropriate use of the installation’s history if that history is available. A replaced motor, a recalibrated sensor, a temporary bypass, a known degradation, or an unresolved malfunction changes how current measurements should be interpreted. If those facts remain only in someone’s memory, the agent’s understanding can diverge from the physical plant even while live data continues to arrive.
Maintenance and operational changes therefore need to enter a shared record available to the agent and the relevant personnel. A useful record identifies what changed, which equipment was affected, when it happened, and whether the change is permanent or temporary. Corrections made during supervision also need to be retained in the appropriate instructions, application configuration, or operational knowledge. A correction in one conversation is useful only if the necessary information remains available when it is needed again.
This becomes part of operating the system. Keeping documentation and maintenance history current supports both human continuity and agent decisions. As routine supervision becomes more automated, the quality of that recorded knowledge becomes a more direct dependency of day-to-day operation.
Expanding Autonomy Through Supervised Operation
A commissioned application and a functioning installation do not, by themselves, establish that an operational agent will choose appropriate actions. Its decision-making needs evaluation too. The practical progression begins with humans approving all, or selected categories, of proposed decisions. Operators can examine the evidence, challenge the recommendation, and record corrections before the action is executed.
As acceptable performance is demonstrated, the agent can perform selected actions while a person follows its activity in near real time. This creates experience with the agent operating in context while retaining close supervision. The next stage allows independent operation for an accepted scope of tasks, with escalation when the situation falls outside that scope. Different actions can remain at different approval levels; autonomy need not be granted to the entire plant at once.
Progression should follow evidence about performance under relevant normal and abnormal conditions. Time spent operating without an obvious problem is useful experience, but it does not establish behaviour in situations that never occurred. Representative scenarios, review of decisions and outcomes, and continuing monitoring provide a stronger basis for deciding which responsibilities the agent can take on. Changes to the agent, application, or process can require renewed evaluation.
Throughout this progression, permitted actions and operating limits should be enforced by the underlying system. PLC logic and the installation’s protective functions continue to govern real-time behaviour. Close human observation is valuable where intervention can occur in time; it cannot protect against every consequence of an incorrect action. The operational agent therefore gains authority within an established control structure.
Where Engineering Expertise Moves
For system integrators, AI-assisted SCADA changes the distribution of work across a project. Agents can undertake more application construction and test execution, while engineers concentrate on requirements, architecture, review, and acceptance. Testing extends from the platform to controller software and physical outcomes, using the tools and feedback available at each level. The partner’s understanding of the customer’s process remains central throughout.
After commissioning, that expertise helps define the operational agent’s responsibilities and evaluate its performance. Maintaining an accurate account of the plant becomes part of maintaining the system itself. The opportunity is to deliver applications with less repetitive implementation work and operate them with less repetitive human supervision, while making the remaining engineering decisions explicit, reviewable, and supported by evidence.
Extending the Same Approach to MES
The same approach applies to manufacturing execution system (MES) projects. On a platform that exposes its application model and engineering tools to agents, approved requirements can be translated into production hierarchies, order workflows, lot and batch traceability, quality checks, material accounting, and integrations with enterprise systems. An architectural agent proposes how these capabilities fit together; a human architect validates the design; development agents build the backend, operator interfaces, and tests. The engineering workflow remains fundamentally the same, although more of the application’s behaviour concerns production transactions and manufacturing rules.
Testing must follow those transactions across the relevant system boundaries. An automated test might verify that completing a batch consumes the correct material lots, records the resulting quantities, preserves traceability, and reports production to the ERP without creating duplicate records when a message is retried. Other scenarios can cover partial completion, rejected material, interrupted operations, and corrections entered by an operator. Integration testing connects the MES application to controllers and enterprise systems, while commissioning establishes that the resulting records and workflows correspond to what actually happens on the production floor. A technically successful transaction still needs to represent the correct manufacturing event.
During operation, an agent can work directly with production orders, equipment states, material availability, quality results, and historical performance. It can investigate delays, identify emerging bottlenecks, connect quality deviations with relevant production conditions, and recommend changes to dispatching or scheduling. Where its authority has been validated, it can execute permitted workflow actions and request human involvement when physical intervention or additional judgment is required. As with SCADA, routine supervision can increasingly take place through the underlying application model, with screens and reports available when people need to investigate or intervene.
This also makes current manufacturing knowledge essential. Approved recipes, routing changes, equipment restrictions, quality decisions, and temporary production arrangements must be recorded and available to the agent. Its autonomy can then expand through the same progression: human approval of decisions, closely supervised execution, and independent operation within an accepted scope. For an integrator, the opportunity extends across both SCADA and MES: automate more application engineering and routine supervision while concentrating human expertise on process requirements, validation, and the decisions that determine whether the system serves the factory correctly.