For most of the web's history, software recommended and humans transacted. A page suggested a product; a person clicked Buy, typed a card number, scanned a code. Every checkout flow ever built quietly assumed a human was sitting in front of it.
That assumption broke in the space of about a year. Anthropic shipped the Model Context Protocol to give models structured access to tools and APIs. OpenAI shipped an Agentic Commerce Protocol and in-chat Instant Checkout. Google published the Agent Payments Protocol. Coinbase revived the long-dormant HTTP 402 Payment Required status code as x402, a way to charge for an API call in stablecoins. Visa announced Intelligent Commerce; Mastercard announced Agent Pay. The card networks, the model labs, and the crypto rails all arrived at the same conclusion within a few quarters: the buyer is about to be a program.
The plumbing is being laid fast. What gets discussed far less is which categories are actually ready for an agent to buy. That is the more interesting question, and the answer is not the one the demos reach for. It is not concert tickets or sneakers or groceries. It is connectivity — mobile data — and the reasons are worth spelling out, because they double as a checklist for what agent-ready commerce looks like in any category.
What "agentic commerce" actually means
It is worth being precise, because the term is already getting stretched. A chatbot that links you to a checkout page is not agentic commerce; it is a search box with better manners. Agentic commerce is the case where the agent itself holds three things at once — an intent (the user wants data in Japan next week), a budget (spend up to so much), and the authority to act — and completes the transaction end to end without handing control back to a human at the critical step.
Strip the branding off the protocols listed above and they all describe the same five-step shape:
- Discover — find the product and its price in a machine-readable form.
- Authenticate — establish who the agent is acting as, or whether it needs to.
- Authorize payment — move money within a limit the user agreed to.
- Fulfil — actually deliver the goods.
- Confirm — return something the user can verify or use.
Each protocol is strong on one or two of these steps and silent on the rest. MCP is about discovery and tool-calling. x402 and AP2 are about authorizing payment. None of them tell you which products survive contact with the other three steps. Fulfilment is where most categories quietly fall apart — and connectivity is the rare category where fulfilment is trivial.
Why connectivity is the ideal first category
Five properties make mobile data close to a perfect agent purchase. Most physical and high-value categories fail at least one of them.
1. There are no atoms. An eSIM is a pure entitlement — a profile delivered over the air plus an identifier. There is no shipping address, no warehouse, no customs form, no returns window, no "left it at the door." The hardest parts of commerce — logistics, fulfilment, the physical-world identity needed to deliver an object to a person — simply do not exist. An agent that cannot be trusted with your home address can still safely buy you data.
2. It is instant and low-stakes. Provisioning happens in seconds, amounts are small, and balances are capped. If an agent gets a data purchase slightly wrong, the blast radius is a few dollars that can be topped up or refunded — the opposite of an agent booking a non-refundable international flight. Low stakes are what make autonomy reasonable in the first place. The right first purchases for agents are the cheap, reversible ones.
3. It is metered, not bundled — which is how a model already reasons. The legacy eSIM market sells bundles: 5 GB for 15 days, 10 GB for 30 days. To buy one, an agent has to guess the user's consumption and gamble against an expiry date. Get it wrong low and the user runs dry mid-trip; get it wrong high and the unused gigabytes evaporate. A per-megabyte model turns that gamble into arithmetic: projected MB per day, times days, times the country rate. Arithmetic is what models are good at. Guessing under an expiry deadline is what they are bad at.
4. It is the latent need under almost every other task. Connectivity is rarely the headline of what an agent is doing; it is the thing the headline depends on. A travel agent that books a trip has implicitly committed its user to needing data in a place they do not have it. A fleet agent managing sensors in the field needs each device online. A personal assistant that keeps working as its human crosses a border needs the network to follow. Data sits underneath other commerce as infrastructure — which means demand for it is created automatically every time an agent does anything in the physical world.
5. It is globally uniform and well-specified. A connectivity purchase reduces to three values: a country, a rate, and a balance. That shape is identical in every market. An agent that can reason about France can reason about Japan or Thailand with no new model of the world — only a different number. Uniform, numeric, comparable products are exactly the kind a model can evaluate and cite without hallucinating.
What a connectivity purchase asks of an agent
So the category is right. The problem is that the existing way connectivity is sold was built for the human at the checkout, and it breaks at almost every one of the five steps when the buyer is a program:
- Discover — the catalogue lives in a JavaScript-rendered storefront an agent cannot read, behind thousands of overlapping bundle SKUs.
- Authenticate — buying requires an account, and creating one requires an email confirmation or an OAuth dance the agent has no browser to complete.
- Authorize payment — checkout wants a card form, and there is no concept of a spending limit the agent is bound by.
- Fulfil — activation is a QR code meant to be scanned by a phone camera, on a device the agent usually cannot reach.
- Confirm — the identifiers returned are internal plumbing (ICCID, order IDs) rather than anything the user needs.
None of these are hard problems. They are just problems nobody had to solve while the buyer was always human. Solving them is what "agent-native" actually means — not a chat widget bolted onto a consumer store, but the auth, payment, and delivery layers rebuilt around a different buyer.
What an agent-native provider looks like
This is the part where we stop talking in the abstract. Roamzy is built as a worked example of the five steps done for agents; here is each one, including where it is still rough.
Discover. The catalogue is exposed three ways an agent can read without a browser: a public REST API with an OpenAPI spec, an llms-full.txt written for models rather than people, and a Model Context Protocol server with twelve tools. The MCP server runs two ways — as an npm package over stdio, and as a remote endpoint an agent connects to by URL with zero install. Discovery is the step everyone gets right first because it is the most visible; it is also the least important, because it is useless if the next four steps still assume a human.
Authenticate. This is the single biggest friction remover, and it is a deletion rather than an addition: there is no required signup. An agent calls one endpoint, gets an anonymous session, and can browse, price, and buy immediately — no email, no OAuth, no account. If the user later wants the purchase tied to a real identity, the session can be claimed with a one-time code and Google or Telegram sign-in. The default is anonymous; identity is opt-in, after the fact. An agent should not have to negotiate a login before it can find out what something costs.
Authorize payment. Payment is in USDT, which lets a user (or an agent acting for them) hold a balance and spend against it without a card form in the loop. Be honest about the trade-off: a user with no crypto wallet is worse off here than at a card checkout, and the native on-chain agent-payment rails — x402-style "pay the API call directly" — are not wired up yet; that needs a treasury and is deliberately parked. What exists today is a payment URL the user opens in any wallet, after which a webhook confirms and credits the balance. More on the mechanics in the USDT settlement write-up.
Fulfil. One product, not a catalogue: a single global eSIM, priced per megabyte per country, with a balance that does not expire. That is what makes the budget math from reason #3 actually hold — no bundle to choose, no expiry to race. Provisioning runs against a real eSIM platform, so what comes back is a working profile, not a placeholder.
Confirm. The agent gets a phone number (MSISDN) as the user-facing identifier, a QR image plus a raw payload plus a one-tap install link so activation works whether or not the agent and the phone are the same device, and a balance the user can watch deplete. Internal identifiers stay internal.
The guardrails are the product. The part that is easy to skip — and the part that actually separates "an agent can buy this" from "an agent can be trusted to buy this" — is the limits. Every agent token carries a daily and monthly spend cap, a cool-off ceiling on brand-new tokens, a confirmation gate on any unusually large transaction, and a kill switch the operator can throw. Anonymous sessions are held tighter than named ones on purpose:
Data is priced per megabyte at each country's local rate — on the order of a dollar or two per gigabyte in most markets, more in premium ones — with the full 193-country table public and machine-readable. The agent does not work from a number baked into this post; it fetches the live rate for whatever country it needs straight from the catalogue, then does the arithmetic and stays inside a cap without guessing. One source, always current.
The honest part: this is early
None of this is a victory lap. Agentic commerce is new enough that the most common thing an agent does when it connects to us is connect anonymously — the OAuth identity layer is built and published, but the way connectors actually behave today means it mostly goes unused, by design. The crypto-only payment model is a real filter on who can buy. The on-chain agent-payment rails everyone is excited about are not live in our stack yet. We are a few weeks into this, not a few years.
What we are confident about is the shape of the bet, not the size of the lead. The category is right: connectivity passes every test that matters for an autonomous purchase, and most of the alternatives fail at least one. The friction points are known and individually solvable. And the providers who sell data the old way — bundle SKUs, mandatory signup, card forms, QR-only activation — are optimised for a buyer who is about to stop being the only buyer. We would rather be early and honest about the gaps than late and polished. For a sharper head-to-head on where the legacy model still wins, the Roamzy vs Airalo comparison does not pull punches.
Where this goes
The first purchase an agent makes will be a boring one. That is the point. Connectivity is the on-ramp, not the destination — but it is the on-ramp almost everything else drives onto. Once an agent can reliably put a device on a network anywhere in the world, inside a budget, without a human at the checkout, the interesting tasks unlock by themselves: the travel agent that provisions data before the trip instead of leaving the user stranded at arrivals; the fleet agent that tops up a sensor in a field in another country; the personal assistant that keeps its human online as they cross a border, without being asked.
Data is the least exciting thing on the list of what agents will buy. It is also the thing the rest of the list depends on. That is usually how infrastructure works.
Questions builders ask
Does an agent need a Roamzy account to buy? No. An agent calls the anonymous-session endpoint and can price and purchase immediately. Claiming the session to a real identity is optional and happens after the fact, with a one-time code plus Google or Telegram sign-in.
How does an agent stay within a budget? Every token has a daily and monthly cap, a cool-off ceiling on new tokens, and a big-transaction gate that bounces unusually large purchases back to the human. The remaining budget is returned on every call, so the agent reasons about it rather than discovering it by failing.
What is the cheapest way to integrate? The remote MCP endpoint — connect by URL, no package to install, twelve tools available immediately. The install page and the developer guide cover both the remote and stdio paths, and the agents overview is the one-page summary of how the whole thing fits together.