Robots are no longer rare capital equipment. The International Federation of Robotics counted 542,000 industrial robots installed in 2024, more than double the level of a decade earlier and the fourth year in a row above half a million, with an operational stock of about 4.66 million units. Asia accounted for 74 percent of new deployments, Europe 16 percent and the Americas 9 percent.
At the same time, the models that give robots perception and planning keep getting larger. Vision-language-action models, world models and large perception backbones often exceed what a robot's on-board computer can run at useful speed. That turns a robot into a buyer of compute. And the data and work a robot produces (inspections, maps, measurements, deliveries) are things others will pay for. That turns it into a seller.
This article covers what a machine needs to do both safely.
Where should the inference run?
Physical systems have hard timing. A control loop that misses its deadline is a safety issue, not a slow page. Research on vision-language-action inference makes the trade-off explicit: Jiang et al. (2026) analyse whether such inference should run on-device, on edge servers or in the cloud, and show that hardware capability and network performance jointly determine end-to-end latency under strict real-time constraints.
A practical split:
| Loop | Timing | Where |
|---|---|---|
| Safety and motor control | Milliseconds, hard deadline | On board, always |
| Perception for the current action | Tens of milliseconds | On board or a nearby edge server on the same network |
| Task planning and replanning | Hundreds of milliseconds to seconds | Edge server or regional GPU |
| Learning, simulation, fleet analytics | Minutes to hours | Wherever capacity is cheapest |
The takeaway: keep anything safety-critical local, and treat everything above it as work that can be placed, priced and bought.
A robot as a buyer
Once a robot buys inference from someone else's machine, four questions arise that a single-vendor cloud contract used to hide.
Who is paying? The robot needs its own identity, separate from its operator's account, so that its spending can be attributed, limited and revoked. That identity should be anchored in hardware that cannot be cloned (a TPM or secure element), not in a serial number any program on the device can read.
How much may it spend? A fleet of a thousand robots each with an open credit line is a financial risk. A funded budget per robot, with refills under an allowance that expires, puts a hard ceiling on what any compromised unit can lose.
How does it pay per request? Machine payments over HTTP are becoming standard. x402 uses the HTTP 402 status code: a server answers an unpaid request with payment terms, and the client pays and retries. For inference whose cost is only known afterwards, the useful pattern is to sign a ceiling and settle the actual.
How does the server know which robot is calling? HTTP Message Signatures (RFC 9421) let a device sign each request, so a provider can verify the caller per request rather than per long-lived token.
A robot as a seller
Robots generate data with commercial value: shelf scans for retailers, defect images for manufacturers, map updates, environmental readings. Selling it requires a buyer to trust that a reading came from a specific device at a specific time and was not altered. That means:
- the device signs each reading with its hardware-held key;
- the signature covers a digest of the payload and the measurement time;
- the buyer can verify the signature against a public record of the device's key, without trusting the seller's database;
- payment for delivered data or completed work is released only when the evidence checks out.
The same pattern covers work, not just data: a delivery robot proving it reached a location, or an inspection drone proving it captured a structure.
Simulation and world models feed the loop
Training physical AI increasingly relies on synthetic data from simulators and generative world models, which are compute-hungry and well suited to batch placement on whatever GPUs are idle. A fleet that buys perception at the edge by day can buy simulation and world-model rollouts overnight.
Regional notes
Asia dominates installations, so latency-sensitive services for robots need capacity close to East Asian manufacturing hubs. In the EU, machine safety rules and the AI Act's treatment of safety components shape what may be offloaded; personal data captured by cameras falls under GDPR. In the US, sector rules (workplace safety, aviation for drones) dominate. In every region, keeping the safety loop on board avoids most of the difficulty.
What this means for robotics builders and hardware makers
- Ship every unit with an attestable hardware root of trust and expose it to the software stack.
- Give each robot its own identity and funded budget, not a shared fleet API key.
- Design the software so planning and perception can call remote models with a deadline and a local fallback.
- Sign sensor output at the source if you ever expect to sell it.
Where Tenzro fits
Tenzro is an open network where machines of every size sell AI work and agents and apps buy it. For physical AI, what exists today is:
- Hardware-rooted machine identity. A machine is admitted only if a person or institution delegated it or an attestable root of trust anchors it. The graded identity sources include TPM 2.0, Apple Secure Enclave, ATECC608 and SE050 secure elements and the ESP32 digital-signature peripheral; readable serials and GPU identifiers are never accepted as identity. A device without a TPM, such as a Raspberry Pi, can keep its identity key in another machine's TPM.
- Funded budgets. An agent's wallet can never spend more than its owner funded; it can be paused, its funds reclaimed, and refills allowed only under an expiring allowance.
- Pay per request. Nodes answer unpaid requests with an x402 challenge under a ceiling scheme and settle the actual metered cost after the response.
- Signed sensor readings. A
sensor_dataevidence item carries the measuring device's signature over the payload digest and measurement time, checked bytenzro_verifyEvidenceagainst the key the device registered, so an application can verify delivery before releasing an escrow. - Perception models on the network. Providers serve detection (RF-DETR, D-FINE), segmentation (SAM 2, SAM 3, EdgeSAM, MobileSAM) and vision embeddings; the generative media surface includes world-model and action-policy job kinds, with one world model running natively and others planned until their ports pass checks.
Not built: running models on the edge tier itself. Today's edge build forwards model calls to providers on the network; a small-GPU variant for Jetson-class modules and a harness-host role are planned. The network is live in preview. See tenzro.com.
