Two consecutive panels of one robotics conference in a single document. Speaking are an investor, a delivery-fleet operator and a robots-as-a-service operator at factories; then founders deploying humanoids in data centres, selling dexterous hands with a data pipeline, building a foundation model and collecting data through an exoskeleton. The transcripts come from automatic speech recognition and are in places garbled beyond readability: the names of speakers and companies are deliberately not reconstructed.
The transcript has been through an automatic speech-recognition system and is in places unreadable. The names of people and companies are deliberately not "repaired": speakers are named by role ("the investor", "the delivery-fleet operator", "the robots-as-a-service operator at factories", "the data-centre robotics founder", "the hand-hardware founder", "the moderator"). Where a garbled phrase plainly denotes a specific product term, the most likely reading is given in brackets and marked as a "guess". All numbers are marked as stated by the speakers. What stayed unreadable is in a separate section at the end.
The two panels run back to back, but they are different conversations. The first is about economics and deployment at working production sites; the second is about what breaks and how data is collected in the field.
| Question | What the panels claim | What is verifiable here |
|---|---|---|
| Subject of panel one | Deployment economics: TCO, uptime, refusal of PoC, complete solution, risk on the vendor's balance sheet | Matches the explicit session order announced by the moderator (first "what the buyer pays for", then money, then deployment) |
| Subject of panel two | Deployment in practice: hands and force sensors, integration, standardisation, data, reliability | Matches the moderator's list of blocks (what breaks, where the pilot gets stuck, the first week, standardisation, data) |
| Loudest numbers | 85% in the lab; 99.99% as a product; 99.96% uptime across 150 factories; 4,800 hours of use; 280 hours to a breakdown | All self-reported by the speakers; none confirmed by an independent source in the transcript |
| Main admission of panel one | The first two deployments "went badly" | A direct quote from the robots-as-a-service operator; a voluntary admission, not an analyst's inference |
| Main admission of panel two | They used to think the model was the hardest part; the hardware turned out to be hard | The direct wording of the hand-hardware founder and the data-centre robotics founder |
| How reliable the source is | An ASR transcript with abundant distortions of names and terms | Unreliable on names; relatively reliable on numbers and mechanisms that a speaker repeats twice |
Panel one. Three roles: the investor (claims he previously ran a fund of about 6 million dollars for investment in AI and machine learning, funded around 35 companies, and before that lived in China about 20 years, having built 8 factories); the delivery-fleet operator (claims more than 500 robots in four countries); the robots-as-a-service operator at factories (claims about 150 factories across the US under his ownership and operation). The moderator runs the session. All names are distorted by recognition and are not reproduced here.
The conversation opens with the moderator's question: what the buyer is really paying for. The robots-as-a-service operator answers through a list, not through price.
What is decided is not the sticker, but total cost of ownership. The first link is whether the robot can be operated without a safety fence at all. The speaker calls this one of the most underrated line items: where a fence is necessary, the cost "suddenly doubles the amount you have to invest". The second link is whether the financial case closes: can the metrics be improved enough for it to pay off. The third is what happens when the robot stops: if the task is critical, downtime halts the line, and non-critical tasks simply "will not carry the price of today's robot".
A safety fence doubles the investment (as stated by the speaker). This means that hardware designed to run without a fence is not a convenience but a multiplier of the project's economics: it decides whether the project fits the budget at all.
The speaker then moves to who inside the company slows the deal down: procurement and a multitude of stakeholders. He describes them as people who "can hold a project back right to the end" and stresses that in the US this is especially noticeable. That is, demonstrating value and a working robot do not yet guarantee deployment: it is getting through procurement that decides.
Demonstrating value and deployment are two different events. The transition between them depends on how "educated in their world" the vendor is and whether the deal gets through procurement.
The investor takes the floor and formulates what he considers underrated by most robotics companies: uptime. His first formula is simple and harsh: a robot working 85 percent of the time in a lab is a failure, not a success.
"People see a robot in a lab that works 85 percent of the time and think that is a success. In a real production scenario, if you are not at 99, not at three nines, it is simply a binary choice: it is absolutely unacceptable."
He then explains why the final bar is even higher. To reach 99.99 percent overall, he says, three things must be multiplied: model performance, hardware performance and response-time performance. The product must land at 99.99, which means every factor has to be well above 99. He illustrates with a number: a robot doing 10,000 cycles a day does not tolerate "hundreds of failures".
The practical takeaway from this arithmetic: the weakest link sets the whole result. If the hardware delivers 99.5 and the model 99.8, the product is already below the bar, and no amount of model strength will pull it up. That is exactly why the speaker calls the bar "extraordinarily high".
The investor explains the refusal of proofs of concept through a mechanism of incentives: corporate innovation teams, he says, "for a more accurate word, are paid to spend their own time" - they need a result for management, so a demonstration does not move the decision.
"They want to show a flashy animation, show cool backflips and nice drinks. In the end it does not move decision-making." The stated success metrics of the innovation team differ from the metrics of production operation.
The panel's second argument is the risk the vendor takes on. The wording is stark: "we do not get paid if it does not work"; the vendor does not sell a kit of hardware in the hope that everything will come together, but takes the risk onto its own balance sheet for performance, uptime and maintenance. The investor adds: buyers "have been burned by many empty promises", so the seller's job is to remove risk as fast as possible and take on maintenance, operation, teleoperation, repair and spare parts.
| Position | Classic PoC / pilot | Panel one model |
|---|---|---|
| Success metric | A demonstration for the innovation team's management | Production operation |
| Who pays for failure | The vendor did the work for free; the buyer loses nothing | The vendor gets no money if it does not work |
| Risk on the balance sheet | The buyer's | The vendor's: uptime, maintenance, spare parts |
| What is demonstrated | Backflips, drinks, flashy numbers | A robot still working months later |
A vendor taking risk onto its balance sheet cannot afford to sell something that does not work: the next deployment depends on the result of the previous one. That is an economic motive to be careful with promises.
The robots-as-a-service operator formulates that the buyer will not buy a component on its own. His example: "I want this camera, make the camera, and my camera is the best of all, or my data collection is the best of all" - but the customer could not care less.
Individual cameras, sensors and "data pipelines" as such are not sold to the end buyer. In his words, the only formally sellable product applies: the complete solution, in which the vendor brings everything together. He lists the components of this complete solution as a mandatory set.
"The only thing they can digest is the complete solution. And that is hardware, software, maintenance, spare parts, financing, uptime guarantees, insurance: you have to bring it all. Otherwise it is not a viable product."
The investor's analogy with cloud infrastructure is the centre of his argument. Nobody builds their own data centre not because leasing is cheaper in price, but because "I want AWS to answer when it goes down".
"Almost all of us stopped building our own data centres in offices and instead use a third-party provider. The reason is not that I want to pay monthly. It is not about price. It is about risk. I want AWS to answer when it goes down. I do not want to fix the server myself."
Carried over to robots, the analogy yields a formula: the question is not when you pay, but who is responsible for performance. And the vendor has a natural basis for taking that responsibility on itself: it "should be better at operating robots than its customer is at operating a chocolate factory".
The delivery-fleet operator picks up the thread: if the vendor is confident in the product and ready to guarantee performance, it should take the risk on itself. This echoes the point about "money in the bank" and completes panel one's logic that what is bought is not a robot but a result.
The investor deliberately breaks the tidy picture of the previous points. In his words, he had conversations with robotics companies and their customers, and most large buyers say one thing: "I just want to buy this".
The reason is not an unwillingness to accept risk, but the design of budgets: capex is easier to approve than a multi-year service obligation. "Budgets are easier to get, put the number X there. It is a one-off payment. And even though [service] is available, they will spend it" - but they are not ready to take on a commitment for several years.
Leasing and robots-as-a-service suit smaller and more flexible customers better. For a large budget, a one-off capex payment is easier to approve. This is a question of financing no less than a question of risk.
The robots-as-a-service operator explains that the question of a new round hung in the balance. In an era when "people raise gigantic rounds just for the sake of raising", the company had a position: the robot fleet was already gross-margin positive and generating revenue.
What moved the decision was concrete work done about half a year earlier. The speaker describes it this way: documenting all the tasks at the factories, about 2,000 different manual tasks performed today in various shops. From that list they derived which hardware form factors were needed for those tasks, and they raised capital to build those systems in sequence.
First the list of tasks, then the hardware form factors from the list, then money for a specific build. The robot is designed not on its own but as an answer to a specific list of jobs.
The investor formulates a pattern of technology adoption: there are early adopters and late ones. In his words, "large German companies, large Japanese companies are late adopters, there is no question about that." The early ones are those for whom the question is a question of survival.
"If you want early adopters, go to those for whom it is necessary. Their existence depends on it. And second, to those who make decisions fast."
Concretely, these are small and medium manufacturers. For them it is about the next order and about survival: they look at margin and ask how to compete for the next order if you cannot cut about 30 percent of costs or raise output by roughly the same 30 percent. That is the type of buyer ready to take a risk.
On retention the speaker gives a figure he himself calls self-reported: about 98 percent, "the retention rate of our robots". The logic is simple: once the benefit is proven, the robot stays in place, because the problem has already been solved.
"98 percent" is the speaker's self-report, spoken as heard twice in different ways ("98% rule rate", "retention observation"). The original transcript wording is distorted; the meaning is reliable only as "high retention", not as an exact metric.
The speaker has a separate warning about selling "loud names". Everyone loves to sell to big brands, but it is exactly they who are not ready to take a risk first in a new category. At the same time they have a different set of requirements: they need to be brought not a piece of hardware but a more complete solution.
The delivery-fleet operator talks about several sales fronts. The first is delivery: it started with a pilot that ended in a one-year contract, and then scaled to more than 40 university campuses.
The second front is media and events. He speaks of more than 100 events in 20 countries. Here the buyers are different: venues, media buyers, insurers, certification bodies. Each of them can say "no", and each creates a separate barrier.
"Nobody will say "yes", because if you say "yes" you can be wrong and get into trouble. It is an uphill battle. But once you have broken through and can present it as proof, the next events are much easier."
The speaker mentions a specific example in the media segment, where he calls "kiwi bot" the main player - probably a delivery operator of the Kiwibot type (a guess read from the garbled fragment). He then speaks of reaching more than ten events with a cloud provider under the abbreviation AWS. The speaker's overall conclusion: there is no single magic pill; what matters more is understanding who your buyer is, and that trust is the most important thing, especially while most people do not trust robots.
| Front | Buyer | Gate / barrier | Scale (self-reported) |
|---|---|---|---|
| Delivery | Campuses | Pilot → contract | more than 40 campuses, annual contract |
| Media and events | Venues, media buyers | Insurance, certification, a "no" from the venue | more than 100 events in 20 countries |
| Corporate | Large brands | Scepticism, slow decision-making | rarely first |
The moderator asks what counts as real deployment. The robots-as-a-service operator answers through tenure and money: the real test is not in delivering the robot, but in whether it is still working 12, 24 and 36 months later. His phrasing about proof: "the only proof is money in the bank".
It is one thing to ship a robot. Another is that it is still working 12 months later. 24. 36 months later. That is deployment, and it is not easy.
The investor offers a counter-metric that catches the case where a robot is delivered, paid for, but not used. Instead of "money in the bank" he looks at hours of use, tracked daily, because revenue is a lagging indicator: a customer may have paid years in advance but not use the robot because of downtime or line load.
The speaker gives a figure for the whole fleet: about 4,800 hours of use at the time of the conversation (self-reported). The leading indicator is hours of use, and for each robot they look at whether it is more or less than the day before.
Revenue lags: the customer pays but may not use the robot. Hours of use lead: they show whether the robot is bringing benefit right now. Both are needed; neither replaces the other.
An audience member doubts that the stated fleet uptime is achievable and asks whether staff are kept on site. The robots-as-a-service operator answers with the design of the service, not with staff at every site.
The model is this: regional coverage, third-party service teams, a remote command centre. In his words, about 70 percent of problems are solved remotely and the rest require a visit. He gives two figures: average time to response about 10 minutes, average time to resolution about 2 hours.
"One of the preconditions for this is the deployment base. One robot here, one robot there is very hard to do." Maintenance does not scale without a density of sites.
An audience member asks how the operator found his first customer while unknown. The answer is about personal relationships and not only the product.
The operator describes the approach: build personal relationships, walk in and say "I founded this company to help people like you, I built this and I take responsibility for performance". Many manufacturing businesses are still run by their founders, and founder-to-founder outreach works.
The speaker names the second technique outright: point out how bad the alternatives are. The concrete image he uses is "the robot graveyard in the corner": someone bought something under a cheaper model because the budget was easier to approve, bought "some junk", and it worked for a few months and then stopped.
"That is part of our marketing now: avoiding the 'walk of shame'. There is shame, everyone is embarrassed, nobody talks about it, something ugly sits in the corner, covered up and forgotten by everyone. We say it straight: that experiment did not work, let us try something else."
And an honest admission the operator makes himself: "the first two deployments went poorly. We had a lot of failures, we pushed through it, got burned, but came out the other side".
The first two deployments went badly: a direct quote from the robots-as-a-service operator. This is not an analyst's mistake and not gossip: the speaker himself calls it part of the path.
Returning to the subject of pilots, the operator explains why refusing proofs of concept is not a dogma but a calculation. Even a successful pilot may not lead to a purchase order, and a large buyer is structurally motivated to switch to a cheaper solution as soon as one appears.
"A large company is by its nature interested in having ten other proposals. As soon as it becomes possible, they will switch to the cheaper one. A proof of concept is a kind of self-deception: you think you are making progress, but it is usually not a production environment."
The conclusion follows: the vendor prefers a production deployment right away with responsibility for the result, because it is the only path that either yields money or does not, with no intermediate stage in which the customer gets free validation and walks away.
An audience member asks about the shares of different robot types in the operator's fleet. The speaker answers with a trajectory, not with percentages.
The start is closed environments such as university campuses, where the product found a market and continues to grow. Then came internal logistics, which picked up the same form factor and some of the same cameras. The fastest-growing direction is humanoid-type work.
Closed environments → internal logistics on the same form factor → humanoid work as the fastest-growing part. The moderator earlier names "63 different robots" of types; the term itself in the transcript sounds like a listing of mobile robots, industrial manipulators and humanoids.
| Wave | Environment | What is reused | Status according to the speaker |
|---|---|---|---|
| First | Closed environments (campuses) | Product and market | Mature, growing |
| Second | Internal logistics | Form factor and some cameras | Being established |
| Third | Humanoid work | New form factors | Fastest-growing |
Panel two. Roles: a founder deploying humanoids in data centres (claims a bachelor's and master's in computer science at Stanford, work in a scalable-AI lab, and launching the company in June); a founder selling dexterous hand hardware with a data pipeline and an exoskeleton; a founder with a foundation model over primitives (works with partners in Japan and Korea); a founder working on an exoskeleton for data collection and haptic feedback. The moderator runs the session. Names are distorted by recognition.
The data-centre robotics founder states the thesis narrowly: robots inside data centres for cabling, routine maintenance and replacement of hot-swappable components. It is about humanoids, mobile manipulators and simply hands that do "what a smart person in the hall would do" - internet and fibre cabling, hot-swapping components at the rack level.
The geography she names: robots already deployed inside a customer site in San Francisco and a robot at a large colocation site in San Jose. The reason thesis: more and more compute needs to be built and maintained, so the work "is meant to be roboticised".
Ever more compute is needed, it has to be built and maintained, so work in the data centre is meant to be roboticised. The narrow vertical is chosen deliberately: it makes integration solvable.
To the question of what breaks first on site, the answer is consolidated: hands and force-torque sensors are the most fragile parts. One of the speakers notes: "however long we wait, they need to be far more reliable".
"We used to think the model was the hardest part. But the model is only part of it." It was the hardware that turned out to be hard, not the training.
The data-centre robotics founder adds a lesson about the environment: "the world is not friendly to automation at all". Concrete examples she names:
The constraints of the environment must be accepted and worked around, not demanded away. "All of this surfaces during deployment, and it cannot be solved unless you want to retune the environment, which I think will happen gradually."
The moderator asks where a pilot usually gets stuck: hardware, model generalisation or on-site integration. The answer separates three stages.
Model generalisation as a problem is removed at the environment-reproduction stage: first the team works out which tasks to take, then in the lab it tries to recreate the site as closely as possible and deploy the robot, and at that stage data is collected and the model is finished: "at that stage model generalisation is not a problem, because they collect data".
The long pole is integration. And separately, the question of safety, which the speaker considers central to integration.
Many learned policies have no built-in safety layer on top of what is running. A robot may walk up to a sink and try to wash the dishes, not understanding that the environment is not the one. So a robust internal CI/CD pipeline of checks is needed, one that gates every action.
The mechanics the speaker describes: if the robot does not have a certain reliability threshold for a specific task, the action must go to a human. The check decides whether the task is fully autonomous or an operator must step in.
The panel's most concrete technical account is about the first week at a customer site. The data-centre robotics founder describes what surprised her most during the initial install.
The first thing is OEM variation. A server is the same regardless of the vendor, but the way it slides into the rack or attaches to it differs: with rails from different manufacturers (Supermicro and Dell are named; HPE and Exact are also mentioned: the reading of the vendor names is approximate, a guess read from the garbled fragment) the alignment and the slide-in differ, and this is "something you would never expect to be annoying, but it is".
The second is that after installation everything becomes far more deterministic and compliant. Inside the rack everything lies on a Cartesian plane: the switch is always parallel to the rectangular base of the rack, connectors are spaced apart, fans are aligned. This geometry can be used to make the task solvable.
The complicating variables: ceiling height, the presence of a raised floor, aisle width. But since the customer owns the site, he hands over the information in advance, from which a high-precision digital twin of the expected environment is built.
To the question of how long a new site takes, the answer is honest: it depends. The typical path is this: first a tour and information from the customer, from which a digital twin is built; then they start with a limited zone.
A concrete example of a limited zone is "a 30-kilowatt cage with 10 cabinets". In such cases installation and deployment can take one to two weeks. For a hypothetical deployment of 100 robots at a hyperscaler the picture is different: 30 kilowatts is a "rounding error" for a hyperscaler, and it has to reckon the benefit, and its revenue on cloud infrastructure is such that 30 kilowatts means nothing.
"The most important thing for us is to deploy as fast as possible, put the robots on the ground and make them touch very fragile, very expensive equipment." First autonomy in parts, then all at once.
And the key reason: data. The speaker stresses that the value and the "alpha" are precisely in deployment, because a data centre "will never have petabytes of data, never." You have to deploy in order to uncover all the use cases and edge cases that are otherwise unpredictable.
No data centre will ever hand over petabytes of data. Deployment is the only way to get data. This is what makes the "deployment first" doctrine the only option for this vertical.
The moderator asks what needs to be standardised to go "from site 2 to site 20". The founder's answer: focus on one vertical - data centres - and within it on the specific task of "smart hands" versus remote hands.
The logic: then you know how many rack units are in a rack, how many kilowatts each robot serves and how many times a day it needs to do something. A robot, in her words, can be regarded as a machine that is switched on a few times a day, not as a butler on 24/7.
Hence the contrast with a home humanoid robot, which is far harder: every apartment is different (pets, children, layouts, stairs, lifts), and the consumer buyer expects constant availability round the clock. In a data centre the routine is known in advance, and a human is not supposed to be there around the clock either.
At home every apartment is different and the consumer expects a butler, switched on 24/7. That is extremely hard and almost impossible to de-risk. In a data centre the routine is known, because it is a narrow vertical with known action triggers.
In addition, the vertical benefits from standardisation of the environment itself: server racks, data-centre layout, hot and cold aisles, common conventions on rack width and height. The speaker stresses that she came to the problem from the data-centre side, not the robotics side, and that this allowed her first to understand which tasks needed automating and whether there was a financial case in it.
The founder with a foundation model describes it this way: one model works over several defined classes of entities, and he names the number 57 primitives (self-reported). Above it is a mapping layer that carries the model onto different embodiments; he mentions around 5-6 such embodiments and partners.
Then comes an accuracy trajectory that he reckons by stage: about 70 percent in the lab, about 90 percent after deployment, and reaching production quality in roughly four months. The key mechanism is feedback: deployment data goes back into pretraining, and "the next time we roll out the same task, we are no longer at 78 percent but at 90".
An internal KPI he names for the new architecture: to produce dexterous tasks at a rate of about 500-600 episodes per week across all dexterous tasks.
The hand-hardware founder tells a story that became a rule of the panel. The task is to pick up a thin bracket a few millimetres across. They started with a hand of 15 degrees of freedom. The problem: it has no movement in the last segment of the finger, and fingers have three segments; without the last segment the bracket cannot be gripped.
They moved to a hand the speaker calls 31 degrees of freedom. It worked: "wow, it works, now we can tell the customer we can do this." But on the very first day it broke, and it had to be shipped back to China for repair.
"There is an inverse correlation between degrees of freedom, what we can do, and robustness." The more complexity, the higher the failure rate. That is why research wants humanoid hands while deployment cannot afford them: "complexity and failure rate rise together, almost exponentially."
The founder with a background at Tesla and Apple builds a reliability ladder from consumer electronics to automotive and robotics.
He explains that a humanoid robot is an interesting category standing between two benchmarks. The automotive industry gives "practically the highest reliability standard among consumer goods". Consumer electronics aims at a lifecycle of a few years: a phone is replaced in about two years, and testing is defined by that term.
Then comes a calculation he links to his experience working on the hand at Tesla: a benchmark of 100,000 cycles at first, but research shows that an assembly worker opens and closes the hand around 70,000 times a day. With a two-year lifecycle this gives about 2,000,000 cycles.
Today's hardware is at the level of hundreds of thousands of cycles, which under such a load is about three months of the same service. "We are still far off." And that is only the hand itself.
Separately he notes the risk of falling and battery safety: the robot falls, the battery is damaged, "everything can explode". This, in his words, could hit the industry hard.
The panel's most substantive dispute is about the quality of data. The hand-hardware founder separates teleoperation from natural human motion.
Teleoperation, in his words, is "up to a point the only way to get to a real robot", that is, high precision on a real robot. But it is not natural human motion: you are driving another body, relying only on vision, so jitter appears, the object finds its own equilibrium, and "it is not how a human does it".
A human brings a hand to an object and gets instant tactile feedback from the skin: he balances the object before reading it. Teleoperation does not give that. So teleoperation is a bridge, not the best solution.
The way out he proposes is an exoskeleton or a data glove with "joint-to-joint" mapping and haptic feedback. He stresses that it is not a calibration algorithm but precisely a direct joint-to-joint mapping that gives high control. And such a device, besides data collection, becomes an operational tool for the last percent of the long tail: even at 99 percent autonomy there will remain one percent where a human is needed.
The second panel discusses synthetic data. The founder with a foundation model says teleoperation is the best of what is available but not the best possible, and that is why he runs research with world models: to understand when the hand touches an object, what pressure and force arise. The goal is not to depend on human data because of cost, time and quality.
The data-centre robotics founder describes internal work: benchmarks for agents, where an LLM effectively runs the data centre. Through high-level abstractions the agents "puppeteer" the robot and perform tasks like "this part broke, go power-cycle the server" in a high-fidelity simulation of a real data centre.
Synthetic data shows a rise in performance for limited insert-extract tasks: pulling and inserting cables and components without damage. But the caveat is honest: it does not replace real data in the general case.
The caveat matters for the document's honesty: the speaker does not claim outright that synthetic data replaces real data everywhere. It is useful where everything is constrained and the tasks are narrow.
From the audience a person with experience in iPhone product design and reliability asks a question: it is unclear when roboticists decide that something is ready for deployment. The data-centre robotics founder's answer is a description of a readiness pipeline.
| Readiness layer | What it does | Role of the human |
|---|---|---|
| Internal CI/CD gate | Safety check before every action; without a "go" the robot does not act | A remote operator picks it up |
| World model in the loop | "Thinks through" the next step; if it is outside preapproved states, the action is not performed | Ping to the operator |
| Offshore teleoperation team | Drives the robot when autonomy is not ready | The operator performs the task |
| Customer acceptance of teleoperation | Some customers agree to teleoperation (for example, remote power cycle) | Customer consent |
| Data collection and policy crash test | Data returns and retrains the policy up to full autonomy | The final decision on the phase |
The speaker stresses why the model in the loop is fundamental: if the next step does not correspond to preapproved states, the robot simply does not do it and calls an operator, because "who will pay for a damaged, very expensive and fragile server".
The second speaker formulates readiness as a set of KPIs: does it work, does it work reliably, does it work with the required throughput, is it safe - and if a task passes them at every step, it is ready, but always with a fallback.
The investor from panel one divides the industry into three categories and predicts where the companies valued at 10 billion dollars will be: robots, model companies and integrators.
In his words, the middle layer - model companies - is "most likely in China, simply in terms of hardware density and the supply chain, it is already far ahead". On models he expects many models: open, very good, and specialised for different tasks.
In the world of LLMs one model serves all clients. In robotics the model will have to be adapted to the task and the requirements of a specific customer, so architecturally everything is different: many models that must be dynamically routed.
For simple or safety-related motions the vendor uses deterministic control, not a probabilistic model: "you do not want to use a probabilistic model where there is safety risk, a simple linear move". For the remaining subtasks, learned policies. The dynamic routing between them is the central task, and deployment data is the moat.
The investor answers a question about manufacturing in the US. He acknowledges that American domestic manufacturing would have real benefits, but considers it a "losing race" by the nature of volume and scale.
"A protected ecosystem by definition produces worse products, because if the products were better, protection would not be needed. They would sell themselves without it. The only reason this exists is because you are not better."
He adds that one has to look at the real picture of the world and that much work lies ahead in educating the public and the government. That is, he presents the China thesis as structural but not simple: the value of domestic manufacturing is acknowledged, as is the need for external education.
The investor answers the question of who owns the data and separates three things. Part of the data the vendor collects, he owns. Part is governed by individual laws and depends on the jurisdiction, and this is tied to the customer's site. Hence the requirement for contractual clarity.
Equipment that guarantees that the data belongs to you and is used by you is something worth negotiating over time, so that it is clear whether you own it and use it. Different parts of the data are governed differently.
| Type of data | Who owns it | What determines it |
|---|---|---|
| Collected by the vendor | The vendor | The contract with the customer |
| Under individual laws | Depends on the jurisdiction | Geography and the customer's site |
| At the customer's site | Requires an explicit agreement | Contractual clarity, equipment |
The last question from the hall carries the most concrete sceptical anchor of the whole panel. The audience member, introducing himself (it sounds like Alex, a manager at a company whose name in the transcript is distorted), gives two quotes.
The first is from a representative of a company that spoke at the World Robot Conference, who, he says, expects "no more than about 280 hours from his robot for working for investors", which when working all day is about ten days to a breakdown.
The second is from a founder (the transcript gives a name that is not reproduced here), who said that "the biggest problem is keeping a robot working for a week, just a whole week without a breakdown".
"Today for humanoids it is mostly dancing, boxing and fighting. The hardware can be specified: engineers have clear requirements. But the problem is that the whole humanoid system has to be AI-controllable, and the AI model that works for sport is not ready today."
The panel's answer to the question of real applications of humanoids today is honest and sceptical: use is still mostly performance and entertainment, and the contact-AI stack is not ready. One of the founders summarises: the solution is to design for a specific task, not for everything at once.
The audience member describes a familiar situation: a friend sells "egocentric", precise data for robotics so that companies can do post-training before they collect data at scale, and he himself describes his business as a commodity, a "race to the bottom", where data will soon become worthless, so one has to earn now.
The panel's answer splits into two parts, and this is an important divergence.
"The cost of data is definitely falling, especially for pretraining. Half a year ago it was a million hours of people; now it is just one-two-three for 95 percent." That is, for pretraining data is getting cheaper fast.
For post-training, high-quality data is still needed, and here it is about quality, not quantity. Annotation is becoming more efficient. But to open a pure data company today is a doubtful bet.
The bottom line: the panel does not think data will be fully devalued. It separates pretraining (where the cost is falling) and post-training (where quality still decides). The direct answer to the question about the friend's business: starting a pure data company now is a question with a doubtful answer.
Every number is marked as stated by the speaker; the source is an automatic speech transcript, and the numbers are not independently confirmed.
| Number | Context | Speaker role |
|---|---|---|
| ~$6M | the size of the fund he managed | investor |
| ~35 | companies funded | investor |
| ~20 years | lived in China | investor |
| 8 | factories built before that | investor |
| more than 500 | fleet robots deployed in 4 countries | delivery-fleet operator |
| ~150 | factories across the US under ownership and operation | robots-as-a-service operator |
| ×2 | how much a fence doubles the investment | robots-as-a-service operator |
| 85% | a lab uptime is a failure, not a success | investor |
| 99 / 3 nines | the minimum production bar | investor |
| 99.99% | the overall target of the product of three factors | investor |
| 10,000 | cycles a day; hundreds of failures are unacceptable | investor |
| 99.96% | fleet uptime across 150 factories | robots-as-a-service operator |
| 98% | robot retention (wording distorted) | robots-as-a-service operator |
| ~30% | cut costs or raise output | investor |
| more than 40 | university campuses on an annual contract | delivery-fleet operator |
| more than 100 | events in 20 countries | delivery-fleet operator |
| 4,800 | hours of use across the fleet | investor |
| ~70% | of problems solved remotely | robots-as-a-service operator |
| ~10 min | average time to response | robots-as-a-service operator |
| ~2 h | average time to resolution | robots-as-a-service operator |
| ~2,000 | manual tasks documented in half a year | robots-as-a-service operator |
| 63 | robot types named by the moderator | moderator |
| 57 | primitives in the foundation model | model founder |
| 5-6 | embodiments through the mapping layer | model founder |
| ~70% | accuracy in the lab | model founder |
| ~90% | accuracy after deployment | model founder |
| 78% → 90% | the start of the next instance of the task | model founder |
| ~4 mo | to production quality | model founder |
| 500-600 | dexterous-task episodes per week (KPI) | model founder |
| 15 | degrees of freedom of the hand that did not hold the bracket | hand-hardware founder |
| 31 | degrees of freedom of the hand that broke on the first day | hand-hardware founder |
| 70,000 | open-close cycles of the hand per day for an assembly worker | ex-Tesla/Apple founder |
| ~2,000,000 | target cycles over 2 years | ex-Tesla/Apple founder |
| ~3 mo | today's hardware life under such a load | ex-Tesla/Apple founder |
| ~280 h | the expectation to a breakdown, ≈10 days | audience member (quote) |
| 30 kW / 10 cabinets | the starting zone in the data centre | data-centre robotics founder |
| 1-2 weeks | integration in a limited zone | data-centre robotics founder |
| 100 | robots in the hypothetical hyperscaler deployment | data-centre robotics founder |
| 100 / 10,000 | units of hardware at a partner this year and next | hand-hardware founder |
| ~70,000 / 2M | hands: load and target for the robot | ex-Tesla/Apple founder |
Both transcripts come from automatic speech recognition and contain extensive distortion. Below is an honest list of what cannot be recovered and where a guess reading is given.
The panels give a rich picture of mechanisms and self-reported metrics, but systematically stay silent about a number of things, and it is worth keeping that in mind.
| Gap | Why it matters |
|---|---|
| Unit economics | Neither the price of a robot, nor the cost of deployment, nor the payback period in money is named - only shares and percentages. |
| Verifiability of the numbers | Uptime 99.96%, retention 98%, hours of use - all self-reported, unaudited. |
| Who exactly the customers are | Companies and names are hidden behind roles; independent verification is impossible. |
| Product identity | Even the robot types are named only generically; specific models are not identified. |
| Failures in figures | It is admitted that "the first two deployments went badly", but without metrics: how many, for how long, at what cost. |
| Data boundaries | It is said that there will be no petabytes from data centres, but not said how much data is actually collected. |
| Regulatory contour | Data ownership is declared jurisdiction-dependent, but specific regimes are not named. |
If both panels are reduced to one thought, it is not about robots but about responsibility. Panel one says the same thing in different words: the buyer does not buy hardware, he buys transferred risk, and a vendor that takes on uptime, maintenance, spare parts, insurance and payment only by result sells not a machine but a result. Hence the refusal of PoC, the compound uptime bar, and "money in the bank" as the only proof. Panel two descends to the site and shows what that responsibility costs in practice: it is hands and force-torque sensors that break, not models; the world is not friendly to automation; integration is the long pole; and the reliability gap is measured in cycles, where today's hardware lasts about three months against the two million cycles needed. Both panels converge at one end: while the contact-AI stack is not ready, honest applications of humanoids are narrow verticals for a specific task (data centre, cable, component swap), where the environment can be standardised, the robot switched on a few times a day, and a human left in the loop for the long tail. Everything else today is performance, and the panels say so plainly.
An analysis of two panels of one conference. The sources are two transcripts obtained by automatic speech recognition (41 KB and 51 KB), in places distorted beyond readability. Speakers are named by role; the names of people and companies are deliberately not recovered. All numbers are marked as stated by the speakers and are not independently confirmed. The document is assembled by the script build_panels_en.py and is not edited by hand.
ARLI membership: the notes from the workshop
One site of yours, measured, with the price for the work in the same document
ARLI, Inc., a Delaware corporation. Questions: hq@arliwork.com.