Week 5: Twenty-Two Things I Don't Know
I wrapped up last week with a checklist for anyone considering a humanoid investment: three questions for sorting vendor evidence and five asks to keep in the back pocket during any sales meeting. A few readers seem to have filed it away as a buying guide, so let me correct that before it turns into one. The three questions and the five asks tell you how to read a vendor, but they tell you nothing about whether your enterprise should deploy a robot, and those are two different problems entirely.
Sometime in the next year, a CIO is going to put the question to me without any hedge attached: should we be piloting one of these robots? The honest answer, the one I would give across a table rather than in a post, is that I can’t responsibly answer yet. In short, the standby consultant answer of “it depends” stands. That isn’t because the robots don’t work, since some of them demonstrably do, for specific tasks, at specific sites, with money changing hands. It’s because a responsible recommendation rests on roughly twenty things I do not currently know, and any one of them could flip the recommendation from go to no-go.
So, this week I wrote down those questions and sorted them into four piles: questions about the machine itself, questions about operating it, questions about paying for it, and questions about the world outside the building. I numbered them because I intend to hold myself to them: whenever I claim to have a view on one of these, you will be able to scroll back and check whether the question I’m answering is the question I asked. (And please do hold me accountable.)
One admission before getting into the list: I sat down to write twenty, and the list grew by two before I finished the draft. Either the field is moving that fast or my list discipline is that weak. (Probably both.)
Let’s dive in.
The machine list
Where is the capability boundary stated outside of a highlight reel? Every vendor can show me what the robot did once. What I need is the task envelope: the range of work the machine completes reliably, the conditions under which that reliability holds, and what happens at the edges of it. A demo gives you one point on the map, and nobody in this field is publishing the map.
What does task variation cost? The tote is wet, the lighting changed, the SKU is new this week. I want to know whether the robot adapts, degrades, or stops, and when it can’t adapt on its own, what teaching it costs in days and in dollars. The economics of a generalist machine live inside this question, because a robot that needs vendor engineers on site for every variation is a specialist machine carrying a generalist’s price tag.
What does the machine do when it fails? It will fail. The question is what it does while it’s failing. A fixed industrial robot has a safety-rated stop: cutting power makes it safe. A bipedal machine that needs active control to stay upright has no equivalent, because cutting power makes it fall. I don’t yet know what a safe failure looks like for this class of machine, and I have not found a vendor who explains it in public.
What data does one unit produce in a shift, and where does it go? Each of these machines carries cameras, depth sensors, joint telemetry, action logging, and on some models microphones, all producing continuously across a shift. I want to know where that data lives, who can see it, what leaves the building, and what the retention terms say. I have asked versions of this question about enough enterprise systems to know that “we’ll work through that during onboarding” means nobody has worked through it.
Does fleet learning occur across customer boundaries? If a robot in my facility learns to handle my packaging, I want to know whether that skill transfers to the rest of my fleet, to the vendor’s other customers, or to my competitor, and under what controls, with what consent, and with what value flowing back to the facility that generated the training data. This is the question vendors most want to keep vague, because the honest answer sits at the foundation of their business model.
Operations
Week 4’s standard applies here: the test of a deployed robot is whether it works, and is supported, on an ordinary Tuesday. These five questions are what Tuesday is made of. (An aside: growing up my grandfather always used the phrase “…just an average Tuesday” to describe the ordinary, so there you go.)
What is the uptime, under production conditions, in writing? I raised this in Week 4 and it remains the most clarifying absence in the field. A forklift vendor quotes mean time between failures without being asked. No humanoid vendor publishes the figure. None.
When it breaks, who fixes it, and how fast? Mean time to repair matters, but so does the boring machinery behind it: where the parts depot sits, whether the technician belongs to the vendor or to me, what the escalation path looks like at two in the morning, and what my line does in the meantime. Twenty years of watching enterprise technology fail has taught me that the support model, not the product, is where deployments live or die.
Who writes the integration, and what happens when systems disagree? The robot has to talk to the warehouse management system, the MES, and sometimes the ERP, and someone has to write that middleware. When the system of record says the pallet is in bay 12 while the robot’s eyes say bay 14, I want to know which one wins and who designed the tiebreaker.
What happens to the team in the work area? Someone has to own the supervision model, the reporting lines, and the question of who answers the robot’s pages, because day to day somebody manages this thing the way a shift lead manages a new hire, and no framework exists for that role yet. The change management literature assumes the change is human, and in this case part of it isn’t.
How long until the site runs without vendor staff on the floor? Every early deployment I can find has vendor engineers embedded at the customer site, an arrangement that is fine for a pilot and disqualifying for production at any real number of sites. The date the vendor’s people go home is the date the product exists.
The money. The real money.
What is the total deployed cost, and what is the multiplier on unit price? This is ask number four from Week 4, promoted to a standing question. The unit price is a marketing number. The deployed reality is integration, infrastructure changes, training, support contracts, fleet software, insurance, and downtime. For every comparable industrial asset that total runs to some multiple of the sticker, and nobody has published the multiple for humanoids.
What is the financing structure, and what happens at the end of it? A capex purchase, a robots-as-a-service subscription, and a lease are three different risk allocations wearing the same robot, and each carries a question hiding inside it: when the term ends, what happens to the robot, to the trained behaviors, and to the data my facility spent two years generating?
If I switch vendors in year three, what do I keep? Behaviors, training data, fleet management tooling, and integration code all sit somewhere in the stack. My current guess? Almost nothing. The lock-in is being built into every layer right now, while nobody’s procurement team is looking.
Who deploys this besides the vendor? Independent integrators are what make any enterprise technology deployable at more than one site at a time, and for humanoids they do not yet exist. Until there is an independent party I can hire, audit, and hold accountable, every deployment is a bespoke vendor project, and bespoke vendor projects have never scaled in any technology wave I’ve lived through.
What does the contract say when things go wrong? I want to read the SLA terms, the liability allocation, the exit clauses, and the answer to Week 4’s bluntest ask: who owns the failure when it happens. The vendor whose standard agreement has a clear answer to that question has thought about production, and the vendor whose agreement is silent has thought about pilots.
My lawyer and insurance agent want to know…
What standard certifies this machine, and who signs the safety case? The industrial robot standards assume a fenced machine or a power-and-force-limited cobot, while the service robot standards assume something far less capable than a full-sized biped, and a dynamically balancing humanoid working near people falls between every category I can find. I do not yet know who writes, reviews, and signs the safety case for one, and as far as I can tell from the public material, neither does anyone else.
Who insures it, on what basis, at what premium? Insurance is the institution that prices risk honestly, because it loses money when it doesn’t, and there is no actuarial table for humanoids working alongside people. Whatever the early underwriters charge will tell us more about real deployment risk than any vendor’s safety page, and I want to see those numbers badly.
What is the workforce plan, in writing, before the robot arrives? Redeployment, retraining, attrition management, and whatever the existing labor agreements permit all have to be settled somewhere, and the facilities where this goes smoothly will be the ones that answered the question before procurement rather than after.
What happens at the bargaining table? Organized labor has already made automation the center of major contract fights in adjacent industries, and humanoids are the most visible, most filmable form of automation ever built. I don’t know what the first humanoid deployment does at the next contract negotiation, and I haven’t seen anyone game it out.
What happens when the first bad video comes from your building? A humanoid dropping a box is content. A humanoid falling near a worker is a news cycle. The first enterprise to take serious public damage from a deployment video will change every other enterprise’s risk calculus overnight, and nobody I’ve read is pricing that in.
The bonus questions
What is the teleoperation percentage? This one was already on Week 4’s list of unknowns, and the more I sit with it the more it refuses to stay in one category. It is an operational question, because a robot that is ninety percent piloted is a staffing model with servos, and it is a commercial question, because you are paying for a robot plus a remote human, which means a per-hour labor cost, an operations center somewhere, and a camera feed from inside your facility going to people you have never met. I want one number, in writing, before any contract gets signed.
Who supplies the brain, and who owns what it learns? The body and the intelligence are decoupling into separate industries while we watch. Boston Dynamics builds the body and Google DeepMind supplies the models, Figure walked away from OpenAI in February 2025 to build its intelligence in house, NVIDIA ships an open foundation model that anyone’s hardware can run, and a new class of company now sells robot brains with no body attached. That decoupling hands the enterprise buyer a question that did not exist a year ago: when the body vendor and the brain vendor are different companies and the robot does something wrong, whose problem is it? And behind that question sits a sharper one, because the fleet-learning data my facility generates is training somebody’s model, and I want to know whose, under what terms, and whether it ends up running my competitor’s fleet.
What I learned writing this
What follows is an honest reflection of where I’m at with the whole “operationalizing robotics” thought experiment.
There are eight questions where I have a starting view. On 6 and 7, Week 4 already established that the absence of published uptime is itself the answer for now. On 11, the comparable industrial assets give us a floor to reason from. On 13 and 14, I have watched the lock-in and integrator-gap movies before in other technology waves, and the opening scenes here look familiar. On 15, contract maturity is legible from the outside if you know what to read for. On 16, the safety case, my view is a negative one but it’s still a view: no standard I can find covers a dynamically balancing biped working near people, and that absence is the finding, not something I’m waiting to learn. And on 21, the position is simple enough to state in a sentence: get the number in writing or walk.
The other fourteen have nothing under them yet, and a few deserve naming. Question 3, what a safe failure looks like, is question 16 from the engineering side rather than the regulatory one, and it stays empty because nobody has published the design. Question 17 is empty because I have not found a single substantive public source on humanoid insurance. Questions 5 and 22 are forming faster than anyone outside the deals can see, and question 2, the cost of variation, may turn out to be the one that decides whether the generalist premise survives contact with enterprise reality at all.
That is how the questions map in my mind: eight questions with some semblance of an answer and fourteen with nothing yet. This list is the spine of whatever comes next in this series, and when I come back to one of these claiming an answer, hold me to the version written here.
The CIO question will come, and when it does, the responsible answer will not be a number of robots or a vendor name. It will be a count of how many of these twenty-two questions we have real answers for, and how many are still running on someone’s roadmap slide. Right now, my count is eight, and most of those are partial.
I’d want to be able to answer a lot more of these questions with confidence before I spent your budget.
Views are personal and do not represent any employer, past or present.