Why We’re Not Rushing Ethen Into Hardware

Our AI company hardware strategy is simple to state: Ethen will not build robots or other physical devices until seven conditions hold together. There has to be a specific customer or research use case; software has to have demonstrated value that hardware would unlock; qualified robotics and safety expertise has to be in place, in-house or through a partner; there has to be a real test site; data rights have to be agreed in advance; the budget has to cover maintenance, support and failure, not just building; and someone has to own physical safety by name. Until then, our robotics research stays in software, where the decision problems every robot shares can be studied cheaply and safely. And if those conditions never hold, not building hardware is a perfectly good outcome. This article explains why.

Key takeaways

• Seven conditions, all of them. A use case, proven software value, expertise, a test site, data rights, a full budget and safety ownership.
• Hardware is unforgiving. Physical mistakes cost more, last longer and can hurt people.
• Demos are not evidence. Staged demonstrations are easy; reliable deployment is not.
• The moat is rarely the machine. Durable value tends to come from software, data and trust.
• "Never" is a valid answer. Not every research direction should become a product.

Why the question comes up

AI companies are being asked about robots more than ever. Humanoid robots attract enormous attention, large investments and viral demonstrations. Language and vision models have made robots more capable of following instructions, and research has shown models trained on web data and robot data together carrying some general knowledge into robot control. It is a genuinely exciting time in robotics.

It is also a time of hype. Reporting on the humanoid robot sector in 2026 has described a gap between eye-catching demonstrations and the limited number of robots doing real, sustained work, and has pointed to physical interaction data — slow and expensive to collect, impossible to scrape from the internet — as a central bottleneck. Many demonstrations are teleoperated, staged or narrowly scripted.

Rodney Brooks, a roboticist and former director of MIT's computer science and AI laboratory, listed common mistakes in AI predictions in a widely read 2017 essay. One is mistaking performance for competence: seeing a system do one impressive thing and assuming it can do related things. Robot demonstrations invite exactly that mistake.

Why hardware is different

Software and hardware fail differently.

Mistakes are physical. A software agent that makes a mistake can usually be corrected or rolled back. A robot that makes a mistake can break things or hurt people.

Iteration is slow. Software can be changed and redeployed in minutes. Hardware changes take weeks or months and cost real money each time.

Maintenance never ends. Physical devices wear, break and need servicing in the field, by people, indefinitely.

The hard problems are the "easy" ones. Moravec's paradox, named after the roboticist Hans Moravec, observes that tasks humans find hard — chess, mathematics — have been comparatively easy for computers, while tasks humans find effortless — perception, grasping, walking — are very hard. Robots live in the second category.

Safety is regulated. Industrial robot safety is governed by established standards, such as the ISO 10218 series revised in 2025, which also covers collaborative applications where robots and people share space. Meeting them requires specialized expertise.

None of this makes hardware a bad idea. It makes it a serious one, which deserves a serious decision rule.

Our seven conditions

Figure 1 shows the conditions we require before building anything physical.

1. A specific use case. A named customer need or research question that a physical device would serve, not "robots are the future".

2. Software value proven first. Evidence that the software side — planning, approvals, recovery, proof of completion — already delivers value, and that hardware would unlock more of it.

3. Qualified expertise. Robotics and safety engineering, in-house or through a partner. Software research does not qualify anyone to own motion control or physical safety. This condition is highlighted because it is the one most easily underestimated.

4. A test site. A real environment, usually a partner's, where the device can be tested under real conditions with appropriate supervision.

5. Data rights. Agreement in advance on what data may be collected, by whom, for what purposes, and what may not be used.

6. A full budget. Including maintenance, support, replacement and failure — not just the cost of building a prototype.

7. Safety ownership. Named people responsible for physical safety and standards compliance.

All seven, not most of them. A strong use case without safety expertise is not enough. A test site without data rights is not enough.

Common reasons to rush, examined

Several arguments push companies toward hardware sooner. Figure 2 examines five of them.

"Robots are the next platform." Perhaps. That becomes a reason to build when there is a specific use case where a robot beats existing tools for someone.

"Hardware creates a moat." The machine itself is increasingly a commodity as manufacturing scales. Durable advantage in robotics, as in AI generally, tends to come from software, data and trust, not from owning the device.

"We need physical data." Physical data matters for physical capability. Getting it responsibly needs rights, safety and a partner site — not a fleet of devices bought to manufacture a dataset.

"Demos attract attention." They do, briefly. Evidence that survives beyond the demo is what earns lasting trust.

"Others are moving fast." That is a reason to watch closely, not a reason to build. The question is whether it matters for our users.

What we are doing instead

Not building hardware does not mean ignoring robotics. Figure 3 shows our current focus.

Research. The Ethen Robotics Research Lab studies acting agents in software: how they pursue goals, recover from failure, predict the effects of their actions and prove completion. We explain why in Why Ethen Is Researching Digital Robots Before Physical Robots and describe the research agenda in From Screen to Physical World: How We Think About Ethen Robotics.

Products. Digital robots are useful today: supervised computer use, delegated jobs that finish with evidence, and local and private AI. Each teaches us something about acting responsibly.

Preparation. The layers any robot would need — bounded authority, approvals, evidence, recovery — are being built and tested in software now. Our digital robot design project, iBOT, explores how an acting agent should present itself without pretending to be more than it is; see What We're Learning From Designing iBOT.

What a responsible first step would look like

If the conditions were ever met, the first step would be modest, and it would look nothing like a humanoid demonstration. The following is illustrative of the shape, not a plan.

A partner already operates physical equipment — say, a warehouse with existing automated systems run by a qualified robotics team. Ethen's contribution would be software: planning which tasks to schedule, asking for approval before changes that affect people or goods, recording evidence of what was done, and reconciling when an outcome is uncertain. The partner's systems would carry out every physical action under the partner's own safety processes. Data collected would be limited to what the agreement allows, for the purposes it states.

Success would be measured in the partner's terms: fewer errors, faster recovery from problems, clearer records. Only if that software layer proved useful in the physical setting — and only if a specific need emerged that existing equipment could not meet — would the question of building or adapting hardware even arise.

That is a long way from building a robot. It is deliberately so.

What we would carry over from software

Years of building software agents have taught lessons that apply even more strongly to physical systems.

Bounded authority. Software agents get only the access a task needs. Physical systems should get only the range of motion, force and area a task needs.

Precise approvals. In software, an approval covers one exact action. In the physical world, consequential actions should be approved just as specifically.

Honest uncertainty. A software agent that cannot confirm an outcome should say so rather than retry. A physical system that cannot confirm a state should stop and check rather than proceed.

Evidence of completion. "Done" should mean verified, in both worlds.

Recovery before scale. Decide what happens when things go wrong before running at volume.

These are the parts of robotics where a software company might genuinely contribute — and they can be developed and tested now, without hardware.

How the decision would be made

A decision to involve hardware would not be made by enthusiasm in a product meeting. It would be made against the seven written conditions, with the evidence for each recorded, reviewed by people with the relevant expertise — including safety — and explained publicly. If any condition were not met, the answer would be no, and the reason would be stated. That is the same discipline we apply when deciding whether research becomes a product: written criteria, evidence, and a willingness to stop.

The path, if we ever take it

If the seven conditions ever hold, the path would still be gradual: software agents doing verifiable work; integration with existing physical systems through software, without controlling motion; ground truth measured in real operations with partners; and only then, where justified, trusted physical control led by qualified robotics and safety teams. We would not start by buying a fleet or a factory.

What would make us move faster

Caution is not the same as indifference. Several developments would make the conditions easier to meet and could bring a decision forward.

A partner with a concrete problem. An organization that already operates physical systems, has qualified robotics and safety staff, and has a specific problem where better planning, approvals or recovery would help.

Evidence from software that transfers. Results showing that the decision layers we build — recovery, uncertainty handling, evidence of completion — measurably help in an integration setting.

Mature safety tooling. Standards, simulation and verification tools that make it easier to demonstrate safety for a narrow use case.

Clear data agreements. Practical frameworks for collecting and using physical interaction data with consent and clear limits.

Any of these would be a reason to revisit the decision, against the same seven conditions. None would be a reason to skip them.

Why "never" is acceptable

The hardest part of this decision rule is accepting that the answer might be no, permanently. Research directions do not have to become products. A research program that clarifies which problems matter, contributes to the software side of robotics and decides not to build hardware has still done useful work. We discuss that principle in Why Not Everything Ethen Researches Needs to Become a Product.

Being willing to say "never" also protects focus. Ethen's products need depth more than they need another category, as we explain in Why We're Choosing Depth Over Feature Count.

Tradeoffs and limitations

We may be early to say no. If physical AI advances quickly, waiting could mean missing opportunities. We accept that risk.

Software-only research has limits. Some robotics knowledge only comes from physical work.

Partners are not guaranteed. Several conditions depend on partners who may not appear.

This is a decision rule, not a forecast. It says when we would build, not whether or when that will happen.

FAQ

Why doesn't Ethen build robots? Because seven conditions — a specific use case, proven software value, qualified expertise, a test site, data rights, a full budget and safety ownership — do not all hold. Until they do, research stays in software.

Should AI software companies build hardware? Only when a specific use case justifies it and the expertise, partners, data rights, budget and safety ownership are in place. Excitement and competition are not reasons on their own.

What has to be true before building a robot? At minimum: a named use case, demonstrated software value, robotics and safety expertise, a real test site, agreed data rights, a budget that includes maintenance, and named safety owners.

Is Ethen working on robotics at all? Yes, as research on acting agents in software, through the Ethen Robotics Research Lab. No hardware is planned or announced.

Will Ethen ever build hardware? Possibly, if the conditions hold. Possibly never. Both are acceptable outcomes.

Related reading

• Why Ethen Is Researching Digital Robots Before Physical Robots
• From Screen to Physical World: How We Think About Ethen Robotics
• What We're Learning From Designing iBOT
• Why Not Everything Ethen Researches Needs to Become a Product
• Why We're Choosing Depth Over Feature Count

References

1. Brooks, R. (2017, October 6). The Seven Deadly Sins of AI Predictions. MIT Technology Review. https://www.technologyreview.com/2017/10/06/241837/the-seven-deadly-sins-of-ai-predictions/
2. Moravec, H. (1988). Mind Children: The Future of Robot and Human Intelligence. Harvard University Press.
3. ISO 10218-1:2025. Robotics — Safety requirements — Part 1: Industrial robots. https://www.iso.org/standard/73933.html
4. Brohan, A., Brown, N., Carbajal, J., et al. (2023). RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. arXiv:2307.15818. https://arxiv.org/abs/2307.15818