Software-Defined Operations: An Architecture for Agentic Operations
Software-defined operations is an architectural pattern that decouples operational decision and coordination logic from the underlying applications, automation systems, and physical infrastructure, enabling that logic to be configured, changed, and governed through software.
Agentic Operations needs an architecture that lets an industrial enterprise change how it makes decisions without rebuilding every system involved in those decisions. Software-defined operations provides a useful pattern for that architecture.
The familiar idea is separation. In software-defined networking, network control is separated from packet forwarding, making network behavior programmable independently of the devices carrying the traffic. That separation is central to the SDN definition.
Industrial operations can apply a related principle. Make operational decision and coordination logic configurable across the systems that observe conditions and execute responses. The scope includes which context a decision uses, which objectives it serves, how competing priorities are resolved, who must approve a response, and which actions are permitted.
That is what becomes software-defined.
Much of this logic already exists somewhere. It may sit inside an application, an integration script, a procedure, or the judgment of an experienced operator. The architectural task is to make the relevant parts explicit and separate them from particular application and integration implementations. The operation gains a way to change its response without changing every system that participates in it. That separation can be logical and distributed; it does not require one central server to make every decision.
The separation is logical, not a required deployment topology. Authority is chosen for each decision; coordination can also operate under human approval.
Consider an illustrative maintenance decision. A pump shows signs of deterioration. The condition-monitoring system supplies the signal, the maintenance system holds its work history, and the production schedule establishes when the equipment is needed. A response also depends on asset criticality, available alternatives, and the current operating constraints. An operator brings these facts together and decides whether to investigate, request work, or escalate the issue.
Now change the approval policy for work requests involving critical equipment. In a software-defined approach, that policy should be identifiable and changeable within the decision process. The approved change can be tested against representative cases while the existing interfaces continue to supply condition, history, and scheduling information. Changing who must approve a response should not require rebuilding how the pump’s data is collected. Where it does, the implementation has coupled two responsibilities that would benefit from separation.
This builds on established engineering ideas. Configurable workflows, rules engines, service interfaces, and software-defined automation already address parts of the problem. The phrase itself has prior industrial use. My argument concerns where to apply the pattern: to operational decisions and coordination that span those systems, with a clear boundary between the logic being changed and the services it depends on.
Software-defined automation commonly focuses on separating automation logic from hardware dependencies. The operations pattern extends the discussion to decisions spanning production, maintenance, quality, energy, and other operating concerns. These scopes can overlap. Existing control systems continue to perform their assigned functions, safety systems retain their responsibilities, and changes affecting the physical process still require the appropriate engineering review.
A digital twin can contribute the representation, relationships, and models needed to evaluate a response. It may also support simulation and reasoning. Software-defined operations describes how the decision process uses that knowledge to coordinate a response and how that behavior can be changed. The distinction is between modeling an operation and defining how decisions are made from that model. A single implementation may support both.
Agentic Operations adds agents that pursue operating objectives, evaluate changing conditions, and coordinate work. The software-defined architecture gives them context, tools, decision boundaries, and paths to action. It can specify the constraints and authority under which an agent reasons while leaving room for the agent to propose a response that was not written as a fixed sequence of steps.
An agent’s ability to propose an action and its authority to execute that action are separate design decisions. A more capable model may improve the proposal. The operating architecture must still establish whether the action is permitted, whether human approval is needed, and what happens when evidence is incomplete or systems disagree. Those conditions must be enforced through the action path as well as communicated to the agent.
This also explains why the architecture has value before a customer is ready for autonomous execution. The same operating context and decision process can help people monitor and predict, advise and guide a response, or support agents that coordinate and execute permitted actions. Autonomy becomes a choice made for each decision within the architecture. A plant can allow one bounded activity to proceed automatically while keeping another under direct human control, without treating the whole facility as being at one maturity level.
Recommended by LinkedIn
The economic case depends on reuse. A decision pattern developed for one site may apply elsewhere even when equipment identifiers, operating limits, and approval responsibilities differ. The architecture should make those local dependencies visible so the team can distinguish reusable logic from configuration that needs adaptation and validation. Copying a workflow to another plant is only a starting point; its assumptions still have to be checked against that plant’s conditions.
For an engineering leader evaluating this approach, I would ask for a demonstration built around one real decision:
Identify the decision logic separately from its data sources, application screens, and action interfaces. Change one approval policy or constraint, and show which parts of the implementation remain unchanged. Test an allowed response and one that must be blocked or escalated, then trace the result to the policy and evidence used. Apply the pattern to a second representative site, showing what is reused, what changes, and what requires revalidation.
Claims about versioning, deployment, and recovery should be demonstrated too. Recovering an earlier software configuration cannot undo a physical action already taken. The value comes from controlled change with known limits, including evidence that the revised decision process behaves as intended.
At XMPro, this is the architectural direction I see beneath Agentic Operations. Our reference architecture brings operational context, human applications, agent reasoning, governed action paths, and decision evidence into a shared operating foundation. Software-defined operations gives that design a familiar architectural explanation while leaving the implementation open to examination.
An agent demonstration shows how a system handles today’s scenario. A software-defined operations demonstration should also show how the enterprise changes tomorrow’s response. That is the capability an operations team will need each time a procedure changes, a new constraint appears, or a proven decision process needs to work at another site.
Software-defined operations is an architectural pattern that decouples operational decision and coordination logic from the underlying applications, automation systems, and physical infrastructure, enabling that logic to be configured, changed, and governed through software.
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
How this was made: I worked with ChatGPT to check sources, draft from my direction and edit. I do not publish anything I have not rewritten myself.
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 18 September 2026.
