AI Orchestration

Limits of a single AI

An AI confined to one process cannot see the causal links to the steps before and after it. A quality model optimizes for quality, an energy model for electricity, and the control commands each considers optimal collide on the floor. Nor is there anything to stop a faulty inference from causing equipment malfunction or a line shutdown.

AI Orchestration addresses exactly this: the layer that arbitrates when optimizing an individual machine and optimizing the plant as a whole pull in different directions.

Two-layer structure

AI Orchestration is built as two layers of quite different character.

Upper layer — a language model manages the agents. When a request arrives, it plans which agents and tools to use, in what order and how far, verifies the result, and hands it to a person for review. It is not the thing that makes the judgement; it is the thing that organizes the judgement.

Lower layer — the agents handle the equipment. Quality, predictive-maintenance, production, energy and safety agents read equipment data normalized through OPC-UA and AAS, then change process conditions, raise maintenance orders or trigger an E-Stop. This is the layer with actual reach onto the floor.

Without the upper layer the agents collide with one another; without the lower layer it stops at analysis. Autonomous manufacturing needs both joined up.

Upper layer — planning and verification

On receiving a request, the planner first breaks down the work.

1. Query analysis — What is being asked, and which tools will be needed.
2. Agent selection — Choosing the agents that fit the query.
3. Execution order and stopping conditions — Decomposing the task to fix which agents and tools run in what sequence, and where to stop. This is what prevents it running in circles.
4. Final plan — Confirming the agents, parameters and conditions for each step, releasing the plan, and checking it against the ontology knowledge base.

With the plan set, the agents execute. RAG retrieval finds the evidence, documents and databases are queried and aggregated, and a verification step then checks the result. Conflicting or insufficient evidence is caught here.

A person closes the loop. When a user flags a judgement as wrong, an owner reviews the correction and approves or rejects it, and approved corrections feed into the ontology knowledge base — raising the consistency of the next orchestration by that much.

Lower layer — agent collaboration and supervisor arbitration

The approach pays off most in compound situations — equipment faults, energy imbalance, production disruption — where the cause spans several areas.

When a problem arises, a supervisor agent takes charge of the overall picture while specialist agents for quality, predictive maintenance, production and energy analyze live data to identify the cause. Where their control commands conflict, the supervisor resolves them with safety and compliance as the overriding rules. A virtual simulation then weighs the effect on plant-wide operation before an action plan is produced and carried out.

The agents in play:

• Quality agent — full inspection combining eddy-current and vision data.
• Predictive maintenance agent — analyzes vibration and torque to raise maintenance work orders ahead of a shutdown.
• Production optimization agent — adjusts process conditions dynamically.
• Energy agent — distributes electrical load.
• Safety vision agent — issues an E-Stop signal on detecting a collision or fire.

Automatic process variable control

On most floors, process variables are tuned from the experience of senior operators. When the people change, so do the settings, and that variance shows up as quality variance.

Having AI control those variables narrows the spread. Because the conditions and their outcomes are recorded, equipment settings and quality data stay connected rather than living in separate places.

Approval controls

High-risk commands are not executed automatically. They accumulate in an approval queue and take effect only after an administrator has reviewed them. Every control action is written to an audit log that cannot be altered. Even where the process runs unattended, a person holds the final decision.

Execution trace

What the planner decided, which tools it called, what the evidence was and how the verifier ruled are all kept as a single execution trace.

Because the system controls equipment, the path to each decision has to be auditable after the fact. The approval, amendment and rejection history is retained alongside, as is the history of ontology changes.

Adoption requirements

Deployment and servers — Built on-premise or in a private cloud according to your security policy. It needs a GPU server for the LLM, embedding and retrieval models, agent and API servers, and infrastructure for the vector database and trace store. There must be a network path to the internal business systems, databases and APIs; in an air-gapped environment, the procedure for bringing in and updating models and packages has to be defined separately. Deployment is either a dedicated customer cloud (VPC) or on-premise, and IMPIX holds ISO/IEC 27001 and GS Certification Grade 1.

Data readiness — The internal documents, business databases, API data and retrieval knowledge base the agents will use, with identifiers and key metadata maintained per document and record. Body text, tables and structured information need to be extracted into a searchable form. If an ontology is used, the core terms, entities, relationships and business rules need an initial definition, which is then refined in operation through human review.

Integration — REST APIs, database connectors and search APIs connect the business systems, internal databases, vector database, document stores and business APIs. Functions that create or change data in external systems must have permissions set separately from read-only functions. On the equipment side it connects to MES, ERP, QMS, WMS, FEMS, SCADA and PLC, taking OPC-UA data from legacy and new equipment, vision images, vibration and torque sensors, and structured production and quality data.

Permissions and operation — Roles are split between general users, operations administrators and domain reviewers. Query and search run automatically within a user’s permissions, but changes to external systems, significant decisions, cases where evidence conflicts or is insufficient, and user corrections are all routed for human approval.

Current status

AI Orchestration is a forthcoming product, currently in internal testing and PoC. Pilots are running with automotive parts, pharmaceutical, food and cosmetics manufacturers.

Indicators such as production output and defect detection accuracy are being measured during these projects, but the figures are not yet confirmed and so are not published here. If you are evaluating the product, contact us and we will share the current state of the work as it stands.