The machines we dreamed about are becoming real

I’m starting a new company in Physical AI with Eitan, my co-founder from Upswift.

We previously built an IoT platform that JFrog acquired in 2021. Now we’re coming back to the world of machines because I think we’re underestimating what is about to happen.

For years, we imagined machines we could explain a job to. Machines that could understand their surroundings, deal with something unexpected, and get useful work done.

We’re beginning to build them.

Google DeepMind is already demonstrating robots that turn language and vision into physical actions, handle varied tasks, and transfer learned skills between different bodies. These are still demonstrations with real limitations. They also show how far the possibilities have moved.

Things we used to describe as science fiction are becoming engineering problems.

I think the pace will surprise people. Progress will be uneven, and getting these machines into daily use will take serious work. But we should start thinking about what happens as the capabilities we see in research reach the products around us.

Some of those products will be entirely new. Others will look familiar: a tractor, an industrial arm, an inspection machine, a piece of construction equipment.

Imagine a factory machine adapting to a new part without someone rebuilding its entire workflow. A tractor handling conditions it has never encountered. A robot taking over a dangerous inspection so a person doesn’t have to go.

That possibility reaches into how we grow food, build homes, move goods, and do physical work. I find it hard to think about that and feel anything other than the urge to build.

Take an F-35.

It already depends on sophisticated software. In February, Lockheed Martin reported flight-testing AI inside its information fusion system. Engineers then updated the model on the ground and loaded it for the next flight.

Now imagine how an aircraft like that might evolve over the next twenty years.

From the outside, you might still recognize the same jet. Inside, successive generations of models could help the pilot make sense of conflicting sensor information, understand a changing situation, and spot problems earlier. Ground crews could learn more about how each aircraft is wearing from experience gathered across the fleet.

After testing and validation, new capabilities could reach an aircraft long after it leaves the factory. Software already improves these machines today. I expect AI to expand the range of things that can improve.

What does it mean to operate a fleet when the aircraft last for decades, while the models inside them keep changing?

The machine outlives the model.

I think that will be true across much of Physical AI. The tractor stays in the field. The industrial arm stays in the factory. The intelligence running parts of it may go through many generations.

Someone has to make that relationship work.

This is where my experience with Upswift comes back into the picture. We helped teams manage software on devices already out in the world. That work teaches you how much responsibility sits behind the word “deployed.”

A machine arrives at a customer. The environment changes. Parts wear down. Connectivity comes and goes. Software gets updated. The customer expects it to work through all of that.

We’re moving beyond fleets governed by static code alone. More of their behavior will come from learned models.

With explicit rules, you can trace a decision back through logic someone wrote. With a learned model, knowing exactly what you deployed may still leave you struggling to explain a particular action. Part of the machine has become a black box.

Some of these models also behave non-deterministically: the same input can produce different actions.

We’ll be operating fleets with that uncertainty built in. Understanding which software is running is only the beginning of understanding what a machine will do.

A machine can be running perfectly well as a computer while failing at its job.

Imagine a fleet of 10,000 robots sorting parts. One puts a part in the wrong bin.

Its process is running. Its connection is fine. It reports that the task is complete.

The software looks healthy. The work is wrong.

Did it misunderstand the instruction? Did the camera miss something? Did a motor fail to do what the model expected? Did an update improve most of the fleet while making this particular machine worse?

And how would you even know to investigate?

Getting a machine to do something remarkable once is an achievement. Getting thousands of them through an ordinary working week, without an engineer standing beside each one, is an enormous amount of additional work.

That gap is where I expect many of the hardest problems to appear.

A customer buying a machine is making a commitment. They may change how a factory operates, how a team works, or how a job gets done. They need to know what they can depend on.

I think we’re getting better at showing what these machines can do faster than we’re learning how to live with them at scale.

And we’re trying to work that out while the architecture itself is still taking shape.

Vision-language-action models, or VLAs, connect what a machine sees and the instructions it receives to the actions it takes. World models aim to represent aspects of the world and, in some approaches, predict how it could change. They can help with simulation, training, and planning.

How will those pieces fit together?

Will a robot use a world model to explore possible outcomes before a VLA turns a choice into movement? Will world models do most of their work during training, with a simpler system running on the machine? How much of this will merge into a single model?

The answers are still developing. Each one changes what we need to test, run, and understand once a machine is doing real work.

There’s another question I keep coming back to: how does one machine’s experience help the rest of the fleet improve, without spreading its mistakes?

These questions lead me to a simple belief: a new software stack will grow around intelligent machines.

We’ll build on decades of work in robotics, embedded systems, and cloud software. We’ll also need new ways to test changing behavior, understand failures across the whole machine, and turn experience in the field into improvements people can trust.

That work will span many companies and many layers, from simulation and evaluation to the daily operation of a fleet. The shape of it will keep changing as the models change.

Most people will never see any of it.

They’ll see a machine arrive, give it a job, and expect the job to get done.

That ordinary expectation is an extraordinary amount of engineering.

It’s also what brings me back.

I want to help build a world where a machine can take on work that is dangerous, exhausting, or simply difficult to get done. Where someone can put it to work and get on with their day.

We’ve spent years imagining what these machines could do.

I want to spend the next part of my life making them something people can count on.