Robotics Startup: What Changed, What Hasn't

You can start a robotics startup now without owning the hardware design, the autonomy stack, or even the computer that runs the model. Search the term and page one gives you accelerator directories, company lists, and a jobs board, all of which tell you who exists and none of which tell you what you would actually be signing up for.

The most concrete answer on record comes from someone whose day job is making that answer yes. On Y Combinator's Lightcone, Quan Vuong, a co-founder of Physical Intelligence, walked through what changed in the equation for starting a robotics business. Vuong did his doctoral work at UC San Diego and was previously at Google DeepMind, where he co-led Open X-Embodiment and worked on the RT-1 and RT-2 models that first showed a vision-language model could be trained to output robot actions.

One disclosure up front, because it changes how you should read the optimism: Physical Intelligence builds the model layer that a wave of new robotics companies would buy or download. A Cambrian explosion of robotics startups is good for them. That does not make the analysis wrong, a separate YC Paper Club session on why robotics still isn't solved reaches a similar conclusion about a robotics application layer forming above the models. It does mean you should check the claims against deployments rather than against enthusiasm, which is most of what this article does.

The vertical playbook itself, from picking a workflow through to break even and scale, is covered in physical AI. This piece is the layer underneath it: what specifically got unbundled, what is still genuinely hard, how to tell a real deployment from a demo, and the security question a robot in someone else's building creates.

What actually changed for a robotics startup

Robotics used to be a vertically integrated business, and that is the part that broke. What replaced it is a shared model layer. The interesting question for a founder is what is left once you subtract it.

Start with what you can now download. Physical Intelligence released the weights and code for its first generalist policy, π0, in February 2025, along with an autoregressive variant called π0-FAST, and the openpi repository has since grown to carry π0.5 checkpoints too. Vuong's point about those releases is the one worth internalizing. People kept asking him whether the open weights differed from what the company used internally, and "the answer was actually no, it's the same model." For those checkpoints, the weights the researchers train on are the weights you get.

Note the scope, because it matters more than the headline. The deployments this article holds up as evidence further down were running π0.6, which is not in openpi. What you can download is a strong pretrained base, not the current frontier, and a founder should plan on that gap staying open rather than assuming it closes. That is still a large slice of what used to be a robotics company, and the remaining question is what you do with it, which is a workflow and operations question rather than a research one.

The sharpest evidence for how clean that interface has become is not a benchmark. It is Vuong's description of collaborating with two deployment partners on real customer sites. "I've never seen that robot in person," he said of one of them, adding that he has very little idea how the robot actually works and "I also don't know how they collect data." That is a deliberate choice rather than an oversight. If the model provider has to learn each partner's stack to be useful, the layer does not scale, and the fact that it is possible to stay ignorant of the hardware is the strongest signal that the unbundling is real.

For a founder, that decoupling is the permission slip. You do not need to originate the autonomy stack any more than a SaaS company originates a database.

The brain does not have to ride on the robot

Here is the part most coverage of this shift skips, and it is the one that changes a founder's spreadsheet.

One of the first questions Physical Intelligence gets from companies wanting to deploy robots is what compute to put on the machine. It is an uncomfortable question, because onboard compute is expensive, it raises the bill of materials on every unit you ever ship, and you are committing to silicon today against models that keep getting larger. Pick wrong and you have a fleet that cannot run the model you will want in a couple of years.

Vuong's answer is that the model does not have to be on the machine at all. Almost all of the robot evaluation Physical Intelligence runs, including the coffee making, the laundry folding, and the mobile robots navigating around, uses a model hosted in the cloud. Not a server in the office. A real data center. Inside the high frequency control loop, "the robot is actually querying an API endpoint that hosts the model," sending images and a language command, and getting back actions that execute directly on the machine.

That should not work. Robots run in real time, and a network round trip to a data center is an eternity in a control loop. Two ideas make it work anyway.

The first is pipelining. The model does not return one action, it returns a chunk of them, a short sequence the robot can execute. So the robot never has to sit idle waiting. As Vuong put it, if the robot already has actions queued for the next 100 milliseconds, "there's no reason for me to wait until I finish executing that action to ask my model for a different action." Ask early, and the next chunk arrives before the current one runs out. Anyone who has built a streaming system will recognize this immediately, which is part of the point: the problem moved from robotics into systems engineering, a discipline far more founders already have.

The second is harder and is where the research went. When you switch from one chunk to the next mid-motion, the two have to agree, or the arm jerks. Physical Intelligence published its approach as real-time action chunking, which explicitly targets keeping precision and speed despite high latency, and notes that its models use a chunk of 50 actions corresponding to one second of real time. Naively smoothing the discontinuity between chunks is not safe, which is why this needed a method rather than a filter.

What this means commercially is specific:

• Your bill of materials may not need a large accelerator. Some onboard compute is still required. What moves off the robot is the model, not all of the computing. That accelerator is a per-unit cost on every robot you ever ship, and removing it changes the unit economics at exactly the point where robotics companies historically died.
• You can upgrade the model without touching the fleet. The hardware you deploy this year does not have to be sized for next year's model.
• Your control stack gets simpler. You are not maintaining an embedded real-time operating system alongside a general purpose one just to host a large model locally.
• You have inherited a network dependency. More on that below, because it is the trade and it is not free.

What is still hard for a robotics startup, and it is not the model

The unbundling is real. The remaining problems are the ones that do not make good demos.

The data shortage is two problems, not one. That robotics has no equivalent of the web corpus is the well-worn half. Vuong splits what founders tend to blur together. One is data generation, actually producing the robot experience in the first place, which is the operationally heavy part everyone budgets for. The other is data capture, which is subtler and cheaper to fix: a great deal of robot data is already being produced and then thrown away, because nobody set up the pipeline to record it in a form you could train on. If you are putting robots on a customer site, the capture problem is yours from day one, and solving it is most of your accumulating advantage. Every shift your machine works is either an asset or an asset you discarded.

Your own fleet will fight you. The intuition that standardizing on a single robot platform simplifies everything turns out to be wrong in practice. Vuong's observation is that "over time that platform is going to drift" through hardware revisions and software changes, and each drift quietly devalues the data you collected before it. You end up with a handful of samples from each of many slightly different distributions rather than many samples from one. Physical Intelligence's response was to lean into heterogeneity, on the thesis that a model trained across many platforms learns the more abstract skill of controlling a robot rather than one specific machine. Be careful about copying that posture, because it is position-dependent: variety is an asset to the model provider, who wants samples from as many distributions as possible, and a tax on the deployer, who has to keep all of it running. You are the deployer. The Open X-Embodiment collaboration Vuong co-led at Google DeepMind pooled data from 22 robot embodiments, and in the small-data regime the generalist beat the embodiment-specific specialists on 4 of 5 datasets, with a mean success rate about 50 percent higher. On the large datasets that advantage disappeared. That is the honest version of the result, and it is why the bet is about data diversity rather than a free lunch.

Evaluation gets worse faster than capability gets better, for reasons physical AI covers, along with the supporting tooling gap that is an opening for a company with no robots at all. The part that bites a new company is narrower: you will not have an evaluation harness on your first deployment, and that is exactly where you discover you needed one. Decide early what "working" means in numbers a customer would accept, because the alternative is a demo you cannot reproduce and a pilot you cannot close.

The calendar is still physical. Every constraint in deep tech startups still applies once you own hardware: lead times, revisions, and a loop measured in weeks rather than in deploys. The model layer got cheap. Iterating on a machine did not.

How to tell a real deployment from a demo

This is the skill that will save you the most money, because robotics has more impressive video than any field in technology and almost none of it predicts whether a system works at a customer site.

Physical Intelligence published its partner results in a post called The Physical Intelligence Layer, which is worth reading for the structure as much as the results. Two deployments are instructive.

Weave Robotics, a Y Combinator company building home robots, ran laundry folding in an actual laundromat in San Francisco. Laundry is the canonical hard case in manipulation: garments are deformable, no two items are alike, and a slightly misplaced corner ruins the fold. Weave's own account notes that folding for laundromat customers means folding whatever arrives, not just t-shirts but long sleeves, shorts, and pants in varying fabrics and sizes. Vuong's framing of why it counts is that the observation space is effectively infinite, and that the garments in the footage were not items the model had seen in training.

Ultra, another Y Combinator company, runs order packing in live e-commerce warehouses. The task is picking an item from a tray and placing it into a narrow shipping pouch, which sometimes requires nudging the item through an opening it barely fits. The tell in that footage is the clock: the clip runs about 100 minutes at 4x speed, and by the end of it the sun has set. Lighting change across a working day used to be exactly the kind of thing that broke a robot's perception. Asked whether this was a demo station, he was direct that it was packaging real customer orders for shipment in a real warehouse: "So this is real operations."

From those two, here is the checklist to apply to any robotics deployment, including your own pilot:

1. Unseen objects. Did the system handle items that were not in its training data, or was the object set curated.
2. Uncontrolled conditions. Did lighting, clutter, and the surrounding environment change during the run, or was it a fixed cell.
3. Duration. A 30-second clip proves a capability. A full shift proves a system.
4. Real stakes. Were the outputs real customer orders, real garments, real money, or was it a staging area.
5. Stated intervention rate. A deployment that reports how often a human took over is telling you the truth. One that does not report it is showing you its best run.

That last point is the one to internalize. Mixed autonomy is not an embarrassment to be hidden, it is the operating mode, and the honest number is the one you manage down.

The security question the demo never covers

This is where the cloud inference trade comes due.

If your robot's control loop queries an endpoint in a data center, you have made three commitments that a fully onboard system does not make.

Availability is now a safety property. The question is not whether your uptime is good. It is what the machine does in the specific moment the link drops mid-chunk, with an arm in motion holding something. That behavior is a design decision you make deliberately, with a local fallback that brings the system to a safe state, or it is a decision that gets made for you by a timeout somewhere. Write it down before you deploy, not after an incident.

Integrity of the action path. Whatever returns from that endpoint gets executed on physical hardware. That is a categorically different exposure from a web application returning bad JSON. Mutual authentication between robot and endpoint, integrity on the action stream, and bounds checking on the robot side that rejects actions outside a safe envelope regardless of what the model asked for, are not paranoid extras. They are the difference between a software bug and an injury.

The data path leaves the building. Cloud inference means camera frames from your customer's site go to a third party continuously. In a warehouse that is a picture of their throughput, their inventory, and their staffing. In a home it is considerably worse. Enterprise buyers will ask what is retained, where it is processed, and who can see it, and the honest answer is a procurement requirement long before it is a compliance one. Decide your retention and residency posture while it is still a design document.

There is a further layer that is genuinely unsettled. Robot foundation models are probabilistic systems that take physical actions, and the interpretability work that lets anyone explain why one chose a given action is very young. A YC Root Access session on interpretability and safety for robot foundation models describes the field as new enough that the first interpretability paper for these models is recent, and points to organized efforts now forming to bring AI safety and robot learning communities together on exactly this. If you deploy into a regulated environment, expect to be asked questions this field cannot yet answer well, and expect the honest answer to be procedural: constrained envelopes, human oversight, and a complete log.

One practical note that costs nothing. Mixed autonomy means you are already recording every human intervention. Treat that log as a security and safety artifact rather than as ops telemetry: timestamped, tamper evident, and retained. It is your incident record, your evidence in a dispute, and your training data, and it is much cheaper to build that way from the first deployment than to reconstruct later.

Who should start a robotics startup now

The claim that the cost of building in robotics has fallen sharply is well supported. The claim that this makes it easy is not, and Vuong does not make it. His closing framing is that the work now calls for "a very different kind of scrappy skill set" from the one the field used to select for. The people who will win are not the ones with the deepest robotics background. They are the ones who can find a workflow, integrate a system, collect data in a messy real place, and keep a machine running in a building they do not own.

That is an operations company that happens to use a model, which is the same shape as AI for manufacturing and most of the useful AI businesses being built right now. The model layer is the commodity. The deployment is the company.

What to do this week

• Pick a task where a mistake is cheap. Write down what happens when the robot gets it wrong. If the answer involves injury, spoilage, or a regulatory event, pick a different first task, because you will not be able to run the mixed autonomy period that gets you to reliability.
• Price both architectures before you commit, then find your break-even. Put the onboard compute bill of materials next to cloud inference for your actual duty cycle and network conditions, and carry it through to the intervention rate at which one robot covers its own cost including the remote specialist. That single number tells you whether to add a second robot or keep improving the first.
• Decide the lost-link behavior now. Write one paragraph describing exactly what your machine does when the endpoint stops answering mid-motion, and who is accountable for that state. Then test it deliberately.
• Design data capture into the first deployment. Not the second. Decide now what you record, where it is stored, who owns it in the customer contract, and how you would train on it. Data you did not capture is the advantage you did not build.
• Answer the buyer's data questions before they ask. What leaves the site, how long it is retained, where it is processed, and who can access it. Put it in a one-page document now and you will close faster later.
• Go and buy one arm. The model is a download and the reference deployments are public. The gap between founders who have run a policy on real hardware and those who have read about it is a weekend.

Working out which layer to enter, what to own, and what to let someone else commoditize is the operating question underneath all of this, and it is what the AI Operating System for Startups course is built around. The broader map of where AI actually changes a startup's operating model is in our guide to AI for startups.

Sources

• The GPT Moment for Robotics Is Here (Y Combinator's Lightcone), the interview this article distills, with Physical Intelligence co-founder Quan Vuong on the unbundling of the robotics stack, cloud-hosted inference inside the control loop, the data generation versus data capture split, platform drift, and the Weave and Ultra deployments.
• Physical Intelligence primary sources: Open Sourcing pi-zero for the February 2025 weights release, Real-Time Action Chunking with Large Models for the latency method and the 50-action chunk, The Physical Intelligence Layer for the partner deployment write-ups, and the openpi repository for the released checkpoints.
• Deployment partners, both Y Combinator companies: Weave Robotics on laundry folding in a San Francisco laundromat, and Ultra on order packing in live e-commerce warehouses.
• Open X-Embodiment for the cross-embodiment dataset and RT-X results, the collaboration Vuong co-led while at Google DeepMind.
• Why Robotics Still Isn't Solved, But Could Be Soon (Y Combinator's Paper Club), an independent read on the robotics application layer forming above the base models.
• Interpretability and Safety for Robot Foundation Models (YC Root Access), for the state of interpretability work on models that both reason and physically act.