Why orchestration is the better answer to industrial AI’s semantic bottleneck

Collaboration Synergies Inc. · Author of The Intelligent Digital Thread · November 2026

AMT has put its finger on the real problem with industrial AI. In a recent IMTS article, “Getting Operations Ready for Industrial AI: Addressing the Technology Stack,” Ryan Kelly, AMT’s vice president of technology, argues that the bottleneck isn’t the AI at all. It’s the semantic layer — the place in the technology stack where systems agree on what their data means.

“Each system has its own definition of what a ‘part,’ an ‘operation,’ a ‘downtime event,’ or a ‘work order’ means. Joining data across systems requires a translation project every time, and the translations are lossy.” — Ryan Kelly, AMT

The numbers support him. The article cites 63% of organizations lacking, or unsure they have, the data practices AI needs, and a Gartner prediction that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data. As Kelly puts it: “The AI is not the hard part. The stack beneath it is.”

I agree with the diagnosis. I want to offer a different treatment.

The current condition: integration

Most of our industry still answers the semantic problem with integration. We move data between systems — PLM to MES, MES to ERP, supplier to quality — and translate at each connection. Then we reconcile afterward.

The trouble is structural. Six systems connected point to point means 15 connections and 15 translations, each one losing some meaning. Every engineering change ripples through them again. And because records move after the fact, they arrive stripped of the context that would tell the receiving system what they meant.

AMT’s own readiness map makes the point. Across the product life cycle, from RFQ through delivery, it rates the semantic layer and connectivity as gaps — white space — in design, engineering and process planning, and only “emerging” almost everywhere else. Workflow systems, by contrast, are largely established. We have the systems. We lack the shared meaning between them.

Figure 1. Integration translates at every connection; orchestration maps each system once and connects the steps.

The alternative: orchestration

Orchestration starts from a different question. Instead of asking how to move records between systems, it asks what information each step of the process needs.

Each step is defined by four things: the information it needs and where that comes from, the data it collects, the decision that follows, and what it records. A process engine then runs that model against each serialized unit — from design, through suppliers and production, to delivery. Existing PLM, MES and ERP systems stay in place as systems of record. What changes is how they are connected: through the steps, not just through each other.

Orchestration does not make the semantic problem disappear. An engine that runs steps across PLM, MES and ERP still has to know what each system means by a part or an operation. The claim is narrower and more useful: orchestration makes the semantic problem smaller, local and solvable once, while integration has to solve it again and again.

Five reasons orchestration is better — and easier

1. Meaning is set at the point of use

Kelly’s examples are ambiguous mostly because data arrives without context. An orchestrated step asks for information while the work is happening — for this unit, at this step, in this configuration. The request carries the context, so the meaning is fixed exactly where the data is used.

Figure 2. Anatomy of one orchestrated step: the request carries the context, and the result is recorded against the unit.

2. You don’t need enterprise-wide agreement on definitions

The slow part of building a semantic layer is getting every system to agree on everything. Orchestration only needs agreement on the information its steps actually use. Start with one product family and the terms its steps need, and let the shared vocabulary grow step by step.

3. Translation work scales differently

With point-to-point integration, the work grows with the number of connections. With orchestration built on standards — STEP AP242 for definition, QIF for inspection, ISA-95, MTConnect and OPC UA for operations — each system maps once to the standard, and the process model is written in standard terms. When the definition changes, it is referenced again, not translated again.

4. It fills the white space instead of waiting for it

AMT finds the semantic gap in design and process planning. Integration cannot close a gap at either end of a connection. Orchestration can, because the step definition is itself the semantic contract, written in process planning. That is precisely the “interconnection and recombination” AMT identifies as the opportunity: connecting what already exists rather than replacing it.

5. The data is AI-ready when it is captured

Integration produces data that must be cleaned and reconciled before AI can reason across it. Orchestration records each step against the unit, in shared terms, as it happens. Kelly argues that the semantic layer “creates data assets that did not previously exist.” A per-unit record from design through delivery is exactly that kind of asset.

Anticipating the objections

• “Middleware and canonical data models already solve this.” They reduce the number of mappings, but they normalize data, not process. They don’t know which unit, step or decision a piece of data belongs to.
• “A unified namespace does this.” A unified namespace publishes the current state of the plant. It doesn’t define what a step needs or what decision follows. The two are complementary: orchestration can read from and write to it.
• “You still have to connect to every system.” True. Each system still needs an adapter to the standard. The claim is that orchestration is easier to sustain and extend, not that it needs no integration.
• “Is it really easier at the first plant?” Not by much. The advantage compounds with each engineering change, each additional line or plant, and each supplier brought into the thread.
• “Where is the proof?” Neutral, head-to-head evidence is still thin. It should be measured: translations maintained, time from engineering change to the station, manual reconciliations per change, and the effort to add a second line or supplier.

The bigger picture

This argument sits at the heart of The Intelligent Digital Thread: the defining differentiator of a digital thread is item specificity — tying all data to the individual serialized unit rather than to batches, lots, part numbers or work orders. Orchestration is how that becomes practical across a whole team, from product design through customer delivery.

AMT is right that the AI is not the hard part. The stack beneath it is. The question is how we build that stack. We can keep translating data after the fact, one connection at a time. Or we can define meaning where the work happens, once, and let every step — and every AI that follows — build on it.

Integration translates data after the fact. Orchestration defines meaning where the work happens.

Source: Robert Schoenberger, “Getting Operations Ready for Industrial AI: Addressing the Technology Stack,” IMTS / AMT, October 27, 2026, drawing on AMT’s “Industrial AI & Digital Manufacturing Report 2026.” Figures are original illustrations; the step example is illustrative.