If you run AI infrastructure, the machines are not the hard part. You have already built or bought them, powered them, cooled them and put models on them. The hard part is the demand around them: finding buyers, agreeing terms, pricing work that arrives in very small units, and being confident of getting paid.
That last point is changing shape. A growing share of AI demand comes from software rather than from a procurement team: agents and applications calling models in the middle of a task, choosing a supplier at the moment of the call. For an operator, that is a large and growing pool of work. It is also a pool of counterparties you have never met, will never sign a contract with, and could not chase for an unpaid invoice if you wanted to. Tenzro is the open settlement and coordination layer that sits underneath that demand: it routes the calls to you, carries each agent's authority and limits, and settles every call you serve.
This article explains how demand reaches an operator's capacity through Tenzro, and how per-call settlement and signed receipts change the counterparty question.
How demand reaches your machines
Agents and applications reach Tenzro through the interfaces they already use: OpenAI-compatible routes for chat completions, responses, embeddings and audio transcription, served by every node. That demand arrives through several channels on equal terms: platforms and resellers that buy from providers and sell to developers with their own commission, applications that buy AI for their own products, and developers calling the network directly. No channel has a privilege over another, and every one meets the same fees and rules.
When a node receives a request for a model it does not serve, it forwards it to a provider that does. Your machines become such a provider by announcing the models they serve. Each announcement carries your rate card, so any node can price a request at your machines without asking you, and your signed heartbeat, every 2 seconds, tells routers whether each model is warm, how many requests are in flight and how deep the queue is.
Routers choose among providers by price, latency, reputation or a weighted score of all three. You do not need to win a sales process for each buyer. You need to be serving the model, at a price and latency the router selects, and to keep serving it reliably.
Reliability is what moves you up. When a slow primary is hedged, the router hedges at that provider's own tail latency, the pattern Dean and Barroso described, and only the answer that wins is billed and credited to reputation. A provider whose heartbeats stop for 6 seconds is skipped until its next clean heartbeat.
Your prices, your units
The network sets no price. You publish a rate card per model, and a default card, priced per unit of metered work: input and output tokens, characters, audio milliseconds, image steps, or any unit registered since, with tiers such as priority output where you choose to offer them, and a per-call minimum. A call none of whose billable work your card prices is refused rather than served free.
You also set who can reach you. A node can be public, gated or private. A model your node forwards to another provider is never free: a caller with no credential is asked for payment over x402, the open standard that puts the HTTP 402 status code to work, or refused. A price of zero gives away your own capacity, never another provider's.
If you want to sell reserve capacity, you can. An operator can stage models in host memory and offer them as standby for sessions at a fee per hour. A session holds your node as its successor only against a funded escrow the buyer opens to you, which you claim as it accrues.
Settlement instead of credit
The conventional way to manage counterparty risk is credit: you assess the customer, agree terms, invoice, and chase. That works for a handful of large customers. It does not work for thousands of agents you have never met.
Per-call settlement replaces most of that with mechanics. A paid call settles against a payment the payer signed, binding the request, your quote and the price. High-frequency callers pay through channels: funds locked in escrow up front, then cumulative vouchers you claim when you choose, checked by the same rule the ledger applies at the claim, so you can accept a voucher knowing it will be honoured.
Billing comes from your own receipt. A forwarded call is billed from the signed receipt your machine returns, checked against the key your machine registered, with every dimension capped by what was actually sent and received. That cap cuts both ways: you cannot over-report, and the numbers on both sides of the call agree, so there is nothing to reconcile and little to dispute.
Every agent that pays you answers to someone. An agent on Tenzro holds no key of its own. It acts under terms set by a named root, a person's passkey or a machine's hardware key, with per-payment and daily limits. If its root revokes it, its channels stop paying everywhere at once, and the same check that governs the ledger governs your node, so you are never left holding a voucher that will not pay.
Each payment to you is one record, and refunds and splits settle against it. You can set a standing split rule so that every settlement to you is divided, in the same execution, between the accounts you name. Your payment history is pageable, with proofs against a certified checkpoint.
Receipts as your evidence
A signed receipt protects the operator as much as the buyer. A locally served answer carries a receipt signed by your node's session key, certified by your machine's hardware identity key, covering the model hash, engine, machine identity, input commitment, output hash, billed units and sampling parameters. If a buyer later claims that the work was not done, or was done on a different model, the receipt is your evidence, checkable by a third party without trusting you. That is the property remote attestation work, such as the IETF RATS architecture, is built around: evidence signed by the thing that did the work.
Receipts also build your standing. Reputation rises through settled, receipt-verified work, not mere availability, so your track record is something you accumulate by serving well rather than something you assert.
Your policy, enforced on your machines
Operators often serve under constraints: certain models only, certain jurisdictions only. You can publish a signed operator policy stating what you serve and where. Your node refuses, on its own serving path, a model your policy does not cover. A buyer can pin a call to a set of jurisdictions and receive a signed jurisdiction receipt, or a refusal (HTTP 412) when the pin cannot be met. A proven violation of a published policy is recorded against the operator and slashes its compute bond once validators holding two thirds of stake agree, which is what makes a policy worth something to a buyer choosing you because of it.
What this means for operators
The questions that matter are your own: utilisation, demand, payment terms, counterparty, audit. Tenzro addresses them with mechanics rather than promises. Demand arrives through interfaces buyers already use. You set your prices. Each call settles against a receipt your machine signs, from counterparties who answer to a named root with hard limits, and your payments are records you can prove.
Where Tenzro fits
Tenzro is the settlement layer for AI work. Operators run the machines; agents and apps bring the work; Tenzro routes each call, settles it, and returns a receipt signed by the machine that did the work. It is not another compute provider. Operators are its supply side, and their keys stay in hardware: TPMs, Secure Enclaves and passkeys. Everything in this article is built, per the Tenzro repository documentation, and the software is open source under the Apache 2.0 licence.
