The Internet’s Next Customer Is Software

When software becomes the customer

When I picture buying something on the internet, there is usually a person moving through a familiar sequence. They find a product, read the pricing page, create an account, choose a plan, and enter a card. I understand that flow when someone expects to keep using the product.

Now suppose the buyer is a research agent. It might need four thousand search results, a weather lookup, or a browser for six minutes. For another task, it might need two minutes of GPU time or a single SMS. Its relationship with a provider could begin and end with that task. Once the work is done, it may never come back.

That makes me question what it is being asked to buy. If the service is useful for one small part of a task, I would want the purchase to fit that use. Paying for what it consumes seems a more natural possibility than assigning it a seat on a subscription.

This is where Bitcoin starts to make more sense to me. If agents begin choosing services and doing business with each other, payments could become part of carrying out the work. I can picture a role for Bitcoin in those exchanges. I’m interested in how money could move within the authority a person has already given, without someone having to complete each purchase.

I read Stripe’s agreement to acquire OpenRouter with that possibility in mind. OpenRouter provides access and routing across AI model providers, while Stripe handles payments. In the announcement, Patrick Collison described Stripe as building “economic infrastructure for AI.” Bringing those pieces together looks to me like a way to prepare for software making more decisions about which services get used and paid for.

If more purchases start to happen this way, a growing part of the internet might sell directly to software alongside the applications designed for people. I’m trying to work out what would make a brief, automated purchase feel as ordinary as signing up for an application does now.

Choosing and buying as the work happens

Before that purchase can happen, the agent has to find a service. Suppose I give it a task and, just to choose a number, ask it to spend less than four cents per request. It would also need a service that meets the task’s requirements for reliability and latency, from a provider it is allowed to use.

That is where the API begins to look like a storefront to me. The agent would need a way to discover what a provider offers, understand its terms, and judge whether it fits the task. I would expect reputation and existing relationships to matter, but they might be inputs to a decision the software can make again when the work changes.

SEO gives me one way to think about the change. A business tries to be found by a search engine so that a person can arrive and decide what to buy. In the situation I’m imagining, the system finding the service could also choose and pay for it. I wonder what being discoverable and worth choosing would mean for that kind of customer.

Then there is the company’s side of the purchase. Buying a new service can mean involving a manager, a procurement team, a vendor, a contract, and credentials before anyone can use it. I’m trying to picture what happens if an agent discovers the need halfway through its task. With a service that supports automated purchases and access, perhaps it could check the rules, pay, and continue working.

That would make the rules set beforehand much more important. I could give an agent room to choose without approving each purchase individually, provided I had already decided how much it may spend, what it may buy, and from whom. Anything outside those limits would wait for a person.

If I carry the thought further and imagine thousands of these choices a second across an organization, I find it hard to picture a person reviewing every one. Part of procurement starts to look like something the software does while it works, with people setting the rules and dealing with the exceptions.

Giving agents authority to spend

The purchase raises another question for me: whose money is the agent using, and what gave it permission to spend it? Someone would still have to choose the budget and the purpose of the work. I would want each action tied back to that task and to the person or team that authorized it.

To work through the accounting side, say a company’s agents spend $12,000 in a day. I’m inventing the bill, but knowing only the total would still leave me wondering which tasks produced something useful and which got stuck in retries. A monthly bill from model providers would be one view of the spending; I would also want to follow each run and step to understand what the money bought.

Suppose I compare two agents that complete a task to the same standard, one spending twenty-one cents and the other seventeen dollars. I picked those amounts to make the difference visible. The output alone might make the agents look equally capable. If I then imagine the task running a hundred million times, the cost of getting to that output becomes much harder to ignore.

For another example, I’m imagining a monthly inference bill falling from $1.2 million to $100,000 through better routing. Even then, I would be interested in why the cheaper path was sufficient. A permitted model that meets the task’s requirements could be a good choice. Another task might justify more time, another attempt, or a more capable model.

That leaves me trying to work out how an agent should make those tradeoffs. It may know how to solve a problem and still spend far more than the result was worth. Deciding whether another step is worth taking starts to feel like part of intelligence to me. I would want to judge both the quality of the work and whether the time and money spent made sense for its purpose.

Managing people and agents together

Following the spending back to an owner does not quite settle who is responsible for the agent. I would also want someone to understand how its work is going and to be able to intervene. If I imagine a company with thousands of agents that can act and spend, that responsibility seems likely to become an organizational question as much as a technical one.

To picture the organization, I might put forty engineers alongside a few hundred coding agents, plus agents doing testing, security reviews, and research. Those are imagined headcounts, but they make me wonder where the engineers would spend their attention. Perhaps more of it would go toward coordinating the work and reviewing what comes back. The things being managed would include the people, the agents, and the workflows and budgets connecting them.

The practical questions seem familiar: what the agent is trying to achieve, what it can access, and when it should ask for help. I would want a record of its decisions and a way to review the result or stop the work. Noticing when to intervene seems harder. A stop button would be of limited use if nobody realized the agent needed to be stopped.

Companies already have to govern work done by employees, contractors, and outside teams, so I would expect some of that experience to carry over. What I find less clear is how far it stretches. An organization could create agents much faster than it could hire the same number of people, and those agents might make many decisions before someone reviews the work. I’m curious about which habits of managing people would still help at that scale.

The responsibility seems to cross engineering, security, finance, and operations. Each team would see a different part of the problem, which makes it hard for me to see an obvious owner. It could sit with one of them or become a function of its own.

Following that thought outside the company, I can picture a supplier having two ways to explain what it offers. A person might need a product page and enough context to decide whether to trust it. Software might be better served by a direct description of the capability, its terms, and how to use it. The packaging and prices could differ. I wonder whether learning to serve both could matter as much as the move from physical storefronts to websites.

The internet may need an execution control layer

All of this brings me back to the gap between what an agent wants to do and what it is allowed to do. The agent might know which service it needs, but that still leaves the decision about whether this particular action fits the authority it was given.

Looking at the pieces already available helps me separate the problem. Identity can establish who is acting and on whose behalf; payments provide a way to move money. Observability helps explain what happened, and orchestration arranges the work. These can all contribute to control. I’m interested in how they come together when the agent is about to act.

One possibility I keep returning to is an execution control layer. I picture it checking the request against the rules about what the agent may use and spend, and letting the work proceed or wait for a person. For a purchase, I would want the authorization to stay attached to the receipt, so I could trace what happened back to the permission that allowed it.

My current thesis is that some form of execution control could become a fundamental part of software that acts on its own. The question I’m still working through is how to give an agent room to work while making those limits hold at the moment it acts.