Agentic AI in industrial operations

Most of what is currently sold as agentic AI in industrial operations is one of four older things wearing a newer label. The four are genuinely different from each other, and a buyer who cannot tell them apart will pay agent prices for a scheduled query. The distinguishing feature is not the model, and it is not the interface. It is who decides the next step.

A scheduled job runs a fixed sequence that somebody wrote in advance. It may well call a language model somewhere in the middle, to summarize a shift log or classify a fault code, and it is still a scheduled job: the steps are identical on every run and the model is one of them. That is a good design for work whose shape you already understand, and it is far easier to test than anything below it in this list. It is not an agent.

An agent differs in one specific way. It is given a goal and a set of tools, and it chooses which tool to call next based on what the previous call returned. Ask why a turbine underperformed last week and it can decide, during the run, to pull the availability history first, notice a gap in it, go looking for the signal behind the gap, and come back with an account that no fixed sequence would have assembled. That freedom is the entire value of the approach and the entire source of its risk, which is why the approval boundary in the next section is structural rather than optional.

Three of those carry a note the row cannot hold. A chatbot retrieves, reads and replies: it carries out no plan of its own, changes nothing, and leaves nothing behind when the conversation closes. An alert rule does not reason and does not need to, and a threshold on a temperature is not intelligence: calling it that obscures what it is genuinely good at. An agent, because its sequence is decided at run time, can produce work nobody specified, which is why nothing it produces should take effect unreviewed.

There is a quick field test that separates them without any access to the vendor's architecture. Ask what the system does when the first thing it tries comes back empty. A scheduled job fails or writes a null. A chatbot says it could not find anything. An alert rule does not have a first thing to try. An agent goes and looks somewhere else, and then tells you where it looked. If a demonstration cannot survive a missing input, the label on the box is doing work the software is not.

None of the four is better than the others in the abstract. A great deal of industrial work should be a scheduled job, because the sequence is known and a fixed sequence is easier to test, cheaper to run, and simpler to explain to an auditor. Alert rules remain the right instrument for a standing condition on a stream, and no amount of reasoning improves on a threshold that already works. The argument for an agent is narrow and specific: it is the right instrument where the useful next step genuinely depends on what the last step found, which is true of investigation and of authoring, and false of most of the rest.

The failure mode of a language model is not a crash. It is a confident, well-formed, wrong answer that looks exactly like a right one. In most software that is an annoyance you catch on the next screen. In industrial operations it is expensive in a second-order way, because numbers about assets travel: a credible-looking wrong availability figure gets copied into a monthly summary, into a board pack, and into a warranty conversation long before anyone thinks to re-derive it.

This is why the useful question about an industrial agent is never how clever it is. It is what the system does with the agent's output before that output becomes something people act on. An agent that drafts a calculation and hands it to an engineer is a different product, with a different risk profile, from one that drafts the same calculation and starts computing it fleet-wide on its own. The models involved may be identical. The systems are not.

So the boundary is drawn between drafting and taking effect, and it is drawn in the software rather than in the operating procedure. On one side an agent may read, reason, draft, and preview. On the other side, everything that persists or runs waits for a person. The two lists below are the ones worth demanding from any vendor, because the split between them is the product.

• Read the history, the asset model, and the definitions already in use
• Draft a calculation and present it as a specification you can actually read
• Run that draft over your real history as a preview that writes nothing
• Explain a number by citing the readings and the definition it came from
• Propose a change, and stop there

Everything else is a person. Enabling a definition so it computes, activating an alert rule, changing a configuration on a site, dispatching a command: each of those is an explicit human action with a name attached and a record behind it. Preview is what makes that review meaningful rather than ceremonial. Being asked to approve a formula you cannot evaluate is a rubber stamp. Being shown what that formula produces over your own last ninety days, before anything is stored, is a decision.

Honest answer, and the reason this section carries a maturity marker rather than a promise. Live dashboards and fleet-scoped alerts ship today, and specialist agents build the KPIs your fleet is measured by, approved by you, in early access. Those are two different levels of readiness in one sentence on purpose. Monitoring is a solved, shipped thing. Agents that author the measurement system are new, they carry an early-access marker for a reason, and describing them otherwise would be the exact overclaim this page exists to argue against.

The loop, where it is running, has four steps and only one of them belongs to the agent. You describe what you want to know in plain language. Specialist agents write the calculation, work out which assets it applies to, and build the dashboard. You preview every draft over your real history, and nothing activates without an explicit human yes. What you approve then computes continuously on every matching asset as first-class time series, queryable and exportable like any raw signal.

What is deliberately absent from that table is anything the agent starts by itself. There is no step where a draft becomes live because it scored well, no confidence threshold above which review is skipped, and no batch mode that approves twenty definitions because you approved the first three. Those are the shortcuts that make a demonstration impressive and make a production system unaccountable, and the moment one exists, the audit trail stops answering the only question anyone asks after a bad number: who decided this, and when.

Hand a language model a list of controller addresses and it cannot reason about a fleet, however capable the model is. An address like ns=2;s=WTG_07.ActivePower carries no unit, no data type, no statement of which physical thing it belongs to, and no guarantee that the identically named address at the next site means the same quantity. An agent given that has two options, and both are bad: refuse, or infer from the string and present the inference with the same confidence as a fact.

Modeling removes the guess. Once a raw address is bound to a named variable with a unit, attached to an asset that has a type and a site, the questions change shape. Compare the three worst performers across the wind fleet stops being a string-matching exercise over tag names and becomes a resolvable query over things the system knows: which assets are turbines, which variable on a turbine carries active power, and what unit it is in. The agent is no longer interpreting a naming convention. It is reading a model.

This is also what makes an approved definition worth approving once. A calculation bound to a site's tag list is a per-site artifact, and a fleet of twelve sites is twelve of them drifting apart. A calculation bound to an asset type applies to every asset of that type you own, including the ones you commission next year, which never require a second approval or a second review. The value of the review step compounds only because the thing being reviewed is fleet-wide.

The honest limit deserves stating in the same breath. An agent inherits the quality of the model it reads. If two sites bound the same variable name to different physical measurements, the agent will compare them and report the comparison confidently, because nothing in the data says the two are not comparable. Modeling discipline is a prerequisite for this to work, not something the agent supplies on your behalf. It is also why the binding step is where most of the durable work in an industrial data program actually lives.

An industrial agent is only as good as its read surface, so be precise about what that surface is. It reads the modeled history: named variables on real assets, with units and types, rather than raw controller addresses. It reads the asset model itself, which is how it knows that a question about a battery site concerns four stacks and not one. It reads the definitions already approved, so it can propose something consistent with them. It reads alert events. It does not read your control system.

The boundary on the other side needs stating outright, because vague answers here are common and the vagueness is usually load-bearing. Fleetera does not replace the controllers that keep your equipment safe, and no agent in it writes to equipment. Command is a supervisory layer that manages configuration across every site from the cloud, audit-trailed, with a human always in command. Supervisory equipment commands are in development. Explanations read your data; they never act on it.

There is a subtler boundary that gets less attention and deserves more. Plant data contains text that people typed: asset descriptions, site notes, tag comments left by an integrator years ago. To a language model, text is text, and a sentence in an asset description that reads like an instruction is indistinguishable from an instruction unless the system is built to keep them apart. Content pulled from your fleet must be handled as data the agent is reasoning about, never as direction the agent follows. Ask any vendor how they enforce that, and be unsatisfied by an answer that is only about the prompt.

• What exactly can the agent read, and is it the modeled data or the raw stream?
• Which of its tools can write anything at all, and what gates each one?
• Is there any path, direct or indirect, from an agent to a controller?
• How is text that came from our own plant prevented from acting as instruction?
• When the agent is wrong, what record exists of what it saw and what it proposed?

Agent demonstrations are unusually easy to make impressive, because the demonstration is allowed to choose the question. Real operations do not offer that courtesy: the data has gaps, two sites spell the same signal differently, and the interesting questions are the ones nobody prepared for. Five requests will separate a system that survives that from one that does not, and none of them require access to the vendor's code.

The fourth of those is the one people skip and later regret. Industrial history is not immutable: a link comes back and delivers three hours of buffered readings, a bad sensor is replaced and its recent output is invalidated, a site clock is corrected. Any number computed over an affected window was computed over incomplete inputs, and a system that never revisits it will hold a stale figure indefinitely while looking perfectly healthy. Restatement is unglamorous, it never appears in a demonstration, and it is most of what makes the difference between an analysis you can cite and one you have to re-derive by hand.

The fifth matters for a reason that has nothing to do with AI. Once a number is used to judge an asset, somebody eventually disputes it, and the dispute is settled by provenance rather than by argument: which definition produced it, at which revision, approved by whom, over which inputs. A system that can answer that has made the agent's role auditable. A system that cannot has made it deniable, which is worse than not having the agent at all.

The scarce resource in industrial analysis was never the ability to write a calculation. It was the person who knows what the number is supposed to mean: which availability convention this fleet uses, why the counter on that make of inverter resets, whether a curtailed hour should count against performance. That knowledge has always been the bottleneck, and it has always been in short supply relative to the number of assets that need it.

What agents change is which part of that person's day the knowledge is spent on. Authoring a definition, translating an intention into an expression, checking it over history, then repeating the whole thing per site, is hours of work in which the expertise is a small fraction. Reading a drafted definition and judging whether it matches the intention is minutes, and it is almost entirely expertise. The work does not disappear. It concentrates into the part only a person can do.

That shift has a consequence worth planning for rather than discovering. Once drafting is cheap, review becomes the constraint, and a team can generate proposals faster than it can responsibly approve them. The systems that hold up under that pressure make review fast without making it shallow: a readable specification instead of raw code, a preview over real history instead of a description of what should happen, a visible difference against the previous revision instead of a fresh wall of text every time. Approval you cannot perform in good faith is not a safeguard.

Narrowly, and with two numbers rather than one. The honest measure of an agent that drafts definitions is the throughput of approved definitions and the review time each one takes. Everything else on offer in this category is either unmeasurable or measures something that did not happen.

Take the two candidates people reach for first. Headcount saved is not the effect: the work does not leave, it moves from authoring to judging, and the person who knows what the number should mean is needed more once definitions are cheap to produce, not less. A percentage saving is worse, because it is a figure with no traceable derivation. Ask where any such number came from and the answer is a run nobody can point at, on a fleet that is not yours.

What can be counted, from the system's own record rather than from an impression:

1. 1Approved definitions per period, and the proportion of drafts that were rejected. A rejection rate near zero is a warning rather than a triumph: it usually means the review has become a formality.
2. 2Review time per definition, measured from draft to decision. This is the number the whole approach is supposed to move, and it is the one nobody records unless the system records it for them.
3. 3Revisions shortly after approval, which is the cost of a review that went too fast. A definition corrected a week later consumed two reviews and produced a period of numbers that have to be restated.
4. 4Coverage: how many asset types have an approved definition against how many are still measured by a per-site arrangement. This is what fleet-wide means in a number.
5. 5How much of that was traceable afterwards: whether the definition, its revision, its approver and its inputs can be recovered without asking a person.

Read together, the first two are the whole argument and either one alone is misleading. Approvals rising while review time per definition collapses toward nothing is not productivity, it is a rubber stamp acquiring volume. Review time holding steady while approvals rise is the outcome worth having, because it means drafting got cheaper and judgment did not get thinner.

We publish no figure for any of this, deliberately. There is no measurement we could stand behind, and a number invented for a web page is worse than an absent one, because it will be quoted back to us by someone who took it seriously. These are the things to instrument in your own fleet, over your own first quarter, and the answer is yours rather than ours.