Published date: October 27, 2026
Most manufacturers already have AI running somewhere in engineering: an assistant in the PLM client, a search across specifications and standards, a copilot in a CAD or ERP screen. Each works, but only inside the system it belongs to. The next step is usually framed as a tool choice: which vendor, which model, which platform. It's better to start with the use case and how far it has to reach: within one task, within one system, or across systems. We call these three levels of AI support. The level a use case needs sets both the value on offer and the integration effort it takes to get there.
Which level fits is much easier to answer for a named process with a business case attached. When the starting point is a general ambition to do something with AI in PLM, programmes tend to stall after the POC.
Higher is not better
Orchestration is not the goal the other two levels lead up to. An organisation can run all three at the same time. Process-level support inside PLM or ERP covers a lot of daily engineering work with limited integration effort. Task-level tools tend to multiply, because each one serves a single task and they often come from different vendors.
The reason not to run all three everywhere is mainly cost. Basic AI functionality is often included in a vendor's subscription, but premium capability is usually priced separately, per user or by consumption. An orchestration layer can call those tools rather than replace them, but it can also cover the same ground itself. So start by establishing what your systems of record include and what their premium tiers cost. Set that against what orchestration could deliver for the same processes, and what it would cost to build and run. Then decide on value against cost. Skip that comparison and you may end up paying for the same capability twice.
Process-level AI and orchestration overlap the most, so compare those two first. An orchestration platform combined with task-level tools overlaps far less. For a manufacturer, that could mean AI functionality in the CAD tool for designers and a coding agent for controls engineering, possibly from different vendors.
Once a process spans several systems, an AI platform as the orchestration layer is usually the only option. Engineering change is the clearest example. It starts in PLM, affects material masters, suppliers, inventory and open purchase orders in ERP, touches requirements and test evidence, and surfaces again in service. No single system holds all of that, so an assistant inside one system cannot tell you what a change will affect.
What orchestration requires
Orchestration depends on three things: a suitable platform, a solid data foundation underneath it and the right set-up in the organisation. The platform should offer:
- Composable: Pre-built agents, tools and connectors to start from, fully customisable to your own processes. Whatever you build can be reused.
- AI and fixed logic: Steps that must be exact, such as calculations and validation rules, run as code. The agent orchestrates around them.
- Context: Agents work with your own documents, system data and the links between them, so answers are grounded in your data.
- Control: Monitoring per agent and per tool, with cost and usage tracking and an audit trail.
- Model-agnostic: New models can be adopted as the field moves on, and the model is chosen per task, with cheaper models for simpler tasks.
- Speed: Quick to build and iterate on, with a first application live within months rather than after a two-year platform project.
The data foundation is separate from the platform. Records have to be matched across systems, for example the same part in PLM and ERP, and that needs a common ID. No platform provides this for you, and without it the agents have no reliable data to work with. Getting PLM data out of Teamcenter in a governed way, the subject of the first blog in this series, is part of that foundation.
On the organisation side, AI initiatives often start in a single department. That works well: the business owns the case and knows the work. For task-level AI, it is enough. A cross-system process such as engineering change management involves departments and systems beyond the one that started it, and aligning them takes time before any agent runs. That is why orchestration needs a company-wide AI platform and strategy rather than a departmental one. The result is shared service that any team can build its own use cases on.
What the vendors offer
The big vendors agree on what this architecture looks like, and each wants you to build it on its own platform. Siemens announced Intelligence Center X on 1 June 2026: the Mendix platform combined with Graph Studio and AI Studio, industrial ontologies and orchestrated agents, running on top of existing enterprise systems. SAP is moving in the same direction with Joule, its AI assistant and agents. The same capability can also be assembled on Microsoft Azure. That route needs different skills to build and maintain and comes with a different licence model, but gives you more freedom to shape the set-up later. Whichever route you take, the outcome depends on the use case you select, a business case that holds up and the right people involved to run it across departments.
Where to start
Treat this as a business decision first: which processes cross systems, what each level costs to run, and where results case can be delivered within two quarters. Emixa builds on Siemens and SAP technology, and on our own Gen AI Accelerator, which is deployed into the customer's own Azure tenant. Which route fits depends on the use cases on your roadmap, your system landscape and the skills in your organisation.
.svg){kind=small}
