Who Controls the Orchestration Controls the Plant
Gartner just called the placement of agent orchestration the most consequential architecture decision of the decade. In industry, the stakes are physical.
A recent Gartner note, “OpenAI for Agentic Systems: Harness the Platform, Avoid Vendor Lock-In” (Gartner subscription required), argues that orchestration is the control plane of an agentic system, and that whoever controls it controls the outcomes. The warning underneath it: embedding orchestration inside one AI platform looks convenient and quietly hands that vendor control of how your agents behave, with dependencies you cannot easily walk back.
I agree. In a factory or plant the same logic has teeth, because the outcomes are not documents and support tickets. They are setpoints, work orders, and physical state.
Two layers the word “agent” keeps merging
There is the model, and there is the orchestration layer around it, and most of the market talks about them as if they were one thing.
The model is the language and reasoning layer. It interprets a signal, summarizes a state, drafts a plan, makes a proposal. Even the ones with reasoning built in do one job, which is to turn inputs into language. They do not run anything. The orchestration layer is what runs. It governs intent, coordinates agents from more than one vendor, enforces policy, recovers when something goes wrong, decides what is allowed to happen, and executes it. The model supplies the language and the reasoning. The orchestration layer turns that into a governed action and lives with the result.
I have written before about creators and operators, and this is the same distinction one level up. A model that writes a block of code or drafts a plan is doing creator work, and doing it well. Deciding what happens next across a plant, inside the limits, and proving afterward that it was the right call, is operator work. The orchestration layer is where the operator logic lives, and it is not the model.
Creator Agents vs Operator Agents
You can see the inversion in the code. In a creator agent the model does most of the work: roughly ninety percent of it is the model generating, and ten percent is the harness that orchestrates and guards it. An operator agent is built the other way around. Around ten percent is the language model, and the other ninety percent is orchestration and decision logic, the objectives, the constraints, the coordination, the recovery, and the evidence. Same word, agent. Opposite center of gravity (and you can read it straight off our codebase.)
The operator layer has to sit above any one platform
That warning matters if you run operations, and it is less about anyone’s intent than about where the orchestration is built. When the orchestration and the operating context both live inside one vendor’s suite, that layer can only govern that suite. A plant does not run on one suite. It runs on equipment, control systems, historians, and applications from many vendors at once.
The big industrial software vendors are racing to add agents, and most of what they are building sits on the creator side: agents that help engineers design, simulate, generate, and document inside their own platforms. That work is real and it is valuable. It is also a different job from running the operation. The operator layer, the one that turns a signal into a governed decision across the whole plant, has to sit above all of those platforms. That means it has to be yours.
Owning the model is not the same as owning the orchestration. You can rent the smartest model in the world and still control nothing about how it acts in your operation, if the logic that governs it belongs to someone else.
How the logic is stored decides whether you can run it
The technical teams see this first. Pull apart one of these vendor agent frameworks and the orchestration turns out to be a pile of markdown files with prompts and ‘skills’ written into them. Your operating logic ends up as loose text, interpreted by whichever model reads it that day and written in that vendor’s dialect.The day you move to a different model it does not come with you, and you rebuild it from scratch. For creator-style work that is an afternoon. For an operator it means re-validating the whole rebuild against a live plant, which is not a cost you take on just to switch models.
Then there is versioning. Once you are running hundreds of agents across a dozen sites, keeping every one of them on the current version of a skill file is the spreadsheet problem all over again, and anyone who has tried to get five hundred people onto the same version of a spreadsheet knows how that ends. Operating logic that matters cannot live in copies that each agent or site maintains for itself, because then no two give the same answer, which for an operation is the whole point of having the logic at all.
Loose text is also a leak. The decision logic in an operator agent is often the most valuable thing the company owns: years of failure modes, operating envelopes, the judgment of engineers who have since retired. As a folder of markdown skills, that can walk out the door on a laptop or in a resignation. Plant operators ask about this early, because they have watched expertise leave before and have no interest in writing it all down in plain text for the next employer to inherit.
The way out is to hold the operating logic as parametric configuration you own, rather than prompt files living inside someone else’s framework. Define the objectives, the constraints, and the decision logic as parameters, and the model underneath becomes swappable without touching any of it. Parameters execute the same way regardless of which model reads them, which is what makes an operator agent model-agnostic in practice, and why the same agent can run on a frontier model today and a local one tomorrow. It also keeps the logic inside the platform you control rather than in files that copy, so the advantage stays with the operation when people leave.
What an industrial control plane has to do that an office one does not
Most of the orchestration writing right now assumes the agents live in email, chat, and back-office apps. Industrial is a harder and different problem.
The control plane for operations has to run where the consequence is, at or above the control system, not in a SaaS console. It has to enforce bounded authority, so an agent can act inside an approved envelope and not one step beyond it. It has to recover, because “the model had a bad day” is not an acceptable failure mode next to rotating equipment. It has to produce evidence that an engineer, an auditor, and a regulator can all read. And most of its logic is not a language model at all. In the systems we run, the overwhelming majority of the decision is process logic and engineering constraint, and the model is a small, bounded part of it. The model proposes. The policy disposes.
Recommended by LinkedIn
The Model Proposes. The Policy Disposes
There is a reason this matters more every month. The people who run plants keep telling me the same two things: **the systems are getting more complex, and the experienced people are leaving.**They need agents that can carry operating decisions. They cannot run those agents on a frontier model that changed under them last night, over a connection that drops, with no way to prove what happened. Call that what it is, a liability with a chat window, not a control plane.
A creator can wait. An operator cannot.
Downtime is where the two part ways. A creator agent can go offline for an hour and the cost is an inconvenience. You wait, you retry, you write the summary later. An operator running a plant gets no such grace, because the compressor does not pause while a cloud endpoint returns errors.
And it happens. The big frontier providers all publish status pages, and those pages all show extended outages. One of the major ones had hours of degraded and unavailable service just this week. If your operating decisions depend on a model sitting in someone else’s cloud, you have accepted an availability risk that no control room would tolerate anywhere else in the stack.
Frontier models publish status pages - here is one example from this week
The answer is the right model in the right place. Most operator decisions do not need frontier reasoning at all; they need to run the observe, reflect, plan, act loop reliably, every time, inside the plant. A capable local model, governed by the orchestration layer, does that at the edge, air-gapped if it has to be, with no dependence on a connection that can drop. Keep the frontier model for the reasoning that is genuinely hard. It has no business being a single point of failure between your operators and their equipment.
What actually runs your plant
Frontier models are becoming a commodity, and for an operator that is good news. The model was never the thing that ran your plant. What runs your plant is the layer that turns a signal into the right decision, keeps it inside safe limits, coordinates the people and the agents, and leaves a record you can stand behind. The model is one input into that. Swap it out next year and the operation should not notice.
So here is the question to put to anyone selling you industrial AI. If the product is a database with a chat box on top, it will not survive contact with a real operation, because that part is now trivial to rebuild. If it is the layer that decides what happens next across the plant, holds the line on safety, and shows its work, that is the part you actually depend on. Build on that, not on whichever model is winning this quarter.
Operators are starting to say this in their own words. At an energy conference this week, a senior digital leader at a major oil operator made the case that operators should build and own the context layer in their business rather than rent it from a vendor. He is right, and it reaches one step further than it usually does. The orchestration and the decision logic are part of that context, the operating end of it, the part that turns what you know into what the plant does. Owning it does not mean building a platform from scratch, because no operator wants to maintain one. It means owning the IP: the logic, the rules, the constraints, and the context, held as configuration you control on a platform built to run it. The model and the platform can change underneath you, and the logic stays yours.
What this means if you run operations
The platforms would love you to spend your time deciding which model or which agent vendor to standardize on. Every answer to that leaves them holding the orchestration, which is why it is the debate they keep steering you into.
**What decides control is who owns the orchestration.**Own the logic for that layer and you can swap models as they improve, mix vendors where it suits you, and raise autonomy at the pace your risk tolerance allows. Cede it, and you will spend the next decade renting your own operations back from whoever you handed it to.
The most consequential decision really is where the orchestration sits. In an industry where a wrong call releases a hydrocarbon or trips an interlock, it is also the one you least want to get wrong by default.
Related: Operators, Not Creators
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 agentic operations at The Digital Engineer
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 25 June 2026.
