Software-Defined Operations Writes the Decision Down for AI Agents
Software-defined operations means the logic behind an operating decision lives in one place in software. Today it is spread across spreadsheets, procedures, control settings, approval routes and the experience of a few senior people.
That has been tolerable for decades because people held it together. It stops working when you add AI agents. An agent can only work inside a decision that is written down somewhere it can read, with limits it can check. If the logic sits in ten places, the agent sees one of them, and nobody can say with confidence what it is allowed to do.
This is why so many industrial AI pilots stall after the demonstration. The model works. The decision it is meant to support was never defined in a form a machine can use, and changing it means changing every system and person that holds a piece of it.
Today we published a short book on software-defined operations. It explains how to give a decision one definition in software, connect it to the systems you already run, and change it without losing track of what it affects.
Related: Software-Defined Operations: Change How Operations Work
What a decision definition contains
Most plants can name their important decisions. Few can point to where any one of them is defined.
A decision definition is a small set of things written down in one place. The information the decision uses, and what each value actually means. The requirement that applies, such as a minimum reserve, a quality limit or a maintenance window. Who may approve the response, and under which conditions. The actions that are permitted, and the systems that carry them out. When those pieces live together in software, a team can see the whole decision at once and test a change before it reaches the plant. When they are spread out, the decision exists only in the moment someone puts it together.
The book makes one distinction that I think most AI programs miss. Changing an input and changing the decision are different kinds of work. A new forecast asks the existing decision to run again. A new requirement changes how the operation decides from now on. If you cannot tell the two apart in your systems, you cannot tell an agent which one it is allowed to do.
Why agents expose the gap
Experienced people reconcile scattered logic without noticing. They know the spreadsheet is a week out of date, that the procedure was updated but the screen was not, and that a certain approval is skipped on night shift. That knowledge never gets written down, because people carry it.
An agent has none of that. It reads what it is given and acts within the limits it can check. If the limits are not written down, the agent either does nothing useful or does something nobody approved. Neither outcome survives a review by operations, engineering or safety.
This is also where governance becomes practical. The organization’s rules about what an agent may see and do have to sit somewhere they are applied every time, before any action goes ahead. We call that the control plane. It is a set of rules the operation owns, applied in software, with a record of every decision it allowed or stopped. It does not replace the control system. The control system still runs the equipment and its protective functions, exactly as it does today.
A test you can run this week
Pick one decision that matters to your operation. Something that happens often, costs money when it goes wrong, and involves more than one team. Then ask four questions.
Where is this decision defined? Point to it. Who owns that definition, and who approved the current version? When the requirement last changed, what did you have to update, and how long did it take? After the decision was made, what record remains of what was seen, what was decided and who approved it?
If the answer to the first question is a spreadsheet, a procedure, two screens and one person’s memory, you have found your first software-defined operations project. The answer to the third question tells you what every future change will cost, with or without AI.
What software-defined operations does not mean
The term “software-defined” now appears in many places. Software-defined automation separates control software from the controller hardware it runs on. That is valuable work, and it sits at a different level.
Software-defined operations is about the decision above the control system: how the operation decides what to do, who approves it, and how that changes over time. Your existing systems keep doing their jobs. Some changes will still need new measurements or engineering work, and a good definition makes that visible early instead of discovering it during commissioning.
Where to start
Start with one decision. Define it in one place, connected to the systems that already hold its information. Run it with people making and approving every response. Then change one requirement under control and check what the change affected.
Authority for an agent should grow only where that evidence supports it. The book describes three stages. In Monitor & Predict, systems organize information and people decide. In Advise & Guide, the system proposes a response and people review it. In Coordinate & Autonomize, agents carry out specific actions within limits the organization grants. The architecture stays the same at every stage. Only the authority changes.
At XMPro, this is the platform we build. Data Streams connect to the systems a plant already runs, our Operational Context Engine keeps the meaning of the data, agent teams and other AI tools work on the decision, and the control plane decides whether an action goes ahead. The definition itself belongs to the customer.
The decision comes first
The question to ask of any industrial AI program is where the decision lives. Model choice, data platform and agent framework all come after it. If nobody can point to the decision, the program is automating something it cannot see. If the decision is defined, an agent becomes one more participant working inside rules the operation already understands.
The book, Software-Defined Operations: Change How Operations Work, follows one decision through a requirement change from start to finish. You can download it at xmpro.com/software-defined-operations.
Related: Software-Defined Operations: Change How Operations Work
Pieter van Schalkwyk is the CEO of XMPro, specializing in industrial AI agent orchestration and governance. Drawing on 30+ years of experience in industrial automation, he helps organizations implement practical AI solutions that deliver measurable business outcomes while ensuring responsible AI deployment at scale.
He authored the Industrial AI Agent Manifesto, published by the Digital Twin Consortium in February 2026, a governance framework for trustworthy autonomous operations
Our GitHub Repo has more technical information. You can also contact myself or Gavin Green for more information.
Read more on MAGS at The Digital Engineer
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 6 October 2026.
