Settlement for AI work

Most AI spending still looks like ordinary software buying. A company signs with a model provider or a cloud, receives an invoice at the end of the month, and reconciles it against a usage dashboard the provider runs. That arrangement works when a person chooses the supplier, the volume is predictable, and there is one counterparty to call when something goes wrong.

Agents change each of those conditions. Software acting on someone's behalf now calls models, buys data and hires other software in the middle of a task, often many times a second, and often from whichever supplier is fastest or cheapest at that moment. The buyer is no longer a procurement team. The supplier is no longer one company. And the question after the fact is no longer only what the bill says, but which agent spent, under whose authority, on which machine, and for what work.

Tenzro is built to answer that question. It is an open settlement and coordination layer for AI work, underneath the operators, model providers, agent platforms and payment schemes that already serve it, rather than another one of them.

This article sets out why that demand needs a settlement layer between buyers and operators, what such a layer has to do, and where Tenzro sits in it.

Agents now pay for work

The building blocks for machine payments are arriving. HTTP has reserved a status code for payment since its early days; RFC 9110 still lists 402 Payment Required as "reserved for future use". x402 turns that code into a working pattern: a server answers a request with its payment requirements, the client pays, and the request goes through. AP2 adds mandates that record what a user asked an agent to buy and what they approved, producing what its authors call "a non-repudiable audit trail" of authorisation.

These are real advances, and they answer the question a merchant asks: was I paid, and did the buyer consent? AI work raises a second question that a payment alone cannot answer: was the work that was paid for actually done, by the machine that claims to have done it, at the size that was billed?

For a pair of shoes, delivery is a separate event that someone can observe. For a model call, the delivery is the response itself, produced on a machine the buyer never sees. The only evidence the buyer has is what the serving side reports.

Why invoices and cards do not fit

Invoices and card payments were built for people buying from companies. They assume a known merchant, a human in the loop, and amounts large enough to carry a fixed processing cost. A single model call can be worth a fraction of a cent. An agent can make thousands of them in a session, spread across several suppliers, with no person approving any one of them.

Three things break under that load.

The unit is wrong. A monthly invoice aggregates away the individual call, which is exactly the thing an agent's owner needs to examine when a task goes wrong or a budget is exceeded.

The authority is missing. A card number says who will pay; it does not say which agent is spending it, what that agent was allowed to buy, or how to stop it without cancelling the card for everything else.

The evidence is one-sided. The supplier's usage report is the supplier's word. When there is one large supplier and a long contract, that may be acceptable. When an agent spreads its calls across many independent operators, each with its own report, it is not.

What a settlement layer has to do

A settlement layer sits between the work and the money. For AI work, it has to do five things, and do them per call rather than per month.

Route. Take a request through one interface and send it to an operator that serves the model, chosen on price, latency and track record, and move it to another operator quickly if the first one fails.

Price. Apply the operator's own published price to the units the call actually used: tokens in and out, audio milliseconds, image steps. The layer should not set prices; operators should.

Settle. Move value from payer to operator for that call, in a way both sides can check, with refunds and revenue splits recorded against the same payment rather than in a separate system.

Record. Leave one record per payment that binds what was asked, what was quoted and what was paid, and a receipt of the work that was delivered, signed by the machine that delivered it.

Hold the payer to account. Make every paying agent answer to a responsible person or organisation, with limits it cannot exceed and a way to stop it everywhere at once. The OWASP Top 10 for Agentic Applications gives security teams a peer-reviewed list of the critical risks of autonomous AI systems; a payment path without limits is one of the most direct ways any of those risks becomes a financial loss.

Payment proofs and work proofs are separate today

The open efforts in this space have each taken one piece. Payment protocols prove payment and consent. Separately, standards work at the IETF defines receipts for inference: the Attested Inference Receipt draft binds model identity and input and output hashes into a signed artifact for independent verification, and describes itself as evidence, "not an appraisal verdict". It does not address billing.

Each piece is useful. Neither, on its own, tells a buyer that the money it paid matches the work it received. Joining them is the job of settlement: the receipt of the work and the record of the payment have to refer to the same call, and the amount has to follow from the receipt rather than from a separate report.

What this means for buyers, operators and agent owners

For buyers, a settlement layer turns AI spending from a monthly reconciliation exercise into a sequence of individual, checkable transactions. Each call has a price, a payer, a payee, and evidence. An agent's spending can be exported and audited by someone who does not trust the operator, the agent's developer or the layer itself.

For operators, it brings demand they did not have to sell. Agents and applications reach their machines through an interface those applications already use, and every paying agent arrives with a named responsible party and hard limits. Counterparty risk on a call becomes a property of the payment, not of a credit relationship negotiated in advance.

For the people responsible for agents, it gives control in the terms they already use: a budget, a list of permitted suppliers, an expiry date, and a way to switch an agent off.

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 across independent operators, settles it per call, and returns a receipt signed by the machine that did the work. It is not another GPU or compute provider. The operators who already run AI infrastructure are its supply side.

What is built, per the Tenzro repository documentation:

• Every node serves OpenAI-compatible routes for chat completions, responses, embeddings and audio transcription, and gates them with HTTP 402 wherever its operator charges for them.
• Calls are routed across providers by price, latency, reputation or a weighted score. A slow primary is hedged with one duplicate request, and only the winning answer is billed. Providers send a signed heartbeat every 2 seconds and are treated as down after 6 seconds of silence; failover skips them.
• Operators publish their own rate cards per model and per unit of metered work. The network sets no price.
• A locally served answer carries a receipt signed by the serving node's session key, certified by its hardware identity key, covering the model hash, engine, machine identity, input commitment, output hash, billed units and sampling parameters.
• A forwarded call is billed from the provider's signed receipt, with every dimension capped by what was actually sent and received, so a provider cannot over-report usage.
• Every payment leaves one record binding the request digest, the quote digest and the USD price. Refunds and payee splits settle against that same record.
• An agent holds no key of its own. It acts under terms set by its root, a person's passkey or a machine's TPM or Secure Enclave key, with per-payment and per-period limits. Revoking it stops its payment channels everywhere at once.
• An agent's payments can be exported as an evidence pack and verified offline against a certified state root.
• A node charges and accepts payment over x402 and MPP, the open agent payment protocols, and checks every payment against the paying agent's terms.
• Tenzro is open source under the Apache 2.0 licence.

The other articles in this series take each part in turn: what a receipt proves, how one job settles across many operators, the payment rails machines need, spending limits and revocation, and what all of this means for operators.