Notes from our Physical AI dinner
What should a drone do when a police helicopter approaches it?
We heard that question at a dinner we recently hosted for engineering leaders and founders working in Physical AI: the AI behind robots, drones, autonomous vehicles, and other machines that sense and act in the real world, along with the infrastructure that keeps them running. Nobody at the table had a clean answer. The people in that room deploy these machines for a living, and the question that stumped them was about safety, regulation, and operations, not model quality.
That was the theme of the whole evening: Physical AI is constrained by the physical world. Progress depends not only on better models, but on solving the problems around them: regulation, safety, operations, and data.
Scaling takes more than a better model
Despite rapid model progress, truly large-scale autonomous deployments still feel distant. The gap is the long tail of situations nobody puts in a pitch deck. How should a system respond when an animal starts interacting with the equipment? What kicks in when hardware behaves in ways nobody anticipated? Who is accountable when it does?
This is the unglamorous work that gates adoption. The physical world doesn't behave like a benchmark.
The physical world plays by rules a model can't change
Physical AI companies routinely operate inside regulatory frameworks written for older technologies. EV charging companies have had to navigate gas-station rules, including public price displays and printed receipts. Drone operators face aviation requirements designed for crewed aircraft. These constraints sit outside the model entirely, and a team has to clear them before a deployment is legal, let alone good.
Society sets its own rule on top: machines face a higher bar than humans. A battery fire or an autonomous accident draws disproportionate attention compared to an equivalent human-caused incident. That's the reality, and the teams that win will design for it early.
Surviving the physical world is a data problem
The edge cases, the regulations, the higher bar: you handle all of them through the data the machines produce. You catch an edge case because something in the telemetry looked wrong. You prove you met a regulation because you kept the records. The physical world is messy, and data is how you get a grip on it.
So data becomes its own hard problem. Machines in the field generate enormous volumes of telemetry, and every team deploying them wrestles with the same five decisions:
- What does the system need in real time?
- What stays at the edge?
- What gets shipped to the cloud?
- What's worth retaining for training?
- And what must be kept for regulators, sometimes for decades?
Nuclear applications can carry 30-year retention requirements, a timescale that makes most storage strategies look quaint.
At fleet scale, monitoring, observability, and automation become critical infrastructure, increasingly run with agentic copilots that help operators watch and triage while humans stay accountable for the rare edge cases.
Most teams haven't felt this yet, because most aren't at fleet scale. The ones who treat the telemetry layer as core infrastructure before they get there are the ones who won't be rebuilding it under load later.
The work is surviving reality, not beating a benchmark
The model is what everyone watches. The deployment is decided by everything around it: the regulation, the safety bar, the operations, and the data that ties them together.
That's the work the people at our dinner do every day, and it's why we'll keep bringing them together. It's also the work we do: helping teams capture, store, and make sense of the data their machines produce, so the operational layer is ready when deployment scales. If you're building machines that operate beyond the lab, reach out. We'd love to have you at the table.
