If a factory needs 10,000 material transfers a day, why must it buy a robot first?
If a household needs a few hours of help each week, why must it pay for an entire machine, its repairs, and its idle time?
These are the questions I want to ask ahead of CES 2027.
What a robot can do sets the limits of the technology. How customers can buy its work sets the limits of the market.
The next contest in Physical AI may be decided by what appears on the invoice: a robot, or work completed to an agreed standard.
How an industry changes the unit on its invoice
We already buy kilowatt-hours, cloud usage, and model tokens without building a power station, data center, or model cluster for every use.
These units measure different things: energy, computing resources, and discrete units of content processed by a model. None directly guarantees a particular economic benefit for the customer.
They do lower a common barrier: customers access capacity when needed, while specialists provision and maintain the assets.
Robotics is exploring the same approach. The multiyear partnership GXO and Agility Robotics announced in 2024 uses Robotics-as-a-Service. But service delivery is only the beginning: long-term leasing, hourly use, and payment per accepted task remain different contracts.Partnership announcement
A robot can run for an hour without completing the agreed work. For the customer, the difference is whether the result passes inspection.
From numbers, bits, and tokens to Proken
Here is how I think about the next step:
Numbers express quantities; bits encode information; tokens let models process content. Proken would provide a way to record physical work, verify it, and settle payment for it.
This connects quantity, information, model processing, and task trading as a narrative, not a strict scientific classification or sequence of technological generations. Numbers are abstract representations, bits are binary information units, and model tokens come from tokenization or other encoding schemes. They operate at different levels and will continue to coexist.
Proken is the name I propose for this discussion: Productivity Token.
It is a design proposal, not an established industry standard. Productivity describes the ambition; strictly speaking, it initially measures accepted work. Productivity requires comparing outputs of comparable quality with the inputs used, such as accepted output per labor-hour. Including capital, energy, and other inputs also requires consistent accounting.
Define one unit of work first
A kilowatt-hour can power different devices. A material transfer is not inherently a standardized product.
Moving a light box two meters and carrying a fragile object upstairs cannot count as identical work simply because both involve moving things. The object, route, load, deadline, safety requirements, and damage criteria must be agreed in advance.
Proken should therefore begin with task catalogs for specific settings, without claiming to standardize all labor from the outset.
For example, on a fixed warehouse route, the parties might agree that a box within a specified weight range must arrive from A to B on time, correctly positioned, undamaged, and in compliance with safety requirements to qualify as an accepted task.
A robot makes 100 attempts; 92 pass acceptance. At an agreed two Proken per task, the record is 184 Proken.
These numbers are illustrative. The principle is:Define acceptance before counting work.
The eight failed attempts do not enter the accepted-work ledger. Their electricity, time, maintenance, and human intervention must still enter the cost ledger. The contract determines charges for failures, customer-caused exceptions, and any minimum service fee.
An initial measurement rule can be simple:
Accepted work = the sum of accepted tasks in each category multiplied by that category's agreed reference weight.
Weights may refer to standard labor-hours or existing industry measures such as item counts, area, or tonne-kilometers. Labor time is a comparison benchmark, not an automatic market price. If standard time already reflects difficulty, adding an arbitrary complexity factor would count it twice.
Under one task specification, humanoids, wheeled manipulators, and other compatible equipment should deliver under the same acceptance rules. Customers would be free to choose the equipment.
Conversion across settings needs further conditions. Cleaning and material handling can share an invoice; adding them together does not make them interchangeable everywhere.
Fractional subscriptions: buy the work you need
By fractional subscriptions, I mean buying service in smaller increments.
Customers could subscribe to a two-hour daily service window, buy 500 accepted transfers a week, or submit demand to a compatible fleet whose operator schedules delivery.
Each customer need not own a whole robot. A small business could try automation without funding the entire machine upfront. Operators would need to combine customers' demand into enough orders to sustain a fleet.
Sharing also has clear limits.
Robots must perform physical work on site. Staggered orders within one campus could improve utilization; dispersed household orders could lose those gains to transport, reconfiguration, and waiting.
Software can serve many users at once. A robot usually occupies one physical location and performs a limited set of tasks at a time. A cloud interface does not remove that constraint.
The most promising place to test this may be recurring demand within one warehouse, factory, campus, or neighborhood: similar tasks, short distances, staggered schedules, and clear acceptance criteria.
Shared asset ownership is a separate design question. Buying service credits and owning robot assets with a claim on returns confer different rights and should be explained separately.
Account for the full cost of each unit of work
A manufacturer earns equipment revenue when it sells a robot. A fleet operator must pay for equipment and deployment before gradually recovering that investment through ongoing delivery.
Revenue may become steadier, even as the upfront cash requirement grows.
A credible business report should answer at least five questions:
- How much available service time becomes accepted work? Include waiting, maintenance, and task changeovers.
- What is the full delivery cost per unit of accepted work? Include human support, retries, energy, maintenance, and depreciation.
- Why do customers renew? Because the service keeps saving money, improving quality, or providing capabilities previously out of reach.
- Who bears idle-capacity and breakdown risk? Allocate it explicitly among manufacturers, financiers, operators, and customers.
- When will cash flow recover the initial investment? Accounting gross profit is not the same as cash available to recover the investment.
Outcome-based pricing may align incentives, but creates new questions. Will operators cherry-pick easy tasks? Will acceptance be delayed? Who absorbs losses when a customer changes the environment?
Standard task catalogs, exception handling, spot checks, and dispute mechanisms should arrive with the robot.
The signals I will look for at CES 2027
I will look beyond the stage for four things:
- Clear task specifications and acceptance criteria.
- Continuous-operation data that disclose human intervention, failures, and downtime.
- Orders that cover real costs, including maintenance and financing.
- Task packages customers can buy without taking on an entire machine.
Clear answers would open another route to growth for Physical AI. Customers would only need to trust that the next task will be completed as agreed, rather than believe in a distant robotic future.
Proken can begin as a way to record work. Whether it should become a cross-platform settlement tool, or even a cryptoasset, is the subject of the next essay.
Make the results trustworthy, then make buying the work accessible.
Which task in your industry is already defined well enough to buy on the basis of accepted results?