Most factory robot programs share one unstated assumption: the world they were configured against will stay the same. The part arrives in the same orientation. The bin sits in the same spot. The sensor returns the same depth profile. In controlled cells under stable conditions, that assumption holds. On actual production floors, it fails often enough to matter.
What Unscripted Actually Means in Production
The term "unscripted" gets used loosely. Here is a useful working definition: any scene state the arm was not programmed to handle, where "programmed" includes teach points, tolerance windows, CAD model matches, and rule conditions. If the current state of the scene does not match any programmed case within its tolerance, the arm faults.
The fault itself is not the problem. The problem is frequency. A typical pick-and-place cell running mixed part batches might trigger 8-20 fault events per shift depending on part variety and bin management discipline. Each event requires a human to clear the error, verify the scene, and restart. At 3-5 minutes per event, that cost adds up quickly on any line running multiple arms.
The specific scenarios that cause faults are consistent across facilities we have looked at. A part that rotated 20-35 degrees from its expected orientation in the bin. Two parts touching each other when the program expected single-part isolation. A surface finish difference on a new supplier lot that shifts the structured light depth return enough to move the computed centroid outside the grasp tolerance. A bin repositioned 4 centimeters after a cleaning pass. None of these are exceptional events. They happen across every shift on floors with any variation in parts or process.
How VLA Models Process an Unscripted Scene
A VLA model does not match the current scene against a stored template. It processes the actual scene at execution time and generates an action conditioned on what it observes.
The inference pipeline runs as follows. A calibrated RGB-D camera captures the workspace at the moment before the arm acts. The perception encoder builds a scene representation: object candidates with approximate 3D extents, depth surfaces, and spatial relationships between elements in the field of view. The language model component receives a task prompt alongside the scene encoding and generates action tokens. Those tokens decode into a target TCP pose, approach vector, and gripper aperture. The arm controller executes the resulting motion command.
The critical difference is what the arm is reasoning against. A rule-based system compares the current scene to a fixed reference and escalates if the comparison fails. A VLA system generates a fresh action from the current scene on each cycle. There is no stored reference pose. The output is conditioned on what is actually in front of the camera right now, not what was there when the system was programmed.
This means a part that has rotated 30 degrees is not an error state. It is just a part in a different orientation. The model sees it, computes an appropriate grasp for that orientation, and the arm picks it. The same applies to slight bin position shifts, surface variation within a class of parts, and moderate depth-return noise from the sensor.
What Changes When You Commission and Maintain a System
The commissioning workflow is different in practice. Traditional teach programming for a pick-and-place task with moderate part variety runs 3-5 days of engineer time: recording teach points, defining tolerances for each variant, testing edge cases, adding exception branches for the failures, and iterating until the fault rate is acceptable. Adding a new part variant after go-live typically means calling the systems integrator back.
With EmbodyX, the initial configuration for a comparable task took roughly a day across the pilot setups we have run. That time goes to camera calibration, workspace bounds configuration, task prompt authoring, and a verification pass on sample parts covering the expected range of orientations and placements. Adding a new part variant is a prompt update plus a short verification run on the floor. The engineer on site handles it without an SI visit.
We are not claiming this eliminates commissioning effort. It changes where the effort goes: less time building and maintaining brittle rule trees, more time configuring and validating model behavior on specific parts. For facilities that add new part variants regularly, that difference compounds quickly.
Tradeoffs That Matter on the Floor
Inference latency is real. Our current model processes a scene in 80-120ms on the hardware we provision. For pick-and-place tasks at typical industrial tempos (2-4 picks per minute), this is within acceptable range. For high-cycle applications above 12-15 picks per minute, latency becomes a design constraint. You either need to accept the throughput ceiling or architect the pipeline so that inference runs in parallel with the arm's transit motion, which requires a lookahead buffer and some latency tolerance on the pick-ready signal.
Fine-tuning is required for high-precision tasks. The base model handles novel geometries well. It can pick parts it has never seen before, orient them reasonably, and place them within the tolerance ranges you would expect for general manipulation. But if your task requires sub-millimeter placement accuracy, like press fits or blind screw insertions, the base model will not reach the required consistency. You need fine-tuning on your specific parts and fixtures. That is a real requirement, not a footnote.
The model does not own physics or safety. EmbodyX outputs a target pose. The arm controller decides whether to execute it within the configured safety envelope. Joint-space collision detection, force limits, and e-stop logic remain the controller's responsibility. We are providing a smarter perception-to-action layer on top of the existing safety infrastructure, not replacing it.
What This Means for the Automation Team
The operational posture shift is meaningful. With rule-based systems, ongoing maintenance involves significant exception triage: identifying which edge cases caused which faults, patching the rule tree, re-testing, and monitoring for the next case. That work is reactive and scales poorly as task variety increases.
With a VLA-based system, the maintenance work shifts toward model performance monitoring: reviewing cases where the model's confidence score dropped below threshold, examining what the arm did, deciding whether the behavior needs a prompt adjustment or a fine-tuning data addition. That is still skilled work, but it is more tractable per engineer hour. In our pilot data, operators who had been handling 10-15 fault clearances per shift were spending most of the same time window reviewing one or two confidence threshold cases, most of which required no intervention at all.
The remaining intervention cases were genuinely ambiguous situations where the arm stopped and flagged for human review rather than attempting a low-confidence grasp. That is the intended behavior. We are not claiming the model eliminates uncertainty. It handles the predictable variation that rule-based systems fault on, and surfaces the genuinely uncertain cases for human judgment. That is a different and better division of labor than the current alternative.
VLA models on factory floors are early in their deployment history. The scenarios where they still struggle, high-speed fine-pitch assembly, tasks requiring active force feedback beyond the gripper's native sensing, multi-arm coordination, are real constraints we are working on. This article describes what works well enough to deploy now. The next ones will cover where the limits are.