Your Cloud's Best Customer Is Now an AI Agent. Who Decides What It Buys?

Wed Oct 07 2026

Last week I asked a coding agent to add a database to a small project. Before it wrote a line of code, before it even asked me which provider I wanted, it ran a CLI command that returned the entire marketplace of my hosting platform as JSON, picked Neon Postgres from the Vercel Marketplace, provisioned it, wired the connection string into the project, and pulled down the provider's own "skills" file so it would know how to use the thing it had just bought.

The plugin that drives this behaviour literally instructs the agent to do that first, before recommending anything or asking me a question. I never saw a catalog page. I never compared plans. I didn't click on anything.

Look at the layering for a second. Neon isn't a Vercel product: it's a Databricks-owned company whose Postgres runs on AWS regions. So the agent bought AWS capacity, through Neon, through Vercel's catalog, and the only brand it ever interacted with was the one at the top. The hyperscaler is still in the stack. It's just two layers down and invisible.

It took me a day to notice the more interesting part: the agent didn't choose that database either. It was handed a default and it took it.

That small moment is, I think, the clearest picture of where SaaS is going. For twenty years cloud products have been designed for a human sitting in front of a console. The customer is changing. A part of the industry has rebuilt its product around the new customer, a bigger part is bolting an adapter onto the old one, and almost nobody is asking who the new product actually serves.

Two generations of cloud interface

The first generation is the one we all know: the AWS, Azure and Google Cloud consoles. Hundreds of services, each with its own blade, its own pricing page written for procurement, its own wizard. Discoverability is a human problem solved with search boxes, documentation and certifications. I've spent a decade in those consoles and I still open the docs to remember where a setting lives.

The second generation looks very different, and the best way to see it is to look at what Vercel and Railway shipped this year.

In March, Vercel added three commands to its CLI aimed explicitly at agents: discover, add and guide. discover lists the whole marketplace in JSON; add installs an integration and provisions the resource at the provider; guide returns setup instructions in markdown. The procurement guide that goes with them shows an agent passing a region and a plan as flags, then checking the balance and setting spending thresholds afterwards. Since August, installing an integration also installs the provider's agent skills, so the agent arrives already knowing how to use the service.

Railway went further. Its MCP server (August 2025) exposes deploys, environments, variables and logs to any coding agent. In April this year it became a remote server with OAuth, plus a railway agent command for scripts and CI, plus a one-line skills install. Their framing is blunt: "If your agent can write the code, it should be able to ship it too."

Read the docs of these platforms and you notice something else. Vercel's documentation pages now carry a block that starts with "For AI agents:" and links to a machine-readable cross-link map of the whole site. The llms.txt proposal from 2024, a markdown file at the root of a website written for models rather than people, has quietly become normal. The documentation has a second audience now, and in some places it's the primary one.

On these platforms, a service can be more visible to an agent than to a human. A provider that publishes a skills file and a JSON catalog entry is one discover call away from being installed. A provider that only has a pretty landing page isn't in the race.

The customer already changed

If this sounded like a prediction, the numbers say it's a description.

When Databricks bought Neon in May 2025, the announcement included a detail I keep coming back to: the share of Neon databases created by AI agents rather than humans had gone from 30% to over 80%. Four databases by agents for every one by a person. Neon's explanation is not magic, it's product shape: instant provisioning, pay for what you use, cheap branching for an actor that experiments a lot and doesn't mind throwing things away.

Railway's June update says tens of thousands of users every week manage the platform exclusively through agent actions, and that active MCP usage grew more than five times in a month. Those users have accounts, and they pay, and they never open the dashboard.

And the plumbing has standardized faster than I expected. Anthropic handed the Model Context Protocol to the Linux Foundation in December, with OpenAI, Block, Google, Microsoft, AWS and Cloudflare behind the new foundation, citing more than 10,000 public MCP servers and 97 million monthly SDK downloads. Whatever you think of MCP as a protocol, it's the USB port of this generation: a vendor builds one server and every agent can plug in.

The hyperscalers are not asleep. They're solving a different problem.

I want to be fair to the big three, because the easy version of this story ("the giants are dinosaurs") is wrong.

AWS made its MCP server generally available in May: one server, access to more than 15,000 API operations with your existing IAM credentials, every call in CloudTrail, and Service Control Policies that can pin the agent to read-only while humans keep full rights. Google announced more than 50 managed MCP servers in April and says every Google Cloud service is MCP-enabled by default, with IAM deny policies, prompt-injection defences and audit logs on the path. Microsoft has had an Azure MCP server in preview since April 2025 and made the Azure DevOps remote server GA in August.

So everybody has an MCP endpoint now. That's not the difference. The difference is what's behind it.

Giving an agent authenticated access to 15,000 operations is a translation layer over a product that was designed for humans. It is enormously useful for operating the cloud you already have, and the governance story (SCPs, CloudTrail, IAM deny) is better than anything the smaller platforms offer today. But it doesn't help an agent choose. Choosing needs a small, flat catalog, prices expressed per unit of use, and a provisioning call that returns a working resource in seconds. That's a product decision, not an integration.

Railway's team said something revealing in their MCP announcement: "If there are no delete-x MCP tools, the odds of the coding agent running a destructive action goes down significantly." Their remote server started with seven tools. That's the opposite instinct from "expose everything". It's the instinct of someone designing the surface for the new customer instead of wrapping the old one.

Today the agent doesn't shop. It's steered.

Here is the honest description of what happened in my database story. The agent did not evaluate Postgres providers against my requirements and budget. A plugin told it to run discover. The catalog came back in an order I didn't set. The first viable entry had a skills file. The agent installed it. From my side it looked like a decision; from the agent's side it was a default.

That's the state of the art in October 2026, and it's worth being precise about it, because most writing on this topic skips straight to "agents will pick the best tool for you". They don't, yet. They pick what their context points at. Three layers of context do the pointing:

  • The plugin or system prompt, which tells the agent which catalog to consult and when.
  • The catalog itself, which decides what's listed and in what order.
  • The provider's skills file, which tells the agent how to use the service and, inevitably, why it's the right choice.

None of those layers belongs to the buyer. All three belong to the platform or the vendor. Keep that in mind for a moment.

Tomorrow the agent shops, and it starts with commodities

I do think real shopping is coming, because in one corner it has already arrived.

Look at how AI gateways route model calls. Vercel's AI Gateway lets you sort providers by cost, latency or throughput and tries them in that order. OpenRouter's default routing first drops providers that had outages in the last 30 seconds, then picks among the cheapest, weighted by the inverse square of the price. That is an agent shopping, on every request, with no human in the loop. It happened for inference first because models are interchangeable, priced per token, and switching costs nothing.

The payment rails are being rebuilt to generalize exactly this. Stripe and OpenAI published the Agentic Commerce Protocol a year ago, with a payment token scoped to a merchant and a cart total so an agent can pay without ever holding the card. In July, Cloudflare announced its Monetization Gateway: any page, API, dataset or MCP tool behind Cloudflare can answer a request with 402 Payment Required, the agent pays in stablecoins, retries with proof of payment and gets the resource. Amounts can be fractions of a cent. It entered closed beta at the end of September.

Think about what that does to a pricing page. Today an agent reads a plan table written for humans and asks me to pick one. With a 402 response, the price is the API. The "plan" dissolves into a per-call quote the agent can evaluate against my budget on every request, the same way the gateway evaluates a model provider today.

So my prediction is bottom-up. Shopping arrives first for inference, then for compute, storage and queues, then for any API that adopts per-call pricing: things that are interchangeable and priced per unit. For those, the agent will genuinely pick on price and fit, and switching will be routine. Above that line, for the email provider, the auth provider, the observability vendor, the agent evaluates inside a catalog that someone else curated. Enterprises will add their own fence on top: a pre-approved list and a budget, and the agent optimizes within it. Still shopping, just fenced.

Which brings me to the part I actually worry about.

Who does the catalog work for?

Imagine, hypothetically, that a hosting platform signs a revenue-share agreement with an email provider. Nothing dramatic has to happen. The provider appears first in the discover output. Its skills file is installed by default. The platform's plugin mentions it as the recommended option. No ad is shown, no label says "sponsored", and every agent on that platform that needs to send email now picks that provider, including the ones for which a cheaper or better-fitting competitor existed two entries down.

I want to be clear that I have no evidence of any such agreement anywhere. I'm describing the structure, not an event. And the structure is the problem, because it is worse with agents than it ever was with humans:

A human can tell an ad from a result. An agent reads a skills file as documentation and a plugin default as an instruction. The sales pitch and the manual are the same text, delivered with the same authority.

Ranking is invisible. When a human scrolls a marketplace, the order is at least on screen. When an agent gets a JSON list, it tends to take the first viable option, and nobody sees the order at all.

There is no disclosure convention. Web search carries "Sponsored" labels because regulators forced them. A machine-readable catalog has no equivalent field, and even if it did, nothing requires the agent to weigh it.

The platform can steer at three layers at once. What's in the catalog, how it's ordered, and what the installed skill tells the agent to prefer. Each one alone looks like a product decision. Together they're a sales channel.

This isn't a new pattern. In 2017 the European Commission fined Google €2.42 billion for placing its own comparison shopping service above competitors in search results. Self-preferencing by a company that owns discovery, ranking and payment is now explicitly banned for designated gatekeepers under the Digital Markets Act. The Commission's own review of the Act lists "more favourable treatment of gatekeepers' own AI services" as one of the open issues and says it will assess whether the rules need modifying for AI. In other words, the regulator has seen the pattern and hasn't written the rule yet. No agent marketplace is a designated gatekeeper today. Every time one company owned the list, the order and the checkout, the order became the product. We are rebuilding that structure, and this time the human who used to notice has been removed from the loop.

The counterweights exist, but they're weak right now:

  • Buyer-side constraints. Your own approved catalog and your own budget in front of the agent, which turns the platform's list into a candidate pool rather than the decision.
  • Traceability. An agent run leaves a record of what it saw and why it chose. Humans never had that for their own purchasing. It's the one place agents could be more auditable than we were, if anyone looks.
  • Open registries and a disclosure field in catalogs. Both are possible. Neither exists in a form that matters yet.
  • Regulation. It lags by years, and it is currently written for search engines and app stores, not for JSON catalogs read by models.

What I'd tell my own team

My backend team runs on AWS, on a .NET stack, in a regulated-ish domain. Nothing above makes me want to move them to Railway tomorrow. But four things change how I think about platform decisions from now on.

Whoever owns the agent's context owns procurement. When the agent chose Neon for my project, it didn't do a vendor evaluation. It ran discover, and the provider with the best skills file won. Lock-in used to be a decision you could see; now it's a default that happens in a tool call. If you don't want that, put your own catalog and your own constraints in front of the agent, the same way we put coding guidelines in front of it.

FinOps becomes a prerequisite, not a follow-up. An actor that can provision in seconds and pays per call can also spend in seconds. The human gate on paid plans, spending thresholds, and server-side read-only scopes are the controls I'd require before letting any agent near a real account.

Machine-readable is the new "documented". Our internal services have Swagger and a wiki. Neither is enough. If a service in our own platform can't be discovered, understood and provisioned from a JSON catalog and a markdown guide, then to an agent it doesn't exist. I expect the same standard to apply to internal platforms within a couple of years that applies to Vercel's marketplace today.

Log the choice, not just the action. We already keep traces of every agent run in our automated process. The trace should record which options the agent saw and why it picked one. That's the only defence against invisible steering that doesn't depend on a vendor's goodwill or a regulator's timeline.

The prediction I'm comfortable making: the console doesn't disappear, but it stops being the product. It becomes the place humans go to approve, audit and set limits. The product is the catalog, the provisioning call, and the price an agent can read. The platforms built that way are already collecting the customers. The open question, and the one I think engineering leaders should be asking their vendors now, is whether that catalog works for the buyer or for the platform that owns it.

References