The Agent Interface and the New Internet

For most of its history, the web has had one kind of user in mind. Pages were built to be seen, funnels to be walked, checkout flows to be tapped through by a person who could be persuaded, upsold, and remembered. A company's advantage online rested largely on its command of that experience. The interface was the product, and owning it meant owning the customer.

A growing share of the requests arriving at commercial sites now comes from software agents acting for a person who is not watching. They do not see the page, cannot be upsold, and will not remember the brand. Cloudflare has begun calling this an “agentic internet,” one that has to be readable, discoverable, callable, and payable by machines rather than only by people. The framing is useful, but the point that matters for anyone running a business online is what it does to the location of advantage. When the visitor is a machine, the interface stops being where you win or lose. The contract does.

Two developments over the past year moved that from a thesis to something operational.

The first is a collapse in what it costs to expose a business to agents at all. Until recently, making a large service available to a model meant describing every function it could call, and the arithmetic was punishing. Cloudflare's own API runs to more than 2,500 endpoints; presented to a model as individual tools, the descriptions alone would consume over a million tokens before any work began. Their answer, called Code Mode, abandons the giant menu and lets the agent write code against a typed interface exposing roughly two operations, search and execute. The cost falls to about a thousand tokens and stays flat no matter how many endpoints sit behind it. The significance is not the elegance of the design but the economics it unlocks. Exposing a full product surface to agents has gone from impractical to routine, and the technical reasons a company might have cited to postpone it are mostly gone.

The second is that payment, the step most businesses defend most jealously, can now sit inside the request rather than outside it. HTTP has long carried an unused status code, 402 Payment Required. A standard named x402, authored by Coinbase, finally gives it a job. An agent requests a resource; the server replies with a 402 and a short set of terms; the agent signs an authorization; a facilitator settles the amount, commonly in a stablecoin such as USDC; and the request is retried and served. A machine can discover a price and pay it in a single exchange, with no account created and no human at the keyboard. Whatever one makes of the settlement rails, the consequence is what counts. A customer relationship, and the revenue attached to it, can now form entirely outside the app a company spent years perfecting.

Incumbents are already choosing sides. In July, DoorDash, a business as protective of its interface and as squeezed on margin as any in consumer technology, released dd-cli, a tool that lets an agent search stores, find deals, assemble a cart, and check out without opening the app. It is a limited beta, and I would not read too much triumph into it. The revealing part is the logic. A company in that position does not open itself to agents because it wants to give up the customer. It does so because refusing would not keep agents away. It would only guarantee they arrive through paths the company neither designed nor controls.

That logic is what leaders should absorb. For a decade the reflex toward unwanted traffic was to block it. Against agents the reflex fails, because a determined agent does not need permission to use a public site; it needs only to tolerate a worse experience. So blocking does not remove agents from the equation. It removes your ability to see them, price them, and shape what they can do. The real choice is not whether machines transact with you, but whether they do so through an interface you defined or one they improvised at your expense.

Several things follow for anyone leading an engineering or product organization. Assume agent traffic is already in your logs, because it almost certainly is, and make it visible before you write any policy about it, since you cannot govern what you cannot see. Treat sanctioned agent access as a product surface with an owner, a roadmap, and the ordinary controls of pricing, authentication, and rate limiting, rather than as an experiment parked to the side. Where you expose functionality, prefer an explicit contract, whether an MCP endpoint, a command line tool, or a well typed API, over a screen that agents scrape, because a contract lets you meter and authenticate while a scraped page breaks with every redesign and reveals nothing. Stay loosely coupled to the payment and identity standards now competing for primacy, none of which has clearly won, so you can adopt the survivor instead of committing early to a guess. And resolve the questions that carry legal weight before an agent spends money on a customer's behalf: who authorized the purchase, what limits bound it, how it is audited, and who answers when it goes wrong. Those cost far less to settle in a design review than in a dispute.

The human web is not disappearing, and most companies will serve people and their agents side by side for years. But the useful question a year from now is not whether agents count as real users of the internet. It is whether the systems you run were built for them, or merely survived them.

About the author

Lucas Hendrich
CTO at Forte Group

You may also like

Transform AI into a Scalable Delivery Capability

83% faster delivery. Under 10% rework. See exactly how Xceptor got there.