← /essays
Issue #005·Oct 18, 2026·10 min read

Beyond Intelligence: Why Orchestration Matters in the Age of AI

EA
Erik Alabay
Author

From intelligent agents to coordinated execution across the end-to-end product lifecycle.

Picture an industrial company that has done everything the AI playbook recommends.

It has a service agent that reads warranty claims. An engineering agent that searches the PLM system. A procurement agent that watches supplier lead times. A planning agent that tunes the production schedule. Each one is good at its job.

Then a bearing starts failing in the field.

The service agent spots the pattern within days. The engineering agent drafts a fix against revision C of the assembly. Meanwhile the procurement agent, seeing healthy demand, reorders revision B parts. The planning agent keeps the line running at full rate on the old design. Service technicians receive repair instructions for a configuration half the installed base doesn't have.

Every agent performed well.

The company still kept shipping the defect for another six weeks.

Nothing was wrong with the intelligence. What was missing was coordination: shared context, sequenced decisions, and someone, or something, responsible for the outcome rather than the task.

AI creates capabilities. Orchestration turns those capabilities into business outcomes.

The Enterprise Has Always Had an Orchestration Problem

None of this is new.

An industrial company manages requirements in one tool, engineering data in PLM, transactions in ERP, factory execution in MES, and the installed base in a service platform. Each system does its job. Business processes ignore the boundaries between them.

Consider the end-to-end product lifecycle:

Strategy → Requirements → Engineering → Sourcing → Manufacturing → Distribution → Service → End of Life

A design change affects sourcing. A supplier issue affects manufacturing. A field failure triggers a redesign. Value is created across the chain, not inside any single application, as I argued in #001, The Product Value Chain.

Enterprises have spent thirty years on this problem: integration platforms, workflow engines, business process management, enterprise architecture. AI does not remove it.

It changes its nature.

Figure 1 — Intelligence is not enough. Capable agents working on fragmented context produce locally correct, globally wrong results. Orchestration connects them through shared product context and governed decisions.

From Automation to Intelligent Orchestration

Traditional automation coordinates predefined work. An event triggers a workflow; the workflow follows rules, calls APIs, assigns tasks and routes exceptions to people. That gives you consistency, repeatability and control, as long as the work can be specified in advance.

Much of the work that matters can't be. Investigating a field failure means reading service notes, comparing configurations, forming hypotheses and deciding whom to involve. That is judgment, not rules.

AI agents can now do a meaningful share of it. They interpret unstructured information, reason over ambiguity, choose tools and plan multi-step actions.

What changes with AI is the nature of the work being orchestrated.

We are moving from coordinating deterministic steps to coordinating a mix of deterministic workflows, probabilistic agents and human decisions. That mix is the hard part. A workflow engine executes what you told it to. An agent produces outputs that are usually right, sometimes wrong, and occasionally confidently wrong.

So the enterprise needs more than capable agents. It needs to know what each agent is authorized to do, how its outputs are verified, when a human must decide, and how every action is recorded in the systems that carry legal and financial weight.

The early evidence says most organizations are underestimating this. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing cost, unclear value and weak risk controls. That is not an intelligence shortage. It is an orchestration shortage.

Three Levels of Orchestration

"Orchestration" is used for very different things, from routing a prompt to a cheaper model to running a cross-functional engineering change. I find it useful to separate three levels, distinguished by what is being coordinated.

Figure 2 — Three levels of orchestration. Each level coordinates a different unit of work and is governed by a different constraint. Levels 1 and 2 are becoming platform features; Level 3 depends on context only the enterprise owns.

Level 1 — Model and Technical Orchestration coordinates calls. Which model handles which request, what data is retrieved, which tool is invoked, at what cost and latency. A small model classifies service tickets; a larger one reads a technical manual; a retrieval step grounds both in product data. The governing constraint is cost, latency and reliability.

Level 2 — Agent and Workflow Orchestration coordinates tasks. Several agents, workflow steps and human approvals working toward one defined result, such as a completed impact analysis. The orchestrator keeps state, handles dependencies and knows when a step belongs to an agent, a rule or a person. The governing constraint is workflow state and control. The goal is not maximum autonomy; it is reliable execution with the right mix of intelligence, automation and human judgment.

Level 3 — Enterprise Orchestration coordinates commitments. This is the level where a decision in one function binds others. An approved engineering change commits procurement to new parts, the factory to a new routing, and service to new instructions, each from a specific serial number or date. The governing constraint is decision rights and authoritative records: who may decide, which system owns the truth, and which product configuration the decision applies to.

The distinction matters because the levels mature differently. Calls and tasks are generic; every vendor can coordinate them, and they are rapidly becoming platform features. Commitments are specific to your products, your organization and your data.

That is where the strategic opportunity sits, and where it is hardest to buy.

Orchestrating the End-to-End Product Lifecycle

Return to the failing bearing, this time orchestrated.

Figure 3 — Orchestrating an engineering change across the end-to-end product lifecycle. Agents analyze and recommend; the orchestration layer coordinates and holds context; enterprise systems execute authorized transactions and keep the authoritative record.

  1. Detect. A service agent links warranty claims and field reports to a recurring failure, and to the specific configurations and serial ranges affected.
  2. Assess engineering impact. An engineering agent pulls the as-designed structure, change history and variant rules from PLM and identifies affected parts and product variants.
  3. Assess supply exposure. A supply agent checks inventory, open orders, supplier capacity and lead times for both the old and new part.
  4. Assess manufacturing readiness. A manufacturing agent evaluates the impact on the manufacturing BOM, routings, tooling and work instructions.
  5. Decide. The orchestration layer consolidates the findings into one decision package and routes it to the change board. People weigh the trade-offs and decide, including the effectivity: from which serial number, date or lot the change applies.
  6. Execute. Approved updates flow through governed interfaces into PLM, ERP, MES and service, each system enforcing its own rules.
  7. Verify. The process stays open until the factory builds the new revision, suppliers deliver it and field failures actually decline.

Three points are worth drawing out.

First, an AI agent may complete a task; enterprise orchestration must deliver the outcome. The outcome here is not "change approved". It is "defect stopped across factories and the installed base".

Second, PLM, ERP and MES don't become less important. They become more important. Agents interpret and recommend; systems of record enforce the rules and hold the truth. Orchestration connects them without replacing them.

Third, and most important: every step depends on knowing exactly which product we are talking about. Which revision, which variant, which serial range, which effectivity. Without a reliable digital thread, agents produce plausible recommendations about the wrong configuration, and an orchestrator just coordinates those errors faster. The opening scenario failed for precisely this reason.

AI doesn't make the old product-data problem go away. It makes it impossible to ignore.

The Emerging Orchestration Architecture

What does an architecture for this look like? Not one super-agent controlling every application. A more realistic picture has five layers.

Figure 4 — An illustrative reference architecture for enterprise AI orchestration. Business outcomes and decision rights sit on top; systems of record and the digital thread sit underneath; governance runs through every layer.

At the top sit business processes, outcomes and decision rights: what should happen, who owns it and how success is measured. Below that, the orchestration layer coordinates work, holds state and context, and manages approvals and exceptions. Below that, agents and models provide reasoning, retrieval and analysis. Below that, integration (APIs, events and, increasingly, open agent protocols) gives controlled access to enterprise systems. At the foundation, systems of record and the digital thread hold authoritative product, operational and financial data.

Running through all of them: identity, permissions, observability, audit and human oversight.

The hard questions are not model questions. How do agents exchange context? How are permissions enforced across five systems? What happens when an agent is wrong? How do you trace an action that passed through four agents and three applications? Who is accountable for the outcome?

Those are enterprise architecture, process and operating-model questions.

Who Will Orchestrate the Enterprise?

There is a competitive dimension to all of this, and in 2026 it has become explicit.

Every major software vendor now claims the coordination layer. Industry analysts name Microsoft, Salesforce and ServiceNow as early leaders in enterprise agent platforms, each approaching from a different base: productivity and cloud, customer data, IT workflow and governance. SAP comes from the transactional core. UiPath has repositioned from RPA to agentic orchestration.

Industrial software has entered the same contest. In June, Siemens launched Intelligence Center X, explicitly positioned as industrial AI orchestration with shared context and lifecycle intelligence. PTC's leadership argues the opposite side of the same coin: that AI is only trustworthy in engineering when it runs on governed systems of record such as CAD, PLM and ALM.

Underneath, the plumbing is standardizing. MCP (connecting agents to tools and data) and A2A (connecting agents to each other) now both sit under Linux Foundation governance.

So the strategic question is not which vendor has the smartest agents. It is:

Who controls the coordination layer between AI capabilities, enterprise applications, business processes and people?

Whoever coordinates work can influence which models are used, which tools are called, how data is accessed and how processes run. Over time that creates switching costs and commercial leverage. Enterprises should decide deliberately how much of that control they delegate, and to whom.

Who Captures the Value?

The strongest counter-argument to this essay deserves a fair hearing.

It goes like this: orchestration will commoditize. Open protocols turn coordination into plumbing. Frontier models will increasingly plan and route their own work. Value will stay where it has always been in enterprise software, in the systems of record, which is exactly what PTC and others are betting on. On this view, "orchestration strategy" is a vendor-invented category.

For Levels 1 and 2, I think this is largely right. Routing calls and sequencing tasks will become standard platform capability, and enterprises should mostly buy it.

Level 3 is different. Coordinating commitments requires knowing your product configurations, your decision rights, your effectivity rules and your process ownership. No protocol supplies that, and no vendor can ship it in a box. The orchestration engine may commoditize. The context it runs on does not.

You can buy the orchestrator. You cannot buy the context.

That reframes where value comes from. The first source is coordination efficiency: less time chasing information, reconciling data and following up approvals. The second, larger one is end-to-end performance: reducing the time from field failure to corrected product across every factory, not just speeding up one impact analysis. The first improves productivity. The second improves the business.

And there is a cost side. Every agent added is something to secure, monitor, test and maintain. A swarm of agents can be slower, more expensive and less reliable than a well-designed deterministic workflow.

The objective is not to maximize the number of agents. It is to maximize the business value delivered by coordinated execution.

What Enterprise Leaders Must Get Right

Start from the value chain, not the agent catalogue. Find the end-to-end processes constrained by handovers, fragmented information and slow decisions. Engineering change, new product introduction, supplier quality and field service are obvious candidates in industrial companies.

Define the commitment before the architecture. What decision, binding which functions, needs to happen faster or more reliably? Measure that.

Make system ownership explicit. Which system owns which truth, which component coordinates, and which agents may only recommend versus act.

Keep deterministic what must be deterministic. Transactions, regulatory steps and configuration rules should not rest on unverified model output. AI should complement process controls, not bypass them.

Invest in product context. Configurations, effectivity, traceability and the digital thread are no longer back-office hygiene. They are the precondition for Level 3.

Buy Levels 1 and 2; own Level 3. Use platforms and open standards for the commoditizing layers. Keep control of the process design, decision rights and data model that define how your enterprise actually works.

Build governance into execution. Identity, permissions, approvals, audit and observability cannot be retrofitted once agents are acting in production.

From Intelligent Tools to Intelligent Enterprises

In #004, Behind Every Prompt: The Value Chain Powering AI I argued that behind every prompt sits a value chain of chips, data centers, models and applications. Orchestration is the other end of that chain: the point where all that capability either becomes enterprise value or dissipates into a collection of impressive pilots.

Today most organizations deploy AI at the level of individual users and tasks. The larger opportunity is coordinating it across whole processes. For industrial companies, that could change how product lifecycles are run: engineers, planners and service technicians working alongside specialized agents, with an orchestration layer carrying context and decisions across functions that today rely on email, meetings and heroic individuals.

People don't disappear from this picture. Their role shifts toward deciding, validating, supervising and improving.

Systems of record don't disappear either. As agents act more, the systems that hold the authoritative truth matter more.

And the companies that pull ahead will probably not be the ones with the most agents or the best model. They will be the ones that understand their own products, processes and decision rights well enough to coordinate intelligence around them.

AI creates capabilities. Orchestration turns those capabilities into business outcomes.

The next frontier of enterprise AI is not merely making individual systems smarter. It is making the enterprise work together more intelligently.

Appendix A: Who Orchestrates the Enterprise?

Appendix Figure A — Technology providers approach enterprise orchestration from different starting positions. Each controls part of the coordination layer; none owns the enterprise's own product context and decision rights.

Sources & References

Related Blueprints