A pallet waits at a handover station. The autonomous mobile robot (AMR) that should collect it is queued behind a forklift. Meanwhile, in a server room two buildings away, the nightly export job that feeds the quality system failed at 2 a.m., and nobody noticed until the morning shift. Neither problem is a robot problem or a database problem. Both are coordination problems.
Factories do not lack automation. They lack coordination between automations. Machines are automated by PLCs. Data collection is automated by SCADA and historians. Material flow is automated by AGVs (automated guided vehicles) and AMRs. Production orders are automated by MES and ERP. Each layer works. The failures hide in the handoffs between them, where no single system is in charge.
Unified orchestration closes that gap. One control plane coordinates data pipelines, IT and edge infrastructure, application integration, and business processes, with agentic AI governed across all of them. This is not a new data bus, not a new MES, and not a robot controller. Orchestration is the layer that decides what runs, in what order, and what happens when a step fails. This article maps that concept to manufacturing and logistics, from the shop floor to the cloud.
The Automation Silos of a Modern Factory
Walk through any large plant, however far along its Industry 4.0 roadmap, and you find at least four orchestration silos, each grown for good reasons.
- OT Data Silo: Sensor and machine data moves through OPC UA servers, MQTT brokers, and streaming platforms toward historians and cloud analytics, with a Python-based orchestrator scheduling the analytics pipelines on top.
- Plant IT Silo: Hundreds of industrial PCs, edge servers, and file transfer jobs stay alive, often held together by scheduled tasks and scripts written a decade ago.
- Application Silo: MES, ERP, warehouse management, and quality systems connect through point-to-point interfaces.
- Business Process Silo: Approvals, maintenance workflows, and exception handling run sometimes in a BPM tool, more often in email and spreadsheets.
Each silo has strong tools. The cost is not inside any of them. It sits at the boundaries: the ML model that should retrain when new production data lands but does not, the deployment that succeeds on the edge cluster but never informs the MES team, the maintenance approval that lives in an inbox while a machine idles.
Where Orchestration Sits in the ISA-95 Stack
Manufacturing readers are rightly allergic to IT vendors who blur the line to the control loop. So the boundary comes first.
The hard real-time loop is off limits. PLC logic, safety functions, SCADA control, and the traffic management of an AMR fleet run under deterministic guarantees: fixed cycle times, safety certification, and reactions that must arrive on time, every time. Event-driven orchestration is fast as well, and often reacts to an event within milliseconds. What separates the two worlds is determinism, and the certification that stands behind it, rather than raw speed. An orchestration engine retries and escalates when something runs late. A safety function has no such option.
In ISA-95 terms, the standard that defines where enterprise systems end and control systems begin, orchestration operates at levels 3 and 4 (manufacturing operations, business planning) and at the seams between them. It never reaches into levels 0 to 2 (sensors, PLCs, and the control logic that drives them).
The strict ISA-95 pyramid is flattening as Unified Namespaces (UNS), edge computing, and cloud analytics break through the old network layers. The logical boundaries between the levels still hold, and they remain the clearest way to decide what an orchestration platform should coordinate and what it should leave to the control loop.
How the Unified Namespace Relates to Orchestration
The data movement layer is a different job as well. The dominant pattern here is the Unified Namespace: an event-driven architecture that connects machines and applications, organizes data in a predictable hierarchy, and makes it available through publish-subscribe.
The most common implementation uses an MQTT broker as the backbone with Sparkplug B defining topic structure and payloads, while OPC UA provides structured access close to the machines. OPC UA, MQTT, and Kafka form the trinity of data streaming in industrial IoT: they solve different parts of the problem and are strongest together, carrying machine data into enterprise and cloud analytics. The UNS structures live OT data. On the IT side, data products turn that stream into governed, reusable assets with schemas, ownership, and access control. Two complementary patterns in one pipeline.
The Data Integration Landscape 2026 maps that layer vendor by vendor and deliberately places workflow orchestration outside its scope.
None of that is orchestration. The UNS and the streaming layer move data. Orchestration decides. It reacts to an event on the namespace, triggers the retraining pipeline, coordinates the schema change across consumers, opens the ticket when a connector dies, and requests a human approval before anything touches production. One layer moves the data and the other coordinates the work around it. Keeping them separate is what makes both reliable.
Orchestrating Data Pipelines from Sensor to Lakehouse
The standard telemetry path runs from PLCs through OPC UA into an MQTT broker, gets normalized into the Unified Namespace, streams through Kafka into a cloud lakehouse, and feeds dashboards and ML models.
Every piece of that pipeline has an owner. The steps around it usually do not. Which job triggers model retraining when a new production batch completes? What coordinates the rollout when a topic structure changes and fourteen consumers need to follow? And who notices when the daily quality report did not run? Today the answers are cron jobs on a VM, a notebook someone runs manually, and hope.
This is exactly where a governed orchestration layer earns its keep: event-driven triggers on data arrival, dependencies across tools, retries with backoff, and an audit trail that shows what ran and why. The pipeline stays what it is. The coordination around it becomes explicit, versioned, and observable. Workflow orchestration and process intelligence belong together here (see the Process Intelligence Landscape 2026): one executes the flows, the other shows how they actually run and where they stall.
Where Orchestrators Fit in Manufacturing
Most manufacturers already run an orchestrator without calling it that. The data science team that builds quality prediction, energy optimization, or predictive maintenance models schedules its pipelines with a workflow orchestrator such as Airflow, Dagster, or Prefect.
These tools are strong in their home domain, which is data engineering in Python. Airflow brings the largest ecosystem, and Airflow 3 modernized the engine with event-driven scheduling, while the core model stays the same: pipelines as Python code, built by data teams. Dagster’s asset-centric model pairs naturally with the data product thinking that is arriving in IT/OT architectures, and Prefect makes dynamic Python workflows simple for teams that live in notebooks. The two are now one company: Prefect acquired Dagster Labs in July 2026, bringing the two most widely adopted Airflow successors under one roof, with both products continuing. The deal is a signal for the whole category: orchestration is consolidating, and both companies positioned the merger around AI agents rather than data pipelines.
Kestra takes a different route. Workflows are declarative YAML definitions instead of Python code, any language runs inside a task, and human approvals, infrastructure steps, and event-driven triggers are native concepts of the engine rather than extensions. That design targets exactly the scope of this article: one platform coordinating data pipelines, plant IT, applications, and business processes, which is why it appears throughout the categories here instead of only in this section. The counterpoint belongs in the same paragraph: a team that lives entirely in Python-native asset pipelines loses little by staying where it is. The difference shows up the moment a workflow has to leave the data domain.
Where Python DAGs Reach Their Limits
The trade-offs of the Python-native tools appear at the plant boundary. Workflows are Python code, so every contributor must be a Python developer. The automation engineer who knows the line and the SAP team that owns the order data can neither read nor extend the DAG, the directed acyclic graph of Python code that defines each pipeline.
The scope is data: a Python DAG has no native concept of a human approval, an infrastructure provisioning step, or a patch window on a line PC. Plant reality adds operational friction, since Python dependency management inside an air-gapped network is a project of its own, and a full scheduler stack is heavy for an edge box next to the line. Governance such as fine-grained RBAC and audit trails often lives in commercial tiers or bolt-ons. None of this is a flaw in the tools. They were built for data teams in connected cloud environments, and there they shine.
Unified orchestration does not rip these tools out. It coordinates them. The Python DAG keeps running exactly as before, while the control plane triggers it on a production event, consumes its completion, and carries the flow onward into the work order in the maintenance system (CMMS), the ERP check, and the human approval that a data pipeline could never model. Teams that want to consolidate later can migrate pipeline by pipeline. Teams that prefer to keep their tooling still gain the coordination layer across it.
Plant IT and Edge Infrastructure: The Shop Floor Windows PC Problem
The least glamorous silo is the most instructive. Every plant runs fleets of Windows industrial PCs: machine terminals, label printers, vision stations, line servers. Walk deeper into the halls and the operating systems get older. Windows XP still drives machine terminals in many brownfield plants, and somewhere an embedded DOS box runs inside a machine controller that has been in service since the nineties.
The reason is structural: A production line runs for twenty or thirty years, operating system support ends after roughly ten, and the machine vendor certified exactly one version. So the machine outlives every OS that ships with it. Each end-of-support wave forces the same exercise: migration planning across hundreds of devices that can only be touched during planned downtime windows, with paid extended support as the expensive bridge for everything that cannot move in time.
Legacy Schedulers and Undocumented Scripts
What actually runs on those machines: Windows scheduled tasks that copy CSV files to a share at midnight, batch scripts that restart a driver, agents of enterprise job schedulers installed years ago. In many plants, the same commercial workload automation platforms that run overnight settlement in banking also run MRP cycles, quality batch exports, and production planning jobs. The market has consolidated under a small number of owners, with BMC (Control-M), Broadcom (Automic, AutoSys), and Redwood (ActiveBatch, RunMyJobs, Tidal) holding most of the installed base. Licensing runs into seven figures annually at large enterprises, with volume-based meters and double-digit annual escalators that penalize every architectural improvement.
This is workload automation in its most fragile and most expensive form. The commercial platforms at least have change tracking. The scripts around them have no version control and no audit trail, and the institutional knowledge behind them retires with the person who wrote them.
Bridging the Gap Between GitOps and Cron Jobs
At the same time, the modern edge is arriving next to the legacy: small Kubernetes clusters running directly in factories have become a foundational pattern in automotive and manufacturing, managed through GitOps and fleet tooling. The result is a split-brain plant: declarative, git-driven automation on the new edge stack, and undocumented scripts on the old one.
An orchestration layer that spans both is the pragmatic bridge. Patch sequences coordinated with downtime windows and human approvals. File transfers turned into monitored, retryable workflows. Legacy scheduler jobs migrated step by step into definitions that live in Git. Modernization becomes a managed path instead of a big bang, which matters in an environment where downtime is measured in lost production.
MES, ERP, and the Human in the Loop
The application silo is where end-to-end value shows up.
Predictive Maintenance: The Canonical Example
Take predictive maintenance, because it crosses every domain. An anomaly model flags a bearing. A work order must be created in the maintenance system, parts availability checked in the ERP, a technician assigned, the intervention scheduled into a downtime window, and the completion confirmed back to SAP. Half of those steps are API calls. The other half involve people. A workflow that treats the human approval as a first-class step, with the same audit trail as the API calls, is the difference between a demo and a production process.
Intralogistics and the VDA 5050 Boundary
Intralogistics is the sharpest illustration of the boundary. Mixed fleets of AGVs and AMRs are now coordinated through the VDA 5050 standard, a uniform, manufacturer-independent interface between vehicles and a central master control. The standard evolves actively, with version 3.0 as the latest major release, and a recent wave of cross-vendor certifications spans fleet software and robot vendors. This is orchestration of vehicles. It belongs to the fleet manager, on the hard real-time side of the boundary.
The layer above is empty in most plants. Transport demand originates in the MES or ERP when an order releases. Someone has to turn that production event into a transport order, hand it to the fleet manager, watch for exceptions, escalate when a handover times out, and confirm delivery back to the business system.
The fleet manager orchestrates robots. Unified orchestration orchestrates the fleet manager, together with everything around it. It never talks to a vehicle, and it should not want to.
Orchestration vs Hard Real-Time Control
The fleet manager example illustrates a boundary that applies everywhere in manufacturing. Event-driven orchestration and hard real-time control both operate in milliseconds, and from the outside they can look alike. The difference is not speed. An orchestration engine is fast, but it retries and escalates when something runs late. A safety PLC or an AMR traffic controller has no such fallback: a missed deadline is a system failure.
What separates the two is deterministic guarantees and safety certification, and that distinction holds for SCADA, DCS, and every fleet manager on the plant floor.
Deploying Unified Orchestration Across Edge, Air-Gapped, and Cloud
Manufacturing is the hardest deployment environment in the enterprise. OT networks are segmented into security zones under IEC 62443. Some plants have no internet path at all, by regulation or by choice. Converged OT and IT networks expand the attack surface, which is why defense in depth with segmentation and DMZs remains the rule.
This has a direct consequence for orchestration: the control plane must run where the work runs. A SaaS-only orchestrator cannot coordinate workflows inside an air-gapped pharma plant. The realistic topology is hybrid and bidirectional. Local orchestration inside the plant handles everything latency-sensitive or disconnected. Cloud analytics consume aggregated data upward. Decisions, models, and configuration flow back down.
Workflows on both sides need coordination across that boundary, with the plant able to operate autonomously when the WAN link is down. Open source matters here for the same reason: a self-managed control plane with an open core passes the sovereignty and procurement reviews that another proprietary SaaS dependency does not. In manufacturing, deployment flexibility is an architectural requirement.
Agentic AI on the Shop Floor Needs Governance First
Agentic AI is the loudest topic in industrial software, and the field reports are more sober than the keynotes. Human-in-the-loop remains a core industrial AI requirement, because a bad decision can stop production, damage equipment, and create audit issues. Agentic AI is currently strongest in recommendations, exception handling, and supervised execution, while multi-agent orchestration remains rare. Analysts nonetheless see agentic AI platforms as the largest new market opportunity in smart manufacturing beside robotics.
Both findings point in the same direction. Agents will act across all four domains:
- Root cause analysis: an agent correlating a quality deviation back through the OPC UA tags that preceded it.
- Vision and calibration: an agent flagging when a camera station drifts out of specification.
- Production scheduling: an agent rebalancing MES orders around an unplanned downtime window.
- Maintenance triage: an agent ranking open work orders by production impact before a human decides.
These agents analyze telemetry, touch infrastructure, call MES APIs, and participate in business processes.
Unified Orchestration as the Architecture for Smart Manufacturing
Three layers, three jobs: At the bottom, event-driven integration moves the data: OPC UA and MQTT at the machines, a Unified Namespace for structure, streaming into the enterprise and the cloud. In the middle, workflow orchestration with process intelligence decides and coordinates: triggers, dependencies, retries, approvals, and the visibility into how work actually runs. On top, trusted agentic AI acts, governed and with human oversight. The hard real-time control loop stays untouched beside all three.
The good news for manufacturers: nothing on the plant floor has to be replaced. The MES, the fleet manager, the historian, and the Python DAGs all stay. What is missing is the connective layer that coordinates them as one system, from an OPC UA tag change to an SAP confirmation, across edge, air-gapped, and cloud. Start with one workflow that crosses a silo boundary, put it under version control and governance, and grow from there. The plants that master coordination, not just automation, will set the pace.
To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.
