Podcast

Spicy Machine Learning Meets the Physical World

AI
Robotics
Strategy

Why putting AI into hardware is not the same as putting AI into a chatbot.

9:57

Take the AI Out

So how do you build safe AI-powered hardware? The honest answer: take the AI out wherever you can. A real engineering take on the zeitgeist of jamming statistical models in front of everything.
8:27

The Professional Wet Blanket

How do you handle a client showing up convinced they need AI? Be a professional wet blanket. It’s an engineering firm’s case for talking clients out of the robot whenever possible.
9:49

Markov Chain in a Trench Coat

What happens when an engineering firm actually unboxes a humanoid robot? They get the world’s most expensive and most dangerous remote control car. A field report from the front lines of physical AI.

Once you’ve crashed the car into the wall, you can’t inference your way out.

Jeff Ciesielski, Leaf Labs

Why AI in Physical Systems Belongs at the Edges, Not the Center

Our guests from Leaf Labs unboxed a humanoid robot. It arrived in a crate. The unboxing instructions amounted to “press these buttons.” There was no obstacle avoidance, no real sensing, and no information about how much space to give it. Just an app to download and a Go button. As they put it on the panel, it was the world’s most expensive and potentially most dangerous remote-control car.

The conversation clarified something we keep telling clients. The current rush to put AI into physical products is moving faster than the engineering thinking required to do it well.

Computers were invented to do deterministic things repeatedly. Machines were invented to do the same. What’s happening now is the opposite. Companies are taking systems that have always been deterministic and making them probabilistic. That can be fine when the cost of a wrong answer is bounded. It’s a different category of problem when a machine can touch you.

Where AI in physical systems belongs

There is a 1970s IBM training manual quote we keep returning to. “A computer should never make a management decision because a computer can never be held accountable.” When machines touch the physical world, accountability stops being optional. It becomes the whole problem.

So our default position with clients is simple. An AI-enabled robot is by definition worse than a robot that doesn’t use AI and can do the same job. AI is a tool of last resort. It belongs only where there is no deterministic way to solve the problem, and only after you understand the tradeoff you are accepting.

The principle we work from: flexible inputs, deterministic outputs. AI can help a system handle variable, real-world conditions. But the actions that touch the physical world need to behave predictably every single time.

What this looks like in practice

Bifurcate aggressively. Identify what truly needs to be non-deterministic. Codify everything else. Make the AI surface area as small as possible.

Define safe bounds. Galois has a Haskell framework called Ivory, built originally for flight software, that constrains inputs and outputs to provable safety bounds. The principle generalizes. Wrap your statistical model in something that can reject outputs falling outside what is acceptable.

Be honest about the 80/20. AI gets you to 80% of a working system fast. That is the seductive part. The remaining 20% does not behave like the first 80%. It can take 99% of the time, and you may never close it. If your application needs five or six nines of reliability, AI alone will not get you there.

Watch for black boxes. Most humanoid platforms ship with closed compute you cannot inspect, patch, or audit. Every closed binary is a permanent attack surface. When the thing in question can physically move and touch people, that surface matters in ways it does not on a phone.

The question worth asking

Before you add AI to a physical product, the question is not “can we?” It is “do we actually need a non-deterministic system here, and what do we give up if we use one?” Most of the time, the right answer is a simpler architecture: better inputs, a clearer process, a more universal pick point, a better human-machine interface. AI gets reserved for the cases where nothing else works.

That isn’t a rejection of AI. It is just engineering. Pick the smallest tool that solves the problem, especially when the problem can hurt someone.

If you are trying to figure out whether AI belongs in a product you are building, we can help you test it before you commit. That is the conversation worth having before the crate shows up.

Frequently Asked Questions

AI in the physical world, answered.

When should AI be used in a hardware or physical product?

Only when there is no deterministic way to solve the problem. Our default position with clients is that an AI-enabled robot is by definition worse than a robot that doesn’t use AI and can do the same job. AI introduces non-determinism, which is the opposite of what machines are built for. Reserve it for cases where no other approach works, then isolate it as narrowly as possible.

What does “flexible inputs, deterministic outputs” mean?

It is the principle we use when AI is genuinely required. AI can help a system handle variable, real-world conditions on the input side. But the actions a machine takes in the physical world should behave predictably every time. You wrap the non-deterministic reasoning in deterministic guardrails so the output stays inside known safe bounds.

What’s wrong with humanoid robots that ship today?

Most current platforms come with no obstacle avoidance, limited sensing, and a closed compute “black box” that the buyer cannot inspect, patch, or audit. The documentation focuses on capabilities, not safety. From an engineering standpoint, that is a permanent, unpatchable attack surface on a machine that can move and touch people.

How do you make AI-enabled hardware safer?

Bifurcate aggressively. Identify what truly needs to be non-deterministic and isolate it. Codify everything else. Wrap statistical models in something that can reject outputs falling outside safe bounds. Frameworks like Galois’ Ivory, originally built for flight software, show how this can be done. The goal is to minimize the AI surface area, not maximize it.

About the Guest

We sat down with Jeff Ciesielski and Jami Friedman of Leaf Labs to talk about what it really takes to put AI into physical products, and when to leave it out.

Jeff Ciesielski

Director of Research

Ciesielski went to LeafLabs having spent the past decade or so of his career on a wide variety of software and hardware projects ranging from race car telemetry systems, to accounting software for commercial fisheries, to most recently bending a fleet of autonomous manufacturing robots to his will using Haskell. When he isn’t working, he enjoys spending time with his wife, tinkering on his never ending race car project, and tending a small pride of house cats.

Leaf Labs LinkedIn

Jami Friedman

Executive Vice President

Friedman leads operations, program management, and partnerships at LeafLabs, overseeing client engagements and the systems that keep complex projects on track. She brings over a decade of experience managing hardware development and machine learning programs. Outside of work, she’s either cooking for a crowd or hunting for mid-century furniture at estate sales. (University of Massachusetts Amherst, BBA Supply Chain & Operations Management ’13)