Designing for Uncertainty in Physical AI

Four HRI Takeaways from Humanoids Summit Seoul 2026

10. 05. 2026

It was a crisp day in late September in Seoul. It was great to meet so many robotics enthusiasts at Humanoids Summit Seoul 2026. Most sessions were heavily focused on engineering and deployment perspectives. Still, it was insightful to learn where Human-Robot Interaction can play a role as the industry develops.

As Physical AI moves into the real world, HRI increasingly has to account for uncertainty across the full lifecycle of interaction from whether a robot can reliably perform a task, to how it acts safely under uncertain conditions, and how people maintain an up-to-date understanding of capabilities that continue to evolve.

Here are four questions I took away from the summit.

01. Real-World Application Uncertainty

Repeated theme across the summit was the difficulty of translating learned intelligence into reliable physical behavior.

Simulation can dramatically expand training and evaluation, but the real world introduces differences in materials, geometry, force, friction, sensing, lighting, and human behavior. More data alone does not necessarily solve this problem; the quality and diversity of the data matter as much as its volume.

Lightwheel’s multi-physics simulation provided a simple example. To a person, these instructions belongs to the same conceptual task:

“Pour this into that”

Yet pouring milk involves fluid dynamics, while pouring rice involves granular dynamics. The intent appears almost identical to us, but the physical problem is not.

AWS and Config approached the uncertainty from another angle. Instead of physically collecting a new robot demonstration for every visual condition, they used existing real-world demonstrations to generate more diverse synthetic data, varying lighting, surfaces, and appearance while preserving the underlying robot action. This helps the model recognize the same task under unfamiliar-looking conditions.

The two instance above expose an important mismatch:

Human organize capability semantically. Robots experience capability physically.

A person may naturally assume that a robot capable of one kind of pouring, grasping, wiping, or opening can perform other tasks that look the same. During this stage of robotics, that assumption will often be wrong.

The UX challenge is not to teach user the underlying physics, but it is to shield them from that complexity while preventing confusing capability surprises.

HRI Question:

How can UX absorb the mismatch between human expectations of task similarity and the robot’s uneven physical capability by revealing limitations only when they affect the user’s goal, safety, or next decision?

Uncertainty should therefore not be treated as an edge case in HRI. Interaction need s to be designed for uncertainty, exceptions, and recovery from the beginning.

02. Safety Through Transparent Uncertainty

Physical safety is fundamental, but safety also includes an interaction dimension.

10Things highlighted a gap between behavior that appears correct behavior that is physically valid, verified, and ready for deployment. A simulated manipulation may visually resemble success while violating the physics of the hand, object, or contact.

Their framing around Aida raised a useful sequence of questions:

Should I — Is this the right action?
May I — Am I authorized to do it?
Can I — Am I physically capable of doing it?
Where Am I — Do I understand the task environment and my physical relationship to it?

Cooley approaches safety from regulation, responsibility, and risk management. They emphasized that safety should be a priority early in the process not a spec to fine tune later on.

Bear Robotics discussed runtime safety: what happens when people unexpectedly enter or interrupt a robot’s operation, and which safety mechanisms should remain independent of high-level AI.

Together, these sessions made me think about honesty as part of robot safety.

Humans do not need constant explanations of everything a robot is uncertain about. That would quickly create interaction fatigue. At the same time, a robot should not appear more confident or capable than it actually is. The relevant uncertainty needs to become visible when it changes what the person should expect or do next.

HRI Question:

How should a robot expose its capability boundary at the moment it matters without turning every interaction into an explanation of uncertainty?

This leads to a principle I find more and more important: Trust in robots should be calibrated, not maximized.

The goal is not to make people trust the robot as much as possible, but to help them trust it to help users develop a level of trust that matches the robot’s actual capability.

03. Autonomy Under Degraded
& Uncertain Conditions

FieldAI challenged another assumption that autonomous systems operate in environments they can largely anticipate. Their work focuses on Dirty, Dull, and Dangerous (DDD) environments where GPS, maps, communication, infrastructure, predefined routes, and predictable conditions may not be available.

In environments like these, autonomy is no longer simply a question of whether the robot can make decision independently. The more interesting question becomes “What happens to autonomy as certainty disappears?”

A robot may begin a task with sufficient confidence, then encounter an unknown route, damaged infrastructure, an unexpected obstacle, or a condition outside its reliable capability.

The interaction cannot simply jump from autonomous to failed. There needs to be meaningful behavior in between. That might include slowing down, changing strategy, communicating progress, requesting assistance, returning partial results, or stopping when continued action would be unsafe.

HRI Question:

As environmental uncertainty increases, when should the robot continue independently, communicate its changing state, request help, or give control back to a human?

Also, how should robot communicate status and completion so people receive enough information to understand the outcome without requiring them to continuously supervise the task?

In uncertain environments, good autonomy may therefore be less about eliminating human involvement and more about changing human involvement at the right moment.

04. Continuous Learning,
Stable Human Expectations

It was insightful that Lightwheel framed robot learning as a continuous cycle.

Learn → Evaluate → Deploy → Improve

This resembles human learning in one important way: deployment is not the end.

Robots collect experience, encounter failures, are evaluated, improve, and return to the physical world with improved behaviors or new capabilities. I believe that is continuous improvement from an engineering perspective. But it creates an unusual challenge from an HRI perspective:

The product the user learned yesterday may not behave exactly the same tomorrow.

A robot might initially fail to perform a task, causing the user to stop asking for it. Months later, the capability may improve but the person’s mental model remains outdated.

The opposite can also happen. A familiar behavior may change after learning or an update, while the user still expects the previous interaction pattern.

HRI Question:

How doe we maintain a stable and accurate human mental model of a robot whose capabilities continue to change?

Not every change needs to be announced. Most improvements should probably remain invisible. But some changes affect established user’s expectations, permissions, routines, or safety.

Then, Which learned behaviors can change silently, and which changes require renewed awareness, explanation, or permission from the user?

Continuous learning therefore creates not only an AI challenge, but also a continuity of interaction problem.

A Perspective I Took Away

Across these sessions, I kept returning to the same relationship:

The robot will never stop learning to become more accurate and reliable. The human, meanwhile, simply needs an outcome that is reliable enough.

These two goals may never fully meet and perhaps they don’t need to.

The role of HRI is not to expose every technical uncertainty, but to decide which uncertainties matter to the user, when they need to become visible, and how the system can preserve the user’s goal when autonomy reaches its limits.