Plan — 18 August 2026

We wrote last week about WebMCP — the emerging pattern that lets AI agents interact directly with the actions on a web page rather than scraping the DOM and guessing. It's a sensible technical direction, and it's coming faster than most SME websites are prepared for.

But before anyone spends money building for it, there's a cheaper and more useful exercise: work out which tasks on your own site a customer's agent would actually need to complete, and whether those tasks would survive contact with one.

Agents are already booking restaurant tables, checking order status, and renewing subscriptions on behalf of customers who never open the browser tab themselves. Most business websites weren't built with that in mind. They were built for a human with a mouse, some patience, and the ability to squint at a red border around a field and work out what went wrong. A script following the same path doesn't have that patience, and it can't squint.

Start with a list, not a strategy

The audit itself is unglamorous. Sit down and write out every task a customer currently completes on your site without ringing you. For most SMEs this is a shorter list than you'd think, and it usually includes some combination of:

A trades business might only have three or four of these. An ecommerce store or subscription SaaS product will have most of them. The specifics don't matter as much as the discipline of writing them all down in one place — most businesses have never done this, because each flow was built at a different time by a different developer for a different reason, and nobody's looked at them side by side.

What to ask of each one

Once you have the list, go through each flow and ask a few concrete questions:

Does it have a clear start and end state? A booking either completes or it doesn't. A search either returns results or it doesn't. If "success" is ambiguous even to a human, it's going to be worse for a script.

Is the required data structured, or does it depend on visual interpretation? A date field is structured. A calendar widget where available times are rendered as an image, or only distinguishable by colour, is not. An agent reading the DOM for text can usually find a date field. It has no reliable way to read a colour.

Does the flow depend on a verification step built for a human? CAPTCHAs, SMS one-time codes, and email confirmation links all assume a person is sitting there, actively participating, in real time. An agent acting on someone's behalf hits a wall the moment one of these appears mid-flow.

Do errors produce something a script can parse? "Something went wrong" and a red outline tells a human enough to try again. It tells a script nothing. A structured error — wrong field, wrong reason — is the difference between an agent correcting itself and an agent giving up.

Run every flow on your list through those four questions and you'll end up with a rough classification: ready, partially ready, or blocked. That's the audit. It costs an afternoon and a spreadsheet, not a development budget.

What the list usually reveals

Read-heavy flows — search, availability, order status — tend to be closer to ready, because they're often already backed by an API or a reasonably clean data layer. Write-heavy flows — booking, checkout, account changes — are where things fall over, because they were built with a human confirming each step visually, and the validation logic lives entirely in the browser rather than being exposed anywhere structured.

It's also worth being honest that not every flow should become agent-completable, even once it's technically possible. Checking availability or price is low-risk territory — an agent reading that information doesn't expose you to much. Actually completing a booking, a payment, or a cancellation is different. These carry fraud, liability, and trust implications that sit with your business, not with whichever agent the customer happened to be using. For those, a confirmation step back to the actual customer is a reasonable design choice, not a limitation you need to engineer around.

The harder problem underneath all of this is authentication. How does an agent prove it's acting for a real, verified customer without you handing out login credentials to a piece of software you've never seen before? Nobody has this fully solved yet, which is a reasonable argument for keeping anything with real financial or legal weight — refunds, account deletion, payment method changes — as human-confirmed for now, regardless of how capable the agent is.

The audit is diagnostic beyond AI

One thing that tends to surprise people doing this exercise: the flows that are hardest for an agent are usually the same flows that are quietly annoying for human customers too. A booking calendar that only works with a mouse drag, an error message that just says "invalid input," a checkout that times out the session without warning — these were never good UX. Agent-readiness just gives you a concrete reason to notice, because a script's failure is binary where a human's frustration is silent.

So the audit pays for itself twice. It gives you a prioritised list for whatever agent-facing work you eventually do — which flows need a small fix like better error messages or accessible labels, which need real re-architecture, and which you'll deliberately keep as human-confirmed. And it surfaces UX debt you were probably carrying anyway.

None of this requires committing to a WebMCP build, a new platform, or a development sprint. It requires a list, an afternoon, and a willingness to look honestly at flows that have probably been left alone since whoever built them moved on. If you want a second pair of eyes on that list, or help working out which flows are worth making agent-ready first, book a conversation.