A few weeks ago I watched a customer try to book a job without ever opening my client’s website. They asked their assistant — the chat one, on their phone — to “find a local guy to regrout a shower and get me on the schedule this week.” The assistant found three businesses. It read all three sites. Then it came back with a summary and a flat recommendation: “Here are their phone numbers.”
That was the whole transaction. The agent did the finding but could not complete the booking, so it handed a phone number back to a human. That extra handoff can add friction, though the result depends on the customer and the business’s response process.
Discovery work still matters: clear content, structured data that matches the page, fast pages, and a useful local presence. Emerging agent experiences raise a separate question: if an assistant reaches the site, can it understand the next step and, where an implementation allows it, help a customer complete a safe, supported task? That capability does not guarantee discovery, recommendation, or conversion.
Two different jobs, and most sites only do the first
There are two separate things an AI agent needs from your website, and they are not the same skill.
Discovery is “can the agent understand what you are?” That’s content. Schema.org markup, a clean llms.txt, descriptive headings, an honest services page. This is the SEO conversation, extended to machine readers. We’re all reasonably good at it now.
Interaction is “can the agent do the thing?” For example, it might check availability, build a quote from an approved price list, start a contact request, or add an item to a cart. This is capability rather than content. Browser and agent support are still evolving, so treat it as a design and engineering decision—not a universal traffic channel.
Here’s the analogy I keep using with clients. Discovery is putting your menu in the window so people walking by can read it. Interaction is having a waiter who can actually take the order. A read-only site is a menu in a locked window. The agent presses its face to the glass, reads everything, and then tells its human to go find a door.
What actually breaks when the site is read-only
When an agent can only read, an action may degrade into a handoff to a human:
- It may not see that a requested day is already full.
- It may not have enough context to price a job accurately.
- It may not be able to use a human-only form or pass a CAPTCHA.
- It may not be able to reserve scarce inventory while the person decides.
Each of those can add friction. A business should still make the human path obvious, track the handoffs it can observe, and avoid assuming that an agent-capable integration will make it the default recommendation.
WebMCP: a site that hands the agent a set of buttons
The piece that’s been missing is a standard way for a website to say, in the browser, “here are the things you’re allowed to do here, and here’s how to call them.” That’s what WebMCP is.
If you’ve heard of MCP—the Model Context Protocol that lets AI tools plug into external systems—some emerging browser tooling explores an in-page version of that idea. A site can expose a small, deliberate set of actions with descriptions and typed inputs. Exact APIs and agent support are still evolving, so confirm browser support and user-consent requirements before depending on an implementation.
The important part: these aren’t a parallel universe. The tools wrap the exact same operations your real UI already uses. The “request a quote” tool calls the same endpoint your quote form posts to. The “check availability” tool reads the same calendar your booking widget reads. You are not building a second website for robots — you’re putting a second set of handles on the one you already have.
What we actually built
We are exploring this pattern on our own properties and evaluating it carefully for client use.
Our prototype uses a small internal library and a compatibility layer. On a site, it can register a narrow set of actions that map to what that business actually does:
search_services— return the real service catalog, with real prices, not a scraped guess.check_availability— read live open slots where the booking system permits it.request_quote/start_contact— start a structured request through the same validation and rate limits as the public form.- For the storefront sites,
add_to_cartandget_order_status— so an agent can assemble an order and a human can confirm the checkout.
Where a client supports it, we can publish machine-readable capability descriptors under /.well-known/. These are implementation-specific signposts, not a recognized search-ranking control or a promise that an agent will use them.
The human site should remain fully usable on its own. Any agent layer should be additive, preserve performance and accessibility, and fail safely when no compatible agent is present.
”Isn’t this a security hole?”
Good instinct, and the answer is only if you build it lazily. The tools you expose are a deliberate, small list — the same things you’d happily let a customer do on the public site, never the admin operations. Writes still go through the same validation, the same rate limits, the same auth your real endpoints already enforce. An agent calling request_quote is doing exactly what the form does; it just doesn’t need a mouse. You are widening the door, not removing the locks. We treat the agent like any other untrusted client, because it is one.
Why I think this matters more for the small guy than the enterprise
Agent-assisted interaction may become useful for some businesses, especially where availability, quoting, or booking are already well-defined. It is not a shortcut to recommendation or revenue. Start with a small, secure task, measure whether real customers use it, and keep the ordinary human journey at least as strong.
The discovery race — being found by AI — is already crowded. The interaction race has barely started. Get found, yes. Then give the agent something to do when it gets there. That is the difference between a website built for the present and a business system built for the next version of the web.
If a business wants to explore agent-assisted interaction, the work starts with a small, concrete capability layered on top of the existing site. The result should be judged by safety, usability, and real customer benefit—not a promised AI-search result.
For the discovery side of the same problem, read Is Your Business Ready to Be Recommended by AI?. If you want to see the human-facing build process, start with how we build.