Agents, agentic browsing and the agent-ready web

0:00 Agents and the agent-ready web

So far in this course, AI search has been about answers. Someone asks a question, an assistant writes a response, and hopefully cites you. But the next wave is already arriving. Agents that don't just answer, they act. They browse your site, compare options, fill in forms and, in some cases, complete the purchase for the user. In this lecture you'll learn what actually exists in twenty twenty-six, what's still outlook, and the practical steps that make your site agent-ready either way.

0:36 Exists today

Let's be precise about what exists today. User-triggered agent fetchers are live. Google added one called Google-Agent to its crawler documentation in March twenty twenty-six, for AI agents running on Google infrastructure. OpenAI, Anthropic and Perplexity all have user-initiated fetchers too. In commerce, OpenAI's Instant Checkout in ChatGPT runs on the Agentic Commerce Protocol, co-developed with Stripe, for eligible merchants in supported countries. These aren't predictions. They're in your logs and in your competitors' sales channels already.

1:09 WebMCP (proposal)

Then there's WebMCP. It's a proposal, published as a W3C draft in February twenty twenty-six and co-developed by Google and Microsoft, with an early preview and origin trial in Chrome. The idea is simple. Instead of an agent guessing what your buttons do by reading the page, your site registers named actions, like search products or get delivered price, with described inputs and outputs. Think of the difference between a tourist pointing at a menu and a waiter who hands them a clear list of dishes with prices. It's promising, but the API is still evolving, so don't ship production code from blog posts yet.

1:55 Verifying agents

One more emerging piece: verifying agents. Today, most sites identify bots by user-agent strings, which anyone can fake. Proposals for signed requests, using HTTP message signatures, sometimes called Web Bot Auth, let an agent prove cryptographically who operates it. Some providers and CDNs have started adopting this. For you, the practical upshot is that your bot management will increasingly be able to say, this really is a legitimate assistant acting for a user, and treat it accordingly.

2:28 Readiness = accessibility + clarity

Here's the reassuring part. Most agent readiness is excellent accessibility and clean engineering. Agents are demanding users. They can't guess, they don't enjoy animations, and they fail on ambiguous forms. So use semantic, accessible HTML: real buttons, links, labels and forms, with accessible names. Many agents read the accessibility tree, the same structure screen readers use, so this work also helps disabled users and your WCAG obligations. Keep flows predictable, show prices including tax and shipping, state stock clearly, and avoid dark patterns.

3:04 Also needed

Two more readiness items. Machine-readable facts: accurate JSON-LD and feeds, consistent with the page. And bot management that recognises agents. Decide which user-triggered agents you allow on which paths. Don't let a CAPTCHA wall silently block legitimate assistant visits to public product pages. But keep strong protection on login, checkout and account actions, because agents acting for users still need the user's authorisation. And write your returns, delivery times and eligibility rules as text, because agents quote them back to users.

3:39 Example 1: Abu Dhabi cake shop

Worked example one, simple. A cake shop in Abu Dhabi takes orders through a custom form where the date picker only works with a mouse drag. We test it with the keyboard only, which is a good proxy for agent operability. You can't pick a date. An assistant trying to place an order for a customer would fail at the same point. The fix is a native date input with a label. It helps keyboard users, screen-reader users and agents at once.

4:15 Example 2: Lahore homeware exporter (illustrative)

Worked example two, with illustrative details. A Lahore homeware exporter selling to the UK and UAE runs the spot check from the lesson text. The size selector is a custom div with no accessible name. The delivered price to Dubai only appears in the basket. And the returns policy is an image. Fixes: native form controls with labels, a delivered-price estimator on product pages, and a text returns policy. Those changes improve conversion and accessibility today, and make the site far easier for assistants and agents to use tomorrow.

4:54 Hands-on: agent-readiness spot check

Your hands-on is the agent-readiness spot check. Pick three key journeys, like find a product in size medium and see the delivered price to Dubai. For each, check you can complete every step with the keyboard only, that every control has an accessible name in the DevTools accessibility pane, that price, tax, shipping and stock are visible as text before checkout, that nothing needs hover-only menus or drag gestures, that errors are text rather than just colour, and that your logs show user-triggered agents getting two hundreds on those URLs. Run Lighthouse's accessibility audit as a quick baseline.

5:37 Watch me do it: agent-readiness spot check

Watch me do it. I'll run the agent-readiness spot check on one journey: find a cushion cover in the medium size and see the delivered price to Dubai. Step one: I unplug the mouse, figuratively, and use only Tab and Enter. From the home page I can reach the navigation and the cushions category. Good. Step two: on the product page, the size selector doesn't take focus at all. It's a custom div. Blocker one. Step three: I open Chrome DevTools, the Accessibility pane, and inspect the size options. No accessible name, no role. That confirms it. Step four: I look for the delivered price. Only the item price is shown; delivery to the UAE appears in the basket. Blocker two. Step five: the returns policy link opens an image. Blocker three. Step six: I check the logs for user-triggered agents on this URL: ChatGPT-User and Claude-User hits return two hundreds. So agents can reach the page, but they'd struggle to act on it. I run Lighthouse's accessibility audit for a baseline score, and write three tickets: a native, labelled size select; a delivered-price line for the chosen country; and the returns policy as text.

7:02 Outlook (clearly labelled)

Now the outlook, and I want to label it clearly as outlook, not fact. It's reasonable to expect that more discovery and comparison will happen inside assistants, that checkout inside assistants will expand country by country, that agent verification will move from user-agent strings to signatures, and that sites with clean data, accessible flows and clear policies will be easier for agents to recommend. Common mistakes: treating agent SEO as a new trick, CAPTCHA walls on public pages, and shipping experimental APIs without following the standard's status.

7:40 Recap and try this now

Recap. Agents that act are already here in early forms, commerce protocols are live in some markets, and WebMCP is a promising proposal. Readiness is mostly accessibility, data consistency, clear policies and sensible bot management. Try this now. Run the spot check on your single most important journey today, keyboard only, and fix the first thing that blocks you. And put a quarterly reminder in your calendar to revisit the status table in this lesson, because this area is moving fast.