The machine economy: agents, robots and devices as buyers

For most of computing history, machines have been tools that people buy. That is changing. Software agents now compare offers, call paid APIs, commission other agents and run multi-step tasks with little human input. Robots and devices in the field increasingly rely on AI models they do not host. In both cases a machine is the immediate buyer of AI work, and often other machines are the sellers.

This briefing is for decision makers who need to understand what has changed, what a machine needs in order to transact safely, and what to ask before letting machines in your organisation spend.

What changed in 2025 and 2026

The protocols arrived quickly, and most are now under neutral governance.

• Agents talking to agents. Google's Agent2Agent protocol moved to the Linux Foundation on 23 June 2025 as an open project for communication between agents.
• Agents using tools. The Model Context Protocol became a founding project of the Linux Foundation's Agentic AI Foundation, announced on 9 December 2025, alongside goose and AGENTS.md.
• Agents paying. Google announced the Agent Payments Protocol (AP2) on 16 September 2025 with more than 60 partners. It records what a user authorised as signed mandates: an intent mandate for the instruction and its limits, and a cart mandate for the exact items and price. On 23 September 2025, Cloudflare and Coinbase announced the x402 Foundation to promote x402, which revives the HTTP 402 "Payment Required" status code. A server answers with payment instructions, the client pays, and the resource is returned, with no account or API key needed.
• Card networks. Visa's Trusted Agent Protocol and Mastercard's Agent Pay give merchants ways to recognise approved agents and tell them apart from malicious bots, as Cloudflare describes.

Together these cover how agents find each other, use tools and pay. What they leave to the infrastructure underneath is the harder part: who the machine is, how far it may go and how the work is proven.

Four things a machine needs to transact

1. An identity someone answers for. A machine that pays or is paid must be identifiable. But an identity that answers only to itself is worthless, because anyone can mint thousands. There are two sound anchors. Either a person or institution delegated the machine and remains accountable for it, or an attestable hardware root of trust, such as a TPM or secure enclave, stands in for that party. Software agents should normally be delegated. Devices in the field can be rooted in hardware.

2. Bounded authority. Delegation without limits is a blank cheque. The limits need to be specific: per-transaction and daily spending caps, allowed counterparties and operations, and an expiry. They need to be enforced where the transaction is authorised, not checked in a report afterwards. Actions outside the limits should be held for a human decision, not simply rejected or allowed.

3. Budgets that cannot be exceeded. The safest form of authority is pre-funded. The owner funds the agent's wallet, and the agent can never spend more than was put in. The owner can pause it, reclaim unspent funds and allow refills under an allowance that expires. That reverses the usual risk: a misbehaving agent can lose its budget, not the organisation's.

4. Proof of what was delivered. When a machine buys inference or compute, the seller must be able to prove what it delivered: which model, on which machine, for which input, producing which output, metered in which units. Signed receipts that anyone can verify make machine-to-machine trade possible between parties that have never met. Disputes then rest on evidence, not on reputation alone.

Where the money and the work flow

Machine purchases are small, frequent and often chained. One user request might pay an app, an agent that orchestrates the task, a small model on an edge device and a large model on a GPU server. Three properties make this workable:

• Attribution. The payment record names each party in the chain, so each is paid directly instead of through layers of resellers.
• Bounded metering. Every billed unit is capped by what actually crossed the wire.
• Several rails. Agents will pay with mandates, HTTP 402 flows, cards and bank transfers, so infrastructure has to accept what the buyer holds and pay the seller in what it chose.

What decision makers should ask

Before letting machines in your organisation spend, or selling to machines, ask:

1. Who is accountable for each agent and device, and how is that recorded?
2. Where are spending limits enforced: in the agent's code, in a policy service, or at the point of authorisation?
3. Can an agent ever spend more than its owner funded?
4. What evidence do you receive for each purchase, and can you verify it without the seller?
5. How are out-of-scope actions escalated to a human?

For organisations in the EU, the AI Act's transparency obligations have applied since August 2026. Auditable records of what agents did, and on whose authority, will matter increasingly to regulators as well as to your own risk function.

What this means for CTOs and investors

For CTOs, agent payments are an access-control problem before they are a payments problem. Treat every agent as a principal with its own identity, scope and budget, and require receipts for everything it buys.

For those assessing infrastructure, the durable layer is unlikely to be any single payment protocol. It is likely to be the layer that ties identity, scope, metering and proof together across protocols, because buyers will use several.

Where Tenzro fits

Tenzro is an open network for the machine economy. Machines of every size, from edge devices to GPU servers, sell AI work to agents and apps. It is live in preview, and governance decides the steps to testnet and mainnet. What is built:

• Identity classes. One decentralised identity scheme covers humans, delegated agents acting under a controller, autonomous machines and legal entities anchored to their GLEIF LEI. A machine identity is admitted only if it is delegated or rooted in attestable hardware.
• Terms enforced by validators. A delegated agent acts within on-chain terms: per-transaction, hourly and daily limits, allowed operations, counterparties and chains, and an expiry. Every validator checks each action against them. Out-of-scope operations are parked for the controller's review.
• Owned, funded agents. Owners fund agent wallets. Agents cannot spend more than they were funded, and owners can pause them, reclaim funds and grant refill allowances that always expire.
• Payment protocols. AP2 mandate validation, x402 with a self-hosted facilitator and the Machine Payments Protocol are supported natively. Card-network protocols are handled by adapters in harnesses.
• Attribution and receipts. Settlements can name the app, agent and tool behind a payment and pay each directly. Inference receipts are signed by keys certified by the serving machine's hardware identity.

Planned: an edge role in which small devices host agent harnesses and small models and call GPU providers for large ones, with every party paid from the caller's budget. Settlement on the network uses TNZO, its unit for pricing and settling work. Fees are set in USD terms, and apps can pay on their users' behalf.