Physical AI - Not too early. Early enough

Eitan Chudnovsky

In 2018, Amit and I kept running into the same problem from different sources: companies were shipping more and more connected products into the world, but once a product left the lab, it was very hard to maintain remotely.

So we founded Upswift, a fleet management platform for Linux devices. Fast forward few years, JFrog acquired Upswift to close the loop from Artifactory to the edge device.

Now Amit and I are starting again - We're building the infrastructure layer for Physical AI fleets.

This post is about why, and why now.

The short version: everything our customers taught us about IoT and edge fleets in production is coming back in robotics, about 10x harder. And the timing is right. Not too early but early enough.

What edge devices taught us

Upswift was a cloud platform for fleets of Linux, IoT, and edge devices. We provided tools for continuous monitoring, remote control, device health, anomaly detection, and secure over-the-air software updates.

Our customers managed through the platform hundreds of thousands of devices worldwide. They taught us most of what we know about real world production. A few lessons stuck.

You can't touch the device. It's on a pole, in a factory, in a vehicle, in another country. "Just SSH in and fix it" stops working at the moment the device is out from the lab.
Networks lie. Updates drop halfway. The battery dies mid-download. The site loses power while the file system is being written. A device reboots in the middle of applying a package. If your update isn't atomic, with a known-good state to fall back to, you end up with a device that's neither the old version nor the new one. Those are the worst ones to debug.
Your fleet is never on one version. Some units are offline for a week and miss two releases. Some come back online after a month. At any moment, "the fleet" is really five or six fleets running different software. If you don't track that, you can't reason about anything else.
No two devices are alike. Different hardware revisions, different OS images, different peripherals, sometimes from the same customer in the same month. The update that works on one board bricks another.
Never update everyone at once. The single most important habit we saw in good teams: staged rollouts. Push to a small canary group, watch, expand, and have a rollback ready before you need it. The teams that skipped this learned it the hard way.
"Healthy" is not "correct." CPU, memory, disk, and uptime can all look fine while the device runs the wrong version of the wrong container. Monitoring health is not the same as knowing what's actually running.
Hardware breaks. Disks fill up. SD cards corrupt. Cameras go dark. Sensors drift. A fan dies and the board throttles until the update times out. From the dashboard it looks like a failed deploy or a flaky network. Until someone checks the hardware, you keep shipping software fixes at a hardware problem.

Our customers were almost never "IoT companies." They made casino machines, welding machines, and coffee roasting machines. One built a life-saving device mounted above swimming pools to prevent drowning. Another built a dog training robot that plays commands and throws a snack when the dog gets it right. Completely different products, completely different industries, and completely different scale. But all of them had the same problems: devices far away, updates that have to land safely, and a team that needs to know what's actually running. When the device is watching a pool, "mostly works" is not good enough.

From devices that follow rules to machines that decide

Every device we managed at Upswift was deterministic. A coffee roaster ran its profile. A welding machine ran its program. The dog robot played a command, waited for a sensor, and threw a snack. Same input, same output, every time. When something broke, it broke the same way on every unit, and the logs told you where.

That predictability was the hidden foundation of everything we built. A canary rollout works because a bad build fails the same way on ten devices as it would on ten thousand. Monitoring works because "healthy" has a clear definition. Rollback works because the old version behaves exactly like it did yesterday.

AI-powered machines break that foundation. They run models: VLA (vision-language-action) models that turn camera input and instructions into motion, and World Models that help them predict what happens next. They don't follow a script. They make decisions in real time, many times a second, based on what they see right now: the light in the room, where a box landed, whether a person just walked by.

That shift, from executing instructions to making decisions, is the real change. It's why I think the fleet problem doesn't just grow in Physical AI. It changes shape.

Why Physical AI makes all of this 10x harder

Every lesson above still holds. Here's what makes each one harder.

Models are non-deterministic. The same input can produce a different action. "It worked in testing" means less than it used to.
Failures are silent. A bad firmware build crashes. A bad model doesn't. It grips a little too hard, takes a slightly wrong path, hesitates. No error, no stack trace. Just a robot doing the wrong thing confidently.
Logs don't explain behavior. With software, logs tell you which branch ran. With a model, the "why" lives in weights, inputs, and context. To debug, you need to know exactly what hardware, which model, which version, which inputs, on which robot.
Updates are now model weights. Not a few megabytes of packages, but large model files, often updated more frequently, sometimes fine-tuned per site or per task. Everything we learned about half-applied updates over bad networks gets heavier.
One model, many bodies. Foundation models are increasingly cross-embodiment: the same model runs on arms, mobile bases, and humanoids. The version-skew problem becomes a matrix: model version × robot type × compute × site.
Mixed compute. One fleet can mix several generations of onboard accelerators. A model that runs well on one may be too slow on another, and in robotics, too slow is a behavior change.
A bad update is a safety issue. In IoT, a bad update usually meant downtime. A robot moves in the physical world, near people. A regression isn't just an outage. It's a robot arm, a forklift, or a humanoid doing something it shouldn't.

Same lessons. Higher stakes, more moving parts.

Why now

The models are arriving fast:

Physical Intelligence open-sourced π0 in February 2025, then followed with π0-FAST, π0.5, and π0.7 (around April 2026). They raised $600M in November 2025 at a valuation of about $5.6B.
Skild AI has raised nearly $1.7B since its 2023 founding, and launched its S1 robot foundation model in August 2026.
NVIDIA shipped its GR00T humanoid model line (N1 through N1.7 in 2026) and launched Cosmos 3, an open world foundation model, in May 2026.
Google DeepMind released Gemini Robotics 2 in July 2026, along with a smaller on-device model that can be adapted with around 200 examples.

That last point matters a lot to me. When a model can be adapted to a new task with a couple of hundred examples, you get many versions of many models, running on many robots. That's a fleet problem.

Why "early enough"

Honestly, most of this is still in labs and early-partner deployments. Fleets of AI-powered robots in production are not everywhere yet.

That's exactly why I think the timing is right.

When we started Upswift, edge devices were spreading fast, but there wasn't a standard in terms of managing them in production. Teams built their own update scripts, their own dashboards, their own remote access. Most of it broke the first time the fleet grew 10x. The companies that used Upswift moved faster and slept better..

Physical AI is at that same point. The models are here. The fleets are next. If the infrastructure only shows up after fleets scale, every robotics team will rebuild the same fragile plumbing, and some of them will learn the lessons in the physical world, where mistakes cost more than downtime.

So, Not too early: the models are real. Early enough: there's still time to build the infrastructure layer before the fleets need it badly.

A marathon, not a sprint

I'm excited in a way I haven't been in a while. Amit and I have done this once, on devices that were predictable by design. Now they see the world, make decisions in real time, and act on them.

This is a marathon, not a sprint. We're at the starting line, and we're glad to be here early enough.

If you're running robots in the field, or about to, I'd love to hear what's hard for you.