Two Agility statements went out within hours of each other, and read side by side they undercut each other.
One is a Bloomberg segment where, per Agility's post, CEO Peggy Johnson describes Digit deployed across nine customer sites with more than 65,000 hours of real-world operation. The other is a job posting for a Senior AI Software Engineer in Reinforcement Learning, to develop and deploy RL policies for locomotion, whole-body control, and manipulation on a humanoid "already working in production facilities."
If the robot is already working in production, why the hire to make it work better? Because the hours figure and the job posting describe the same gap from opposite ends. One markets the mileage. The other admits the mileage still needs a lot of human hands on the wheel.
This week Agility gave us hard hours and hard site counts. It still did not give us that number.
That omission is the whole story.
Sixty-five thousand hours across nine sites is a real milestone, and it deserves to be stated plainly as the most concrete scaling proof the industry has offered. It is also carefully chosen. Hours and sites are cumulative bragging metrics — they only go up, and they say nothing about how many people it took to produce them.
Robots-per-operator is the metric that separates a product from a service. A product's operator ratio climbs as software improves; you buy the unit, it mostly runs itself, support is exceptional. A service's ratio stays flat; every deployed unit needs its allotment of trained humans forever, and you are really renting labor with a robotics logo on the invoice.
Robots-per-operator is the metric that separates a product from a service. Nobody publishes the ratio because, right now, the ratio is unflattering.
Nobody publishes the ratio because, right now, the ratio is unflattering.
Christopher Bower of HireArt, writing in The Robot Report, describes what actually happens as fleets scale. The small, tightly coordinated team model — engineers close to the system, highly trained operators, everyone in the loop — "works well when there are five or 10 robots in controlled environments."
Then it breaks. "When deployments scale to dozens of sites across multiple shifts and inconsistent physical environments," Bower writes, "robotics stops behaving like a product launch and starts behaving like a distributed operations business."
Nine sites is exactly where that transition bites. Multiple shifts, inconsistent floors, escalation procedures — the coordination cost that stays invisible in a single flagship demo becomes the dominant line item across nine.
Agility's own marketing says as much, in a sentence more honest than the hours figure. "Deploying a humanoid isn't one big moment. It's a hundred small ones: mapping the space, integrating the systems, preparing the people."
Sit with the third item. Mapping and system integration get budgeted — they show up on a project plan with owners and dates. Preparing the people almost never gets priced with the same rigor, and it is the item that decides whether the robot gets used or quietly worked around by the shift.
That is the number every deployment cost model omits: not the robot, not the integration, but the shift supervisor learning to work next to it, and the operators, technicians, teleoperators, and QA validators standing behind it. That is the number that decides whether unit two gets ordered.
Bower sketches what that workforce is turning into, and it is not a lean support desk. It is a hybrid structure: a stable W-2 core of trained hourly operators and technicians who own SOP adherence and escalation, wrapped in a flexible surge layer for pilots and new-site launches.
His estimate of the common configuration is the part that should give buyers pause — "a common pattern is an even split between fixed and variable capacity." An even split. Half your operational labor is permanent, half flexes with every new deployment.
That is not the cost curve of a maturing product. That is the staffing model of a services business, and it scales with sites, not with software releases.
Bower is even more pointed about the roles themselves. Operators, field technicians, teleoperators, QA validators, and data capture specialists "sit between engineering and operations," responsible not just for running systems but for "interpreting edge cases, documenting failures, and translating real-world behavior into engineering feedback loops."
Translate that into plain terms: the humans are the sensors and the debuggers. They catch what the robot can't handle and feed it back upstream — which is precisely the loop that RL engineering job is meant to shorten.
So the two Agility posts resolve cleanly. The hours figure is the numerator of a fraction whose denominator the company won't print. The RL hire is Agility trying to shrink that denominator. Both are true; only one gets a Bloomberg segment.
Here is why this matters, and why it won't resolve on a software timeline. Two hard constraints sit under every deployed fleet, and neither is erased by a model update.
The first comes from Agility's own co-founder and Chief Robot Officer, Jonathan Hurst. Against the popular view that humanoid hardware becomes a commodity and software does the rest, Hurst argues the opposite: get the physics wrong, and no amount of AI makes up for it.
He is right, and the operational consequence is the point. As one commenter put it, software iterates in a sprint; hardware iterates in a field failure surfaced six months later. The parts that physically wear are the ones that decide whether a fleet stays up — and every unplanned failure calls a human back to the floor, pushing the operator ratio the wrong way.
The second constraint comes from Sanctuary AI's co-founder and Chief Engineering and Operations Officer, Olivia Norton, who names what separates a great demo from a production system: the final few percent of performance is the most challenging and the most important in industrial environments.
That last few percent is exactly where the human surge layer lives. It is the residue of edge cases too rare to train away and too consequential to ignore — and it is why the even split between fixed and variable labor persists instead of collapsing.
Now watch where the supply chain is placing its bet. Schaeffler has finished validation on its formed strain wave gearboxes and plans mass production in 2027, having already shipped more than two million formed strain wave gearboxes over the past decade.
Its pitch reportedly centers on the hardware bottleneck being real and priced. Strain wave gearboxes sit inside actuators, which make up around half the cost of building a humanoid. Schaeffler's forming process completes key manufacturing steps in seconds instead of minutes, reportedly cutting manufacturing cost by more than 25% and material consumption by more than 75%.
That, arguably, is a serious company betting real capital that Hurst is correct — that the physical bottleneck is worth industrializing years ahead of demand. The hardware constraint is being attacked with forming presses and a 2027 line.
The workforce constraint is being attacked with a job posting and a metric nobody will publish.
That asymmetry is the tell. Schaeffler is willing to name the hardware bottleneck because naming it justifies the factory. Humanoid makers are unwilling to name the workforce bottleneck because naming it would reprice the product as a service.
So here is the test to apply to every "production deployment" announcement from here forward. Hours and sites are the metrics you show when the ratio isn't ready. Robots-per-operator, rising over time, is the metric you show when it is.
Until a maker publishes that second number and lets it climb, 65,000 hours across nine sites describes a distributed labor business wearing a robotics logo — impressive, real, and staffed by more humans than the press cycle wants you to count.