Physical AI: Why Robotics Needs Better Building Blocks
Physical AI extends beyond humanoid robots. See why better building blocks, safety, and practical use cases may matter more than a robotics breakthrough today.
Physical AI's Next Breakthrough May Not Look Like a Robot
"Physical AI" often makes people picture humanoid robots - machines that walk around, grab things, and eventually work side by side with us. That image is understandable, but it also narrows the conversation too soon. AI that works in the physical world could just as easily help design a molecule, develop a material, support a medical process, or run equipment on a factory floor.
That broader view is at the center of Amulya Vishwanath's investment thesis. A former NVIDIA executive who spent seven years leading product marketing for the company's robotics platforms, Vishwanath now runs Techable VC, an early-stage firm backing physical AI. She talks about robotics as being in its "Lego era": the field is still rebuilding the fundamentals - actuators and robotic hands, plus the software and safety standards that make real deployment possible.
That framing cuts against the idea that robotics will soon get a single "ChatGPT moment." For founders, investors, and operators, the more useful question may be less flashy: which parts of the system still stop a real-world task from working reliably, safely, and at a cost customers can live with? This article looks at what physical AI covers, why the foundational work matters, and how to evaluate opportunities without mistaking a cool demo for a product.
Physical AI Is Bigger Than Robotics
Robots are the most visible way AI shows up in the physical world, but visibility doesn't equal scope. Physical AI can involve systems that sense, predict, design, or make decisions about physical things. Sometimes the "output" looks like motion. Other times it looks like a proposed molecule, a new material, or a process that helps people carry out work.
Vishwanath describes the category in terms that include "a molecule, a material, a medicine," along with machines that operate on a factory line. The common thread isn't a particular shape or gadget. It's the link between computation and the physical world - where decisions have consequences beyond generating text or images.
The useful distinction is the job, not the hardware
A robot is a machine. Physical AI is a wider way to think about intelligence applied to physical systems. And that matters, because it changes how you should judge a company's product.
For a factory robot, you might ask whether it can handle variation in objects, fit into an existing workflow, and operate safely around workers. For a system aimed at materials or molecules, the questions shift: what physical property are you optimizing, how are candidate designs tested, and what does it take to move from a model to a real process?
In both cases, the model is only part of the system. Data, equipment, testing, integration, and human oversight often determine whether a technical result turns into something customers actually use. A strong prediction that can't be validated - or can't be acted on - isn't an operational solution yet.
Why this wider definition matters for business
If everyone fixates on humanoid robots, founders and investors can miss quieter opportunities. It can also lead to a bad comparison: a robot demo is easy to film, while improvements to a component, a workflow, or an industrial process may be harder to see - but more valuable to the buyer.
"Physical AI" also isn't automatically better as a label. If it becomes too broad, customers may struggle to understand what a company actually does. A credible business has to answer a practical question: whose work changes, which constraint gets removed, and how will you measure success?
So treat the category as a guide - not a replacement for product definition. Whether the system involves a robotic hand or a material-design workflow, its value depends on the task and the environment it has to work in.
Why Robotics Is Still in Its Lego Era
The "Lego era" metaphor works because it focuses attention on parts that have to fit together. Robotics isn't just "a language model connected to a body." You need hardware, software, sensing, control, and safety, all working together. If one piece is unreliable, the finished product will inherit that weakness.
Vishwanath's view, as summarized in the TechCrunch Equity interview, is that key building blocks are still being rebuilt. That list includes actuators, robotic hands, software, and safety standards. Each element can sound narrow, but they shape what a robot can do, where it can operate, and how much it costs to deploy.
A general model cannot remove every physical constraint
People often argue for a robotics "ChatGPT moment" by pointing to the idea that a general foundation model could make many specialized systems unnecessary. That's worth taking seriously. A stronger model could make instructions easier to use or help systems adapt to unfamiliar tasks.
But model capability doesn't magically solve the physical pieces. A robot still needs hardware that can produce the movement, sensors that deliver usable information, and control systems that turn decisions into action. And the real environment is rarely "clean." Objects vary, equipment wears over time, and a workflow that looks simple in a demo can hide edge cases.
That's the gap between understanding an instruction and completing a task reliably. A model might interpret what someone wants, but the product has to handle the object, avoid damage, respond to unexpected conditions, and fit into the surrounding operation. Those aren't peripheral issues. They're the product.
Integration is where elegant demos meet operating conditions
A demo shows the system can do something once. A business has to learn how often it succeeds, what happens when it fails, how long it takes to set up, and who gets responsible when recovery is needed. Those questions connect engineering performance to real operating cost.
The components also interact. A more dexterous hand can widen the range of tasks, but it may bring new requirements for control and testing. A model that improves flexibility might demand better sensing and tighter safety boundaries. A system can look impressive as a collection of parts and still be hard to maintain in practice.
This doesn't mean robotics is stuck. It means progress may come through many smaller improvements rather than one headline breakthrough. Better components, easier integration, and more dependable operation can build on each other. The "Lego era" framing is a reminder to look at progress in the pieces and the interfaces - not only the final robot on stage.
Safety is a product requirement, not a final-stage checklist
Safety standards matter because physical systems share space - with people, property, and ongoing production. The right safeguards depend on the task and context, but the principle holds: safety has to be designed into the system, not bolted on after the core product is done.
There's also a business reality. If a product only works under perfect conditions, adoption will be slower. Buyers want confidence about how it behaves around people, what its limits are, and what happens when it encounters situations it can't handle. Clear boundaries can be more valuable than broad claims about autonomy.
Where Practical Opportunities Can Emerge
Vishwanath's investment thesis highlights problems with tangible consequences - worker shortages in family-run factories and burnout among surgeons, for example. That points to a practical way to find opportunities: start from a bottleneck that already costs people something, then test whether physical AI can reduce it in a measurable way.
This approach is different from starting with a technology and hunting for a place to apply it. A robot looking for a task can end up delivering an expensive answer nobody actually needs. A business that begins with a persistent operational problem has a clearer path to testing whether automation is useful.
Start with the constraint the customer already feels
In a family-run factory, the challenge might be finding enough workers to keep a production process running. That doesn't automatically mean a humanoid robot is the right solution. The job could be repetitive, difficult to staff, or constrained by existing equipment. The first step is understanding the work, the environment, and what it costs to leave the problem unsolved.
Healthcare works the same way. Surgeon burnout is real, but "use AI in surgery" isn't a product definition. A company has to decide what specific work it can support, how it fits into clinical practice, and what evidence it needs before people rely on it. In high-stakes settings, adoption depends on more than technical novelty.
A good opportunity assessment is unavoidably concrete:
- What recurring task or constraint is the customer trying to address?
- How is it handled today, including the cost of delays, errors, or staffing gaps?
- Which part of the work can a physical AI system reliably improve?
- What must remain under human judgment or supervision?
- What evidence would persuade a customer to deploy it?
These questions are useful because they expose whether a system is solving a costly problem or just proving that a new capability exists.
Conscious automation means paying attention to the role of people
The interview also brings up Vishwanath's idea of "conscious automation." The summary doesn't define it formally, so it's safer not to treat the phrase as a settled technical standard. As a practical lens, though, it asks a clear question: what should be automated, and what should stay a human responsibility?
Automation isn't just a binary choice between replacing someone and doing nothing. A system might take on a hazardous or repetitive step, help a skilled worker handle more cases, or provide consistent support while leaving final decisions to a person. The right boundary depends on the task, the consequences of failure, and how well the system performs.
This also keeps "impact" grounded. A company should be able to explain how its product changes work for the people affected by it. Does it reduce a genuine burden? Does it create new monitoring work? Does it make an existing process safer or more accessible? Those details belong in product design and deployment planning - not in a slogan.
Look for measurable outcomes, not robot-shaped optics
Humanoids get attention because people immediately understand what they're "supposed" to do in a human environment. But that visual familiarity can distract from the real question: does the system do a useful job better than the alternatives?
The interview's point that humanoids should be good for more than dancing is basically the test in one sentence. A movement demo isn't proof of operational value. To assess a humanoid product, ask what task it performs, how it handles variation, how much support it needs, and whether the economics work for the buyer.
The same test applies to less visible physical AI. A material-design platform or robotic component doesn't need to look futuristic. It needs a credible path from its technical capability to a customer outcome.
How to Assess Physical AI Businesses
Physical AI mixes technical uncertainty with the messy realities of deployment. That's why it helps to keep three questions separate - because they often get blurred together: can the technology work, can it work in the customer's environment, and can the business deliver it sustainably?
Vishwanath has also argued that founders should treat their VC as their moat. In this context, "moat" isn't only about money. An investor's network and ability to support due diligence or introduce customers can matter, especially if a company needs specialist input or real-world environments. But relationships are an advantage only if they translate into relevant help. They don't replace product quality or customer demand.
A practical evaluation framework
For an early-stage physical AI company, assess the opportunity across five connected areas:
- Problem: Is the pain frequent, costly, and specific? Can the customer explain how it affects operations today?
- System: What has to work together - model, hardware, sensors, software, and safety processes? Where is the current bottleneck?
- Deployment: How much setup, integration, training, and ongoing support does the product require? Who owns failures and maintenance?
- Evidence: Has the system been tested under conditions that resemble real use? What does success mean, and how are edge cases handled?
- Economics: Does the value justify the cost of equipment, integration, and operation? Can the company repeat deployments without rebuilding the product every time?
This isn't a scorecard where everything needs to be perfect on day one. Early companies will have open questions. The goal is to make those questions explicit, then sort which ones are technical risks, which ones are customer risks, and which ones could prevent the business model from scaling.
Assessing the US and China without turning it into a slogan
The interview also touches on where the United States and China may each have advantages. The source summary doesn't lay out a definitive conclusion by country, so it would be misleading to treat it like a ranking.
For founders and investors, a more useful approach is comparing concrete parts of the ecosystem rather than assuming one country leads everywhere. Relevant factors can include access to customers, manufacturing capacity, research talent, supply chains, capital, and the standards or regulations that shape deployment. Different applications may depend on different combinations of those factors.
National comparisons can provide context, but they don't replace understanding what a specific company actually depends on. A startup's path might rely on a particular component supplier, a specific customer environment, or a regulatory process. Those details affect time to market and cost directly. Generic claims about global leadership don't answer the questions that matter.
What investors should test before backing a vision
A physical AI pitch can sound technically ambitious and still have no credible route to adoption. Investors should ask what the first deployment is meant to prove, whether the customer has a reason to participate, and how the company will learn once it's in operating conditions. A pilot that mainly produces a video - with no plan for rollout - can generate attention without reducing risk.
Founders should also look for investors who understand the kind of support the business actually needs. That could mean customer introductions, help evaluating an application, or a network that strengthens diligence. It should be discussed plainly, not implied. "Strategic value" by itself isn't a moat; the value has to connect to the company's next operational milestone.
Ultimately, the discipline is keeping the technology, the customer, and the business model in the same conversation. A system that works but can't be deployed is incomplete. A customer need without a feasible technical path isn't an opportunity yet. And a successful deployment that only happens with one-off effort may not translate into a durable business.
Conclusion
Physical AI is broader than robotics, and robotics is broader than the race to build the most convincing humanoid. The field still depends on basic pieces - hardware, software, safety, and integration - that determine whether a system can move from a controlled demo to daily use.
For founders, the practical path is to start from a costly constraint in the real world and work backward to what capabilities you need. For investors, the job is to look at the whole system: technical performance, deployment realities, customer demand, and economics that can repeat. For everyone else, the signal to watch isn't whether a machine looks human - it's whether it makes a meaningful job safer, more reliable, or more feasible.
If you're evaluating a physical AI idea, write down the task, the current workaround, the failure conditions, and the customer outcome before you pick a model or machine. That's a better starting point than waiting for one breakthrough to solve the whole category.