The Future of AXD

Forecasting in this field ages badly, so what follows is grounded in what actually happened rather than what might. Each section states the development and then the part that matters here: what it changes about the design work.

1. The interface a site presents to an agent becomes a designed artifact

WebMCP — a draft in the W3C Web Machine Learning Community Group, co-edited by Google and Microsoft — lets a website expose structured, callable JavaScript tools to an agent running in the browser. It was headlined at Google I/O in May 2026 and entered a Chrome origin trial spanning Chrome 149 through 156. Instead of an agent inferring intent from the DOM and clicking around a page built for human eyes, the site declares what it can do: search inventory, apply a filter, add to cart, start a return.

For AXD this is the most consequential structural change on the list, because it creates a second interface that has to be designed. A tool surface has an information architecture, naming, error messages, defaults, and boundaries — and unlike a visual interface, its entire vocabulary is what the agent will believe about your product.

• Tool naming and descriptions are UX copy. They are the labels an agent reads and, often, the words it echoes back to the user when explaining what it is about to do.
• Granularity is a design decision. Too coarse and a single call performs several consequential things with one authorization; too fine and the agent has to compose long sequences it can get wrong halfway through.
• The two interfaces must agree. If the agent-facing tool can do something the human-facing UI forbids — or applies different validation, pricing, or policy — the divergence becomes a support and trust problem the moment anyone notices.
• Consequential operations still need a human moment. Exposing a tool is not the same as authorizing its use; sites will need to decide which calls demand confirmation in their own surface rather than in the agent’s.

This is where AXD and AXO converge in practice: the tool surface is an optimization concern (be usable by agents) and a design concern (be safe and legible when they use it) at the same time.

2. Agentic browsing became a feature, not a destination

The 2025 assumption was that agentic browsing would produce a new category of browser. It mostly did not. OpenAI launched Atlas in October 2025 and shut it down on 9 August 2026, folding its capabilities into ChatGPT. Microsoft retired Edge’s Copilot Mode in May 2026. Perplexity’s Comet went free and spread across macOS, Windows, Android, and iOS — the iOS release landing in March 2026 — competing on reach rather than on being a separate destination. And on 12 August 2026 Claude’s Chrome extension became a full Cowork client: the agent working inside the browser the user already had.

The pattern is consolidation into the assistant and into the existing browser, not migration to a new one. Three design consequences follow.

• The side panel is the dominant surface. Agent and page share the screen, which makes supervision concrete: the user can see the thing being acted on while the agent acts. Design for a narrow column adjacent to arbitrary content, not for a full-width canvas you control.
• You do not own the frame. Your site is now sometimes the object of an agent session hosted by someone else. The agent’s chrome supplies the stop control and the approval dialog; your interface supplies whatever legibility exists about what just changed.
• Sessions carry the user’s real identity. An agent in the browser is logged in as the person, everywhere they are logged in. The blast radius of a bad step is the whole authenticated web, which is a strong argument for scoping and confirmation rather than for trusting any single page.

3. Agents can spend money, so consent design gets serious

Payment infrastructure for agents arrived quickly. The x402 Foundation moved under the Linux Foundation in April 2026, putting a neutral home under the HTTP-native machine payment pattern. Mastercard announced Agent Pay for Machines in June 2026, and Visa has shipped an agent payments API. The rails are no longer hypothetical.

Which makes consent for money-moving actions the live design problem of the moment. Existing checkout patterns assume a human present at the moment of payment, reviewing an amount and a merchant on a screen. Agent payments break every part of that assumption: the person may have authorized in advance, for a class of purchase, at a price not yet known, from a merchant not yet chosen.

• Authorization moves upstream. Consent is granted at delegation time, so the delegation interface has to carry what a checkout page used to: scope, limits, duration, merchant constraints, and what happens when the agent hits a boundary.
• Standing permissions need a visible current state. If a person cannot answer “what is my agent allowed to spend right now, and on what?” from one screen, they have not meaningfully consented.
• Design the boundary behavior, not just the boundary. Hitting a limit should produce a specific, resumable request — this item, this price, this reason — not a dead end or a generic re-authorization.
• Receipts must be attributable. Post-hoc, a person needs to see which agent, acting on which instruction, under which grant, bought what. This is the audit surface that makes dispute and correction possible.
• Expiry by default. Standing spend authority that never lapses is the failure mode that will produce the first genuinely bad headlines.

4. Prompt injection is an interface constraint, not only a security one

Brave’s research on agentic browsers demonstrated indirect prompt injection through ordinary page content and, more uncomfortably, “unseeable” injections carried in screenshots — instructions invisible to the user but legible to the model reading the page. The finding that matters for design is structural: for a model, there is no reliable boundary between the user’s instruction and the content it was asked to read. Both arrive as text in the same context.

That breaks the confirmation dialog as a safety mechanism. “Are you sure?” only protects a user when the proposed action reflects their intent and they can evaluate it. If a page injected the instruction, the dialog faithfully presents an attacker’s action in the product’s own trustworthy voice, and the user approves it — correctly, given what they were shown. Consent obtained on false premises is not consent; it is a record of one.

Design responses that do more than restate the risk:

• Show provenance of instructions, not just of data. When a step originates from fetched content rather than the user’s request, say so and show the source. A user who can see “this came from the page, not from you” can catch what a generic confirmation hides.
• Escalate on provenance, independent of cost. An action derived from untrusted content deserves tighter oversight than the same action derived from a direct instruction, even if the operation itself looks routine.
• Constrain capability by context. An agent reading an untrusted page should not simultaneously hold the ability to send mail, move money, or change permissions. Scoping the tool set to the task is more effective than asking the user to be vigilant.
• Make the plan reviewable before execution. Injection usually shows up as a step that does not follow from the request. That is visible in a stated plan and invisible in a per-action dialog.
• Stop treating vigilance as a control. Any design whose safety story depends on the user noticing something subtle has no safety story.

5. Agents increasingly carry their user’s permissions

On 4 August 2026 the Ninth Circuit vacated Amazon’s injunction against Perplexity’s Comet, on the reasoning that a user-directed agent is the user acting. It is one appellate decision rather than settled doctrine, but the direction is clear enough to design against: an agent operating at a person’s direction inherits that person’s standing rather than being treated as a third-party intruder by default.

If that holds, “block the bots” stops being a viable posture toward agents acting for your own logged-in customers, and the design question becomes how to serve them well:

• Distinguish agent sessions from human ones without degrading them. Knowing an agent is driving lets you present the right surface — structured tools, clearer state, explicit confirmation of consequential steps — rather than an anti-automation obstacle course aimed at your own customer.
• Design the accountability record. If an agent acted as the user, the user needs a clear account of what was done in their name and a path to reverse it. That record is a product surface, not a log file.
• Expect delegation to be visible. Attribution of agent activity — which agent, on whose behalf, under what grant — is becoming table stakes for both sides of the interaction.
• Assume permission inheritance is the default. Design your authorization model around what the human may do and what they explicitly delegated, rather than around detecting automation.

What this adds up to

Each of these shifts pushes the same direction: the interesting design surface is moving from the conversation to the boundary. What an agent is permitted to do, on whose authority, through which declared interface, with what record afterward — those decisions now determine the quality of an agentic product far more than the phrasing of its responses.

For practitioners, the work that will still be relevant in three years is the unglamorous kind: the action taxonomy, the permission model, the provenance display, the recovery path. The chat interface was never the discipline. Delegation is.