Putting robots to work in manufacturing environments means meeting production-level reliability and performance from day one. We don’t get to set the benchmark here - our customers do: fraction-of-a-percent defect rates, strict cycle times, and reliable operation throughout every shift with zero tolerance for unsafe behavior. Meeting that bar requires highly capable autonomy and a way to mitigate and learn from potential failures.

Our approach is to teach our LBMs, the physical AI that controls Walden robots, to call for help, following a pattern inspired by Toyota’s Jidoka, the autonomous vehicle industry, and Claude Code’s “Auto” mode. We previously talked about why this is so important (because autonomy is a ratio), and we are excited to share more about how it works in practice.

Behind our fleet of robots is a team of remote assistants who can virtually jump into a robot that requires assistance to resolve ambiguity and unblock uncaught edge cases. This capability has multiple key components – hardware, software, AI, operations – that must work together seamlessly to be effective. Our infrastructure must be able to maintain connections between sets of robots and sets of remote assistants to ensure availability of assistance, our fleet monitoring system must provide sufficient context for a remote assistant to jump into a new situation and resolve difficulties quickly and reliably, and our robot stack must support highly reliable, high-quality operation over a remote link.

Crucially, for the above loop to work, our LBM must be able to decide when help is needed, taking into account context from its currently assigned task, current environment, and its own capabilities. We do this by making calling-for-help part of our multimodal policy. Alongside a denoising head that generates robot actions, a call-for-help decision head learns to recognize when assistance is needed, providing the policy a native way to assess its own execution and request help. This high-context approach means that call-for-help has access to the internal state of the policy.

Calling for help as part of the policy. A shared multimodal representation supports action generation and assistance requests in a unified model.

We train this capability by continuously closing the loop between deployment and learning. When a robot encounters a new situation, gets stuck, or has a behavior we want to refine, a remote assistant helps. That experience improves both the robot’s ability to perform the task and its ability to recognize when it needs assistance. This matters because uncertainty estimates that are reliable in one setting often become miscalibrated in other circumstances; our deployment loop lets us learn and calibrate when to ask for help directly in the environments where our robots work.

Loading camshafts into a mock machining conveyor. In this many-hour session we encountered zero uncaught failures despite several instances of the policy requiring assistance.

Scanning and sorting bagged items into accepted and rejected bins. When the policy struggles to reorient a part for scanning, it requests remote assistance, then resumes autonomous sorting.

With our initial system, we obtained more than an order of magnitude reduction in failures - enabling hours of continuous operation without fault.

This provides flexibility, allowing performance to be adjusted automatically based on the robot’s experience. New deployments start with a conservative high-recall approach, at the cost of more remote assistance. This lets our autonomy immediately address a wide variety of scenarios, and creates an accelerating feedback loop of improving autonomy performance, call-for-help ability, and call-for-help calibration from deployment. 

Balancing operational continuity and fleet scale. Tuning the assistance threshold balances operational continuity with the number of robots each remote assistant can support. Improving the policy and assistance heads expands this frontier, enabling greater continuity at larger robot-to-assistant ratios.

The best physical AI is not created in the lab; it is learned at scale from deployment. Calling for help is a key piece of that flywheel, allowing us to move fastest in meeting exacting customer requirements, improving our autonomy capabilities, and scaling our fleet. That’s why we’ve built our learning pipeline - and Walden as a whole - around closing the deployment loop.

More to come soon.

By the Walden Team