From Destination to Delegation

For decades, the Web has primarily been a space of direct navigation. One went there personally, opened pages, compared sources, moved from tab to tab, and assembled fragments of information by hand. It has been our daily routine since the 1990s; I know it has been for me.

With the generalisation of the personal agent, that model is declining fast.

Increasingly, entry into the Web will begin not with navigation, but with delegation to an agent, be it ChatGPT, Claude or Gemini.

In a delegated mode, the user no longer visits websites in order to gather information; they simply ask an agent to do it on their behalf. The Web stops being primarily a place one visits and becomes a territory crossed by proxy.

The shift to delegation may sound like a small behavioural change, but it is structurally significant. In the current Web, much of a site’s value lay in its capacity to attract, retain and persuade a human visitor. In a delegated Web, value shifts toward the ability of a source, a service, or a knowledge surface to be read, extracted, connected, interpreted, and recomposed by agents.

The page view is losing its monopoly as the economic event, since content consumption and human readership are becoming increasingly separable.

#Becoming Agent-Friendly

Delegation changes what a source is for, and that changes incentives. Monetisation stops being tied only to being seen and starts being tied to being selected, trusted, and integrated into chains of delegated action.

Publishers, platforms, marketplaces, institutions, brands, and service providers have strong reasons to make themselves Agent-Friendly. Existing players are scrambling to expose cleaner machine-readable layers, better APIs, structured feeds, richer metadata, capability manifests, and more disciplined operational surfaces.

With good reasons. Google now features AI Overviews and AI Mode in addition to classic search. It allows a user to ask a question to an agent that will compose an answer on the fly. Google calls the mechanism "query fan-out": a complex question is broken into several related searches across subtopics and data sources. The engine then assembles a response and attaches links to the pages that support it. A site can therefore be selected for one sub-question inside an answer without ranking first for the sentence the user typed.

Imagine a buyer asking for a commuter bicycle that is light enough to carry upstairs, reliable in heavy rain, available in France, and repairable locally. The resulting answer may use one source for frame weight, another for weather protection, a retailer for current stock, and a local repair network for serviceability. There is no single ranking position for that answer. There is a field of sources, each contributing one piece of the decision.

This changes what “visibility” means. A brand may be mentioned without being linked or a recommendation may produce a sale without generating a visit to the cited page.

The implication for publishers is more demanding than adding a few keywords, though.

To be Agent-Friendly, a source must be usable by an agent. It has to state what it knows, under which conditions, with what date, scope, and evidence. A museum page that clearly distinguishes its collection, location, holdings, and access conditions is more operationally useful than a page that merely repeats a broad claim about cultural importance. A repair shop that publishes accepted brands, service area, opening hours, and current constraints gives an agent material it can actually use, for example.

#Agent-Ready Websites

Being read is only half of it. When an agent has to act on a site rather than simply read it, to book a table, order a part or file a form, it still does so the way a person would, only without eyes of its own: it inspects the page, guesses what each field and button is for, clicks, types and checks what happened. Google's documentation calls this actuation, and each of those steps is a chance to get it wrong. The next stage of being Agent-Ready is a site that tells the agent what it can do, instead of leaving it to infer.

That is the purpose of WebMCP, a proposed web standard backed by Google and Microsoft. A page declares its own tools, either by annotating an ordinary HTML form or by registering actions in JavaScript, each with its parameters and the result it returns. A travel site can expose one tool that searches available flights and another that books one; the agent calls them directly and receives structured data rather than a screen to interpret. For the agent running in the browser, the page behaves like a small MCP server, and the site keeps control of what is offered and on what terms.

WebMCP does not hand the agent the site's interface to redraw as it likes: the tools belong to the site, and the agent can only call them. What changes is who the interface is working for. When the agent calls a tool, the page updates in front of the person: a clothes shop narrows its catalogue to the dresses that were asked for, a design tool brings up the layouts that match, a code-review page displays the suggested patch as a diff, with the changes left uncommitted until someone accepts them. The interface becomes a space shared by the person and their agent, where the user sees, and can correct, what is being done in their name; the authors of the proposal are explicit that the human interface remains primary. Recomposing the interface itself, a surface assembled for one person at the moment of use, is a further step, and the subject of the next chapter.

Where this stands (autumn 2026)

Chrome opened a WebMCP early preview in February 2026, behind a flag in Chrome 146. At Google I/O on 19 May 2026, Google moved it into an origin trial running from Chrome 149 to Chrome 156, which lets any site switch it on for real visitors without asking them to change a setting; a general release is planned for Chrome 157. The draft specification is incubated in the open within the W3C Web Machine Learning community. Its limits are those of the browser: a tab has to be open, so it does not serve headless agents, and an agent only learns what a site offers by visiting it, which leaves the question of discovery where the rest of this book finds it.

Sources: Chrome for Developers, WebMCP documentation, 18 May 2026; Chromium, Intent to Experiment: WebMCP, 15 May 2026.

The other route runs in the opposite direction: instead of adapting to external agents, the site provides its own. An in-app agent answers inside the site or the app, with privileged access to the catalogue, the account and the order history, the way Amazon's Rufus answers shoppers inside Amazon. It keeps the customer at home, but it is also a primitive form of what this part will later call a presence: a business that, rather than being browsed, answers for itself. As visiting agents multiply, the two meet, and the in-app agent ends up talking to other agents as much as to people.