[01]

Physical AI Deployment: Closing the Gap Between Pilot and Production

[01]

Physical AI Deployment: Closing the Gap Between Pilot and Production

[01]

Physical AI Deployment: Closing the Gap Between Pilot and Production

Physical AI Deployment: Closing the Gap Between Pilot and Production

October 15, 2026

Trener Robotics

,

The gap between a successful robot demo and daily production

A successful robot demo shows that a task can be performed under controlled conditions. Daily production asks for more: the same task across varied parts, changeovers, stops and shifts, run by operators who did not build the system. The distance between the two is the Physical AI deployment gap. In machine tending, it usually shows up the first time a cell that ran cleanly in a demo meets ordinary production variation.

Closing that gap depends on collecting the right data at each stage of a deployment. This article organizes that data around four stages: the demo, a representative pilot, production acceptance and repeat installation. A demo shows that a task is possible. A representative pilot shows how the cell behaves with the parts, changeovers, and stops of real production, and a Site Acceptance test records that the cell is validated, operators are ready and responsibilities are assigned. Repeat installation then confirms which results carry over to the next machine or cell and which must be checked again. Machine tending is the running example throughout. 


Diagram of the four evidence stages for Physical AI deployment: demo, representative pilot, production acceptance and repeat installation, with the evidence each stage needs to produce.


Why do Physical AI pilots stall before production?

A pilot can prove the technology works and still stall, because it never answered whether the cell can run in production. The cause usually lies in what the pilot didn't test. In machine tending, four gaps come up again and again.


  1. The pilot leaves normal production variation untested

A pilot that runs one part, in one position, with the engineers who built the cell standing beside it, shows the cell at its best. Production brings different part types, batch sizes, orientations and changeovers, plus the small disturbances in between. If the pilot never sees any of these, it says little about how the cell will behave once they arrive. Our article on why a robot stops working when something changes looks at this problem in more depth.


  1. Machine interfaces and real-time execution remain unresolved

Machine tending depends on the robot coordinating with the machine it serves, including automated door and workholding signals, plus confirmation that the machine is ready. These interfaces are typically configured for one specific machine. A pilot that simulates or bypasses them never shows whether the cell can actually work with the CNC on the floor. That coordination also has to hold up in real time. For this reason, Acteris keeps robot motion in a deterministic control layer, while the AI agent interprets the task and selects the skills to run. Our article on real-time control explains how that layer works.


  1. Operators lack tested setup and recovery procedures

A cell can run well while engineers are on site and still quietly depend on them. If an operator can't set up a new job, or can't get the cell running again after a missed pick or a machine alarm, every surprise turns into a call for outside help. A proper handoff should test setup and recovery with the people who will run the cell every day, not just the people who built it.


  1. Acceptance criteria and support responsibilities remain undefined

Without agreed criteria, success is judged after the fact, and stakeholders can reasonably disagree about whether the pilot passed. Responsibilities for maintenance, escalation and change approval also need owners before production starts, because the first unplanned stop is a poor moment to decide who responds. Defining both before the pilot begins turns the result into evidence that supports a production decision.

Adding AI software for machine tending to an existing robot cell

Many manufacturers already have a robot and a machine tool, and the question is whether they can add software to that cell rather than replace it. One approach is an application-specific intelligence layer: software that handles job setup, skill selection, constraint checking and monitoring for a defined application such as machine tending, while execution stays within the cell's deterministic control layer. Acteris, Trener's AI software for robot applications, follows this approach. It can be deployed on new cells or used to retrofit existing workcells, with deployment delivered through integration partners.

This is one approach among several. Conventional programming by an integrator and purpose-built machine tending cells are others, and each can suit a different situation. For AI machine tending on an existing cell, the first evaluation question is compatibility. Acteris is currently compatible with ABB, Universal Robots and FANUC, with further brands planned. The existing robot brand, model and controller need to be checked against what has been validated, along with the tooling and the interface to the machine. 

An intelligence layer does not replace cell setup, safety configuration or validation. Cell-specific risk assessment and safety validation remain part of commissioning, and machine interlocks remain enforced by the cell's control system. For background on the concepts used in this article, see our earlier articles on Physical AI in manufacturing, CNC machine tending for high-mix, low-volume production and robot skills and agentic AI.

How to design a representative machine tending pilot

A representative pilot is built to resemble production closely enough that its results can support a production decision. For machine tending, five steps cover its design.

Select the parts, batches and changeovers to test

Choose parts and batch sizes that match the real production mix, including the parts that are hardest to handle. Schedule changeovers between them the way they would happen in production. A pilot that runs only the easiest part says little about the rest of the mix. Changeovers are also the right moment to test job setup by operators. 

In Acteris, an operator sets up a new job with the assistance of an agent, which confirms details such as the job name, batch size and pick-and-place locations. The pilot should include new jobs that operators set up on their own, without an engineer stepping in.


"Working with the team at Trener Robotics has been a real pleasure. With Sondre on site with us, we watched an operator set up a new CNC machine tending job simply by talking to Acteris, and that showed us where Physical AI is taking robotics. We are looking forward to bringing it to a customer's shop floor later this year."

Andrej Bielik, CEO, Stimba


Close-up of a robot arm gripper and vision sensor positioned above a tray of parts.


Record the baseline and agree on acceptance criteria

Before the pilot begins, record how the machine is tended today over a comparable period, including output, stops and operator time, so the results have something to be compared against. Then agree on the acceptance criteria in writing: which measures matter, what result counts as a pass, what happens if a criterion is not met and who signs off. Settling these points before the first cycle runs helps keep the evaluation objective.

Verify robot, tooling and machine-interface compatibility

Confirm that the robot brand, model and controller are supported, that the gripper and tooling suit the parts in the test, and that the signals between the robot and the machine, such as door, workholding and cycle status, are configured and working. Planned motions should be checked against the robot model's limits and the cell configuration, including reach and collision risks, before they run on hardware. In Acteris, this check takes place before execution, and testing skills in simulation first can help identify planned motions that fall outside achievable limits. Before physical pilot testing begins, assess the risks of the planned tests and put the required safeguards in place. These checks should form part of the cell-specific safety validation completed before the cell is accepted for production.

Test normal cycles, variation and recovery scenarios

Run normal cycles first, then introduce the variation the cell will meet in production: parts that arrive in slightly different positions or orientations, changes between part types and an infeed that runs empty. Real-time execution matters here because the robot and machine must respond to signals and changing conditions within the time limits required by the process. These responses should remain within the cell’s deterministic control layer.

Recovery scenarios deserve the same planning as normal cycles. Examples include a part that does not pick cleanly, a machine that does not reach its ready state and an alarm raised mid-cycle. The cell should respond with a validated action, such as pausing or asking the operator for input, and the operators who will run the cell should carry out these recoveries themselves during the pilot. In Acteris v.10, operators can pause and resume from exactly where a job left off, end production at the close of the current cycle, or reset with the robot returning home and safely handling any part in its gripper.


Screenshot of the Acteris production interface showing an active job, batch metrics and production controls.


Measure results across the agreed observation period

Fix the length of the observation period before the pilot starts, and make it long enough to include the variety of production: the different parts, the changeovers and the shifts on which operators will run the cell. Log each stop with its cause, its duration and who resolved it, and record interventions by engineers separately from those handled by operators. At the end, report the results against the agreed criteria as they were written, including any that fell short.

Results and checks required before a Physical AI cell enters production

Production acceptance is the point where pilot evidence becomes a decision. Four sets of data support that decision, and each should exist in writing before the cell runs in production.

Recorded performance against agreed criteria

The pilot record should show results for each agreed criterion, along with the stops, interventions and changeovers that occurred during the observation period. If the criteria changed during the pilot, the change and the reason for it should be documented. A result that meets the criteria under narrower conditions than planned should be recorded as such, so the acceptance decision reflects what was actually tested.

Completed cell validation and documented operating limits

The cell’s risk assessment identifies hazards and the protective measures needed to address them. Safety validation then checks that those measures work as intended before production starts. Together with the performance tests, these checks establish the cell’s approved operating limits, including the supported parts and batch ranges, tooling and machine interface conditions. Any proposed work outside those limits, such as a new part family or a different fixture, requires a review to determine what changes and further validation are needed.

Operator training and demonstrated recovery procedures

Operators should demonstrate, and not only attend training on, the tasks they will perform: setting up a new job, running a batch and recovering from the stops defined during the pilot. Written procedures support this work, and they should cover what an operator does when a situation falls outside what the cell can resolve on its own. The acceptance record can then show who was trained and which recoveries each person carried out.

Assigned maintenance, escalation and change responsibilities

Someone needs to own maintenance of the robot, tooling and machine interface; someone needs to be contacted when a stop falls outside the written procedures; and someone needs to approve changes to parts, jobs or settings. The manufacturer owns the decision to run the cell in production, while the integrator and the software supplier commonly contribute commissioning, validation, training and first-line support. The split depends on the agreement and should be written down. Deployment of Acteris is delivered through integration partners, and our Partners page describes how Trener supports integrators.

Adapting a proven robot skill to another machine or workcell

A robot skill is a parameterized capability, so moving one to another machine or workcell often means adjusting inputs such as part dimensions, target locations and batch size instead of building a new program. What was proven in the first cell is not automatically proven in the second, though. Repeat installation is its own evidence stage, and the results from the first cell help decide what to test without replacing the test.

Several items need to be checked again. The machine interface comes first, since door, clamp and cycle signals are typically configured for a specific machine and can differ from one machine to the next. Fixtures, vises and tooling may also differ, which affects how parts are presented and gripped. The new layout changes the reach and collision conditions, so planned motions need to be checked against the robot model and cell configuration again, and a different supported robot brand means execution must be configured and validated for that robot as well. If the skill relies on vision, the part range and the conditions in which parts are located should be confirmed in the new cell.


Diagram of the five evidence stages for Physical AI deployment: demo, representative pilot, field deployment, SAT and repeat installation, with the evidence each stage needs to produce.


Safety validation and operator readiness need to be repeated for the new cell as well. The new cell needs its own risk assessment and safety validation, its own documented operating limits and its own operator training and recovery demonstrations, and acceptance criteria should be agreed again for its parts and production mix. Integrators carry much of this work when they deploy similar applications across customers, because the installation steps repeat while each cell's checks remain specific to that cell. Reusing the underlying task logic can reduce how much is built from scratch, but it does not remove the validation each cell needs.

Comparing output, downtime and labor needs before and after deployment

The comparison that supports an acceptance decision uses the same measures, defined the same way, before and after deployment. Output, downtime and labor needs form a practical starting point for machine tending.



Results may show an improvement, no change or a mixed picture across the three measures, and each outcome is useful evidence for the production decision. Outcomes depend on the parts, the cell and the agreed criteria, so the comparison should be read as a record of this cell under these conditions. It belongs in the acceptance record next to the baseline it was measured against.

Moving Physical AI into production with clear acceptance criteria

Closing the gap between a demo and daily production comes down to the evidence gathered at four stages. A demo shows that a task is possible; a representative pilot tests it against real parts, changeovers and stops; production acceptance documents validation, operator readiness and responsibilities, and repeat installation confirms what carries over to the next cell. Machine tending gives each stage concrete things to measure, and agreeing on the criteria before the pilot begins gives everyone the same definition of success.

Move Physical AI into Production

To discuss a representative machine tending pilot and agree on its acceptance criteria

Move Physical AI into Production

To discuss a representative machine tending pilot and agree on its acceptance criteria

Move Physical AI into Production

To discuss a representative machine tending pilot and agree on its acceptance criteria

Frequently asked questions

What is the Physical AI deployment gap?

The Physical AI deployment gap is the distance between a robot demo that works under chosen conditions and a cell that runs reliably in daily production. It often comes from what a demo leaves untested, including normal part and batch variation, machine interfaces, real-time execution, operator setup and recovery, and agreed acceptance criteria.

What should a machine tending pilot prove?

A machine tending pilot should show that the cell meets agreed acceptance criteria using representative parts, batches and changeovers. It should also show that the robot, tooling and machine interface work together; that the cell handles the tested variation and follows validated recovery procedures; and that operators can set up jobs and manage the recoveries assigned to them, with clear escalation when specialist support is needed. Results are compared against a recorded baseline over an agreed observation period.

Can Physical AI be deployed on an existing robot cell?

Acteris can be deployed on new robot cells or used to retrofit existing workcells, so teams can modernize automation without ripping and replacing installed equipment. Acteris is currently compatible with industrial and collaborative robot brands including ABB, Universal Robots and FANUC, with support for additional brands planned as Acteris expands. Whether a specific cell is a fit depends on the robot brand, controller, tooling, machine interface and cell setup, so it should be evaluated case by case. Cell-specific risk assessment and safety validation remain part of commissioning. 

Who is responsible for production acceptance?

The manufacturer owns the decision to accept a cell into production, based on the evidence recorded during the pilot. The integrator and the software supplier commonly contribute commissioning, validation, training and support, and responsibilities for maintenance, escalation and change approval should be agreed in writing before the pilot starts.