AGIBOT, the Shanghai company that IDC says shipped more humanoid robots than anyone in the first half of this year, spent part of its Innovation Day on Thursday proposing a unit of measure. They call it Worken, a mash of "work" and "token," and the formula fits on one line:
Worken = active robots × autonomous working hours × output efficiency ratio
The detail that caught me is in the second factor. AGIBOT says it counts time spent working autonomously, "rather than total powered-on time." The third factor scores acceptable output against a benchmark for the task. Their CTO put the point plainly: the industry has gotten good at counting robots built and delivered, and now it has to ask how much useful work they actually do.
It is a proposal, not a standard, and it is aimed at fleets of humanoids. But the question is the right one for any machine that runs itself. So I ran it against the one automated system whose every run I have on record: the sump pump in my basement, and the monitor that has been controlling it since February.
Factor one: one robot
Easy. One pump, one smart plug that can cut its power, and software deciding when to do that. It has been in service since February.
Factor two: who started the run?
My monitor happens to log every motor run, and it logs two kinds differently. When the system is in its normal state, the pump's own float switch decides: water lifts the float, the pump starts, the pit empties, the float drops, the pump stops. The monitor writes Pump stopped after 0.9 min. When the monitor decides the float is stuck, it switches to timed mode and pulses power on a schedule, writing TIER_3 cycle 2879: pump ran. One count of each, over the full log from February 23 to this morning:
| Who started it | Runs | Motor hours |
|---|---|---|
| The float (water) | 365 | 4.3 |
| The timer (software schedule) | 20,163 | 664.7 |
That is 669 hours of motor time, and the part of the system that senses water started 4.3 of them. Less than one percent. The other 99 percent were started by a clock.
I want to be careful here, because the easy headline is "99 percent wasted," and I can't show that. In timed mode the pump still only runs if its float is closed, and it draws about 490 watts at the end of almost every pulse, so the float is closed. A closed float means one of two things: there is water in the pit, or the switch is stuck. Those 664 hours could be real pumping. They could be a pump running against an empty pit. They are almost certainly some of each.
What I can say is that the system cannot tell the difference. Which brings me to the factor that matters.
Factor three: what did it accomplish?
For a sump pump, the output is water leaving the pit. My system measures none of it. It measures watts, plug temperature, line voltage and run time, all on the motor side of the pipe. Last week I found the watts are mostly a voltmeter, rising and falling with the grid rather than the water.
There is exactly one kind of event in the log that proves water was moved: the float opening on its own, because that only happens when the pit is empty. It shows up in two places. The 365 float-started runs all end that way. And 92 times since February, a timed pulse ended early because the pump stopped by itself. Those 457 events are the system's entire record of useful output.
Here is when they happened:
| Month | Float-started runs |
|---|---|
| February (last week) | 22 |
| March | 234 |
| April | 15 |
| May | 8 |
| June | 3 |
| July–August | 0 |
| September | 79 |
| October | 4 |
The last one of any kind was October 4 at 10:04 pm. Since October 6 the pump has been in timed mode continuously. In those 24 days it ran 2,879 pulses. All 2,879 ran the full two minutes. None ended early. That is about 96 motor hours and roughly 48 kilowatt-hours of electricity, and the log contains zero evidence that any water was moved.
It also has a benchmark it is failing. Worken's output ratio needs a reference, and for a sump pump the reference is free: rain. It has not rained here since October 16. Fourteen dry days, and the pump ran 119 pulses on every one of them, the same 119 it ran on the 14-millimeter day before the dry spell started. The pit has a history of emptying in about 30 seconds. A pump whose run count does not move with the weather is following its schedule, not the water.
So my pump's Worken for October is one robot, times 96 autonomous hours, times an output ratio I cannot compute. The honest score is "unknown," and a monitoring product that reported "96 hours of protection this month" would be reporting the controller's activity as the building's need.
The missing sensor costs less than the plug
The fix is not more AI. It is a sensor on the output. An ultrasonic or pressure level sensor in the pit, read by an ESP32-class microcontroller that costs about ten dollars, turns every pulse into a number: the water level fell this many centimeters, which is this many gallons. That is the third factor, measured directly. It would also settle the question this system has argued with itself about since March, whether the float is stuck or the pit is genuinely busy, because a stuck float pumping an empty pit and a working float keeping up with real water look identical in watts and completely different in level.
Until that is installed, the cheapest output sensor I have is me. The inspection I promised myself is now 245 days overdue, and the forecast is dry through Monday, which makes this the best possible week to do it: any water in that pit right now did not come from the sky.
Three questions for any automated system's report
Worken is AGIBOT's metric for its robots, and I don't know yet whether it will catch on. The structure is useful well beyond humanoids. Before you trust a report from a boiler controller, a pump monitor, an HVAC schedule or a robot fleet, ask:
- What started each run? A sensor reading a real need, or a schedule? If the logs can't say, the report is counting activity.
- Where is the output measured? Watts, hours and temperatures describe the machine. Gallons, degrees delivered, parts picked describe the work.
- What is the benchmark? Rain for a sump, outdoor temperature for a boiler, orders for a picker. If activity doesn't move when the benchmark does, the machine is running on its own clock.
Try it on your own logs: if your controller logs runs, count them per day and lay them next to the weather (or the orders, or the occupancy) for the same days. If the two columns don't move together, you have found the hours your system chose for itself. That is where the next inspection, or the next sensor, should go.
Want monitoring that counts the work, not the hours?
I build and audit monitoring for small buildings: sump pumps, boilers, compressors, anything with a motor and a power draw. Every install I do measures the output side, so the monthly report says what the building needed and whether it got it.
See the Physical AI practice