Agents Will Buy Their Own Compute | Agentic & Distributed Systems, DeFi, and Compute Economics

Software can provision infrastructure, but a person still opens and funds the account. Agents, distributed compute and machine payments could make the workload the buyer.

Software can provision infrastructure. It still cannot become the buyer.

I already route work between models. I want the software to be able to choose a supplier for the job in front of it, including deciding the job isn't worth the price.

A person opens the account, accepts the terms, funds it and hands the software credentials. I think agents will change who picks the supplier and makes each purchase. They won't remove the person responsible for the money or the work.

The workload chooses the machine

Some jobs need the best reasoning I can buy. Some need a cheap model that can read a document and return clean JSON. Some should stay on a machine I control because the data has no business leaving the building.

Right now I make most of those decisions before the work starts. I pick the provider. I set the model. I decide whether the job runs locally or in the cloud.

Suppose the job is to read a batch of public documents and return a table of dates and amounts, with a source passage for each entry. It can wait until morning. A local model might handle it overnight; a cheap hosted model might finish sooner. The strongest model may not earn its premium on this job.

Before an agent could choose, I would have to set the budget, deadline and allowed suppliers, and explicitly allow those documents to leave the machine. I would not trust a model's guess about sensitivity to set that boundary. This is a purchase flow I want, not one I am claiming to run today.

Change the deadline or make the documents private and the same extraction job may belong on a different machine, or have to stop. A legal review may justify a stronger model, with a qualified person still responsible for the review. Selection has to account for what the work demands.

We keep asking which model wins.

The agent will ask which model wins this job at this price.

Cloud accounts were built for companies

The cloud assumes a human organization sits on both sides of the transaction.

A company signs up. Finance approves the card. Engineering provisions the machine. Security issues credentials. Procurement negotiates the contract if the bill gets large enough.

That works when the commercial relationship changes slowly, even if the machines scale quickly.

Agents can make thousands of small decisions. They spin up work, abandon bad paths, retry failures and split one goal into twenty smaller jobs. The useful unit is not a server for a year. It is enough compute to finish one piece of work.

Cloud metering got granular. The relationship did not. I can buy a few seconds of compute or a thousand tokens, but only after somebody creates an account, accepts the terms, funds it and hands the software credentials.

When I started running OpenClaw seriously, my Anthropic bill went from $25 a day to $800 a day. I wrote about that as the Cloud Landlord problem. The purchasing problem is that each retry becomes another sale to the same supplier, whether or not it was worth buying.

I want an agent that can reject a price, move a batch job or use local hardware when the cloud premium makes no sense. It should be able to pay more when the deadline matters, within a limit I set.

Knowing when another attempt is worth the money is harder. A budget can stop a loop. It cannot tell me whether the work was useful.

Software needs money

An agent cannot shop if every purchase ends at a checkout page.

Credit cards were built for people and businesses. They assume an account holder, a billing address, fraud rules, chargebacks and a bank willing to recognize the buyer. API keys made software access easier, but they still require a human to create the account and preload the relationship.

Machine payments can remove the need to open a separate account with every seller. Someone still has to fund the wallet or payment account and authorize what the agent can spend.

For the document job, suppose an approved provider quotes a price within that budget. The agent needs a way to accept the quote, pay and get the result without sending me through another signup form.

HTTP has reserved status code 402 for "Payment Required" for decades. x402 and MPP use it to tell a caller how to pay for a resource. The client retries with payment proof or authorization, which the server verifies under the chosen payment method.

As of this September 17 revision, MPP’s documentation separates one-time charges from sessions for metered or streaming payments. Its documented methods include Tempo, Stripe and Lightning; it isn't limited to crypto. With a payment session, work can be metered while settlement happens separately, rather than an onchain transfer for every request. x402 carries payment requirements and authorization in HTTP headers, allowing an endpoint to charge a caller without first issuing it a seller-specific API key.

These are early protocols. I do not know which one wins. They may merge, specialize or get replaced.

With a compatible endpoint and an authorized payment method, the agent could pay for the extraction and record the receipt. It would still be spending my money under my rules. The protocol doesn't grant permission to upload the documents or prove the returned table is right.

Another provider could undercut that quote. Hardware that is already paid for can enter at a low marginal cost, although electricity, wear and unavailable capacity still count. A specialized chip can win on speed. A decentralized network can fill demand when the big clouds are expensive or unavailable.

DeFi has spent years building programmable settlement before most people had a reason to care. Agents may be the reason.

The router becomes the product

Once the agent can buy from more suppliers, it has more ways to buy the wrong thing.

I wrote that the model moat is dead because I do not want my business to need one model to stay ahead forever. That does not mean every model is equal. It means selection becomes its own engineering problem.

For the document job, a clean table isn't enough. The dates and amounts need to match the source passages. Missing entries matter too. I would want checks against the documents, not just another model saying the answer looks good. Work that cannot be checked reliably needs a person to review it or a narrower task.

If an extraction fails those checks, the router has another decision to make. Retry with the same model, try a stronger allowed supplier, or stop? The cost of the failed attempt and the next one both belong in the budget. A fast model is not fast if an agent burns five calls repairing the first answer.

The router needs the current price and latency, whether the provider logs prompts, where the work runs and what happens when the endpoint disappears halfway through a job. It also needs a memory of performance by task, not model hype.

One model may be better at code review; another may be good enough for extraction at a lower cost. My local model may be slower but avoid a per-call API bill. Electricity, maintenance and the other work that machine could be doing still count. A remote provider's low price may not compensate for its latency.

I want the router to keep that history and use it on the next job. Paying less for the first attempt means little if finishing the work costs more.

This is a distributed systems problem before it is an AI problem. Scheduling, retries, verification, reputation, failure recovery and settlement matter as much as intelligence.

The market will be messy

Checking the returned table still leaves questions about the machine that produced it.

Did the provider run the model it claimed? Did it keep a copy of the prompt? Did it return a cached answer from somebody else's job? Did it stop early and charge for the full run? Can it prove that private data was deleted? What happens when the result is wrong but technically complete?

More suppliers could widen access. Unknown suppliers also give me more to verify.

An onchain record can show a transfer. A signed receipt records what its issuer attests to. Neither tells me the inference was good, and neither proves that the provider deleted my prompt.

I would want reputation tied to specific workloads, challenge jobs and reproducible outputs where possible. Trusted execution may help verify parts of a private workload, but it is not a blanket guarantee of privacy or a correct answer. Refunds and disputes need their own rules too.

Agents also need hard boundaries.

A wallet with no policy is just a new way to lose money faster. The agent needs a per-job budget, a daily ceiling, approved categories and a point where a person has to say yes. Retries need idempotency so one network error does not buy the same job five times.

The system also has to explain what it is about to do.

"Spend $0.14" is not enough. Spend $0.14 on what model, with what data, under what retention policy, for what expected improvement over the cheaper route?

Faster buying needs tighter permissions, not looser ones.

Local compute joins the market

I used to think about local AI as the opposite of cloud AI.

Rent versus own. Landlord versus sovereignty. API versus a box under the desk.

I still believe ownership matters. I also think the boundary gets more interesting once an agent can route work.

Your local machine does not have to replace the cloud. It can participate beside it.

The Mac sitting idle overnight can handle private document work. A gaming PC can clear a batch queue while nobody is using it. A small business can keep routine jobs on hardware it already owns and burst into rented capacity when demand spikes.

I do not have to choose local or cloud once and live with it.

I made the case for sovereign AI because a useful local model gives you a fallback that doesn't depend on a hosted endpoint staying available at the same price. It still has hardware limits, operating costs and license terms. Dynamic routing gives that fallback a role in each purchasing decision.

Local compute becomes the first bid.

If it meets the quality bar within the deadline, use it. If not, consider outside capacity only when the data policy allows it. If the data cannot leave and local hardware cannot do the job, stop or change the plan.

The agent makes the trade instead of following one infrastructure decision forever.

Who gets to build

The current AI stack rewards companies that can commit early.

They reserve GPUs. They negotiate API contracts. They hire infrastructure teams. They can afford to learn which models fail by spending money on the failures.

Everyone else pays retail.

A market like this could change who gets access.

A small team would have less reason to own a cluster if it could reliably buy the capacity each job needed. Portable workloads could make it less dependent on one provider. That still leaves prices, legal restrictions and suppliers willing to sell. A protocol cannot promise access by itself.

This is the part I care about.

I keep a scoreboard on whether AI abundance reaches people or gets fenced. Cheap models help. Local hardware helps. Open weights help. None of them finishes the job alone.

Access becomes real when a builder can move across the stack without asking one landlord for permission.

Machine payments give the agent a way to buy. Distributed compute gives it somewhere else to go. Local hardware gives it the ability to say no.

The combination matters more than any one network or protocol.

The next cloud

The cloud is not going away.

Amazon, Microsoft and Google are very good at running machines. Frontier labs will keep charging a premium for the best models. Most businesses will keep renting more than they own because renting is easier.

But the relationship can still change.

Today we choose a cloud, deploy the software and live inside the bill.

I expect more competition over individual jobs: an overnight batch that can wait, an urgent request that earns a premium, routine work that stays local because no outside offer beats it. Providers would have to win those purchases instead of relying only on the account somebody opened months ago.

That depends on workloads being portable and suppliers accepting this kind of payment. I don't have a finished market to point to. I want builders to own the parts that let them use one: the task definition, routing logic, evaluation history and permissions. Then a change of supplier need not mean starting the workflow over.

I do not think the next cloud is another place where we deploy software.

It is a market our software shops in.