# The agent said it was in stock

Source: https://tpiros.dev/blog/the-agentic-web

For the past year or so I've been leaning on agents for shopping legwork: "best shops that sell [product] in [city]", "where to buy [product]". The answers came back confident and, an awful lot of the time, wrong.

Shops that don't sell the product. A product page that plainly said out of stock while the agent told me the opposite. A warm recommendation for a place that had permanently shut down. All of it after the agent ran a live web search, so it wasn't just misremembering its training data.

[Kasper Kulikowski's recent essay](https://www.kulikowski.me/blog/what-is-the-agentic-web) defines the Agentic Web as "a web where agents complete workflows on behalf of humans". I want that web badly, and I see two parts to it. One is an agent looking at a page and understanding it: what it can do, where to type, because the site declared its capabilities through WebMCP. The other is discovery, deciding which page deserves the visit in the first place.

# Talking to pages

Today, an agent driving a website works the way you'd teach someone to use a computer over the phone. The screenshot-driven kind guesses which of the 14 buttons is the real "add to basket", clicks at coordinates, waits, screenshots again, and breaks the moment a designer moves a button.

The kind that reads the accessibility tree instead (Playwright MCP and Chrome DevTools MCP work this way) survives the redesign, but it's still feeling out a UI built for humans: a fresh snapshot every step, and nothing tells it what the page can actually do.

WebMCP is the proposal that addresses this half. It's being incubated in the [W3C Web Machine Learning Community Group](https://github.com/webmachinelearning/webmcp), with the initial proposal coming from engineers at Microsoft and Google. The idea: a page registers what it can do as tools, in the same shape MCP already uses, straight from its own JavaScript.

```javascript
await document.modelContext.registerTool({
  name: 'add-todo',
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: 'object',
    properties: {
      text: { type: 'string', description: 'The text of the todo item' },
    },
    required: ['text'],
  },
  async execute({ text }) {
    await addTodoItem(text);
    return { content: [{ type: 'text', text: `Added: "${text}"` }] };
  },
});
```

Instead of the agent inferring what the page does, the page tells it. Everything runs in the session you're already logged into; the agent gets a proper interface rather than a picture of one. I've written a [deeper dive into WebMCP](/blog/building-with-webmcp) as a separate post, so I'll leave the mechanics there.

# The same problem, twice

Put my two parts next to each other and they share a root cause: the agent is acting on guesses.

On the interaction side, the guess is what a page does, reconstructed from pixels and DOM scraping. On the discovery side, the guess is what a business actually sells right now, reconstructed from search snippets and pages indexed at some unknown point in the past.

My out-of-stock product was presumably in stock when a crawler last visited. The shop that closed for good still had a website and years of reviews. The agent read all of that and produced a confident answer about a world that no longer exists.

WebMCP replaces the first guess with a declaration. The second guess is still how discovery works today, although that has started to move.

And it's not for lack of vocabulary. schema.org has had `Product` and `Offer` markup with an `availability` field for well over a decade; the words for "in stock" have existed the whole time.

The markup goes stale because it exists to win rich results in search listings: it gets stamped at render time, crawled on the search engine's schedule, and drifts out of sync with the inventory system that holds the real answer. For years that didn't matter, because a human clicking through would see the live page anyway and self-correct. An agent that stops at the snippet never gets that correction, and neither does the human trusting the agent.

# What discovery actually needs

If I sketch what would have prevented my bad shopping answers, the first requirement is that the data has to be live. "Do you have this in stock, in size 43, today" needs an answer computed from the inventory system at query time, the same way the shop's own product page computes it.

That's a query interface, and MCP already gives us the shape for one. A shop exposing a `check_stock` tool is a thin wrapper over an API it almost certainly already has for its own frontend.

The harder requirement is honesty. The moment agents route purchasing decisions, sites gain an incentive to lie to them: answering "yes, in stock" to every agent query becomes the new keyword stuffing, bait the visit and upsell something else once the human arrives.

Search engines spent two decades building spam teams for exactly this dynamic, and the agentic version starts from zero. Somebody has to build the layer (reputation, verification, perhaps signed responses) that lets an agent trust a shop it has never talked to before.

And then there's the question of who you even ask. Today's agents query the same search indexes we do and inherit their staleness.

An agent-native index would crawl capability declarations rather than prose: which sites near me expose a stock-checking tool, which ones let an agent reserve or buy. That looks more like a service registry than a search engine.

That registry is closer than I expected when I started writing this post.

Google announced the [Universal Commerce Protocol](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/) in January, built with Shopify, Etsy, Target, Walmart and Wayfair: a merchant publishes a manifest at `/.well-known/ucp` declaring what an agent can do with the shop, and Google's announcement calls real-time inventory checks critical to the whole design.

OpenAI and Stripe's [Agentic Commerce Protocol](https://developers.openai.com/commerce) put checkout inside ChatGPT for about six months, until OpenAI retired the first version of Instant Checkout in March and refocused on product discovery, with purchases finishing on the merchant's own checkout.

And in June, Google published the [Agentic Resource Discovery](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/) draft, building on the AI Catalog data model from a Linux Foundation working group: any site can publish an `ai-catalog.json` under `/.well-known/`, registries crawl those catalogs, agents search them by intent, and domain ownership doubles as identity verification. That's the service registry, and a slice of the trust layer, sketched out on paper.

What's missing is everything between a published spec and my Tuesday afternoon shopping question. Merchants have to publish these manifests and keep them wired to live inventory rather than marketing copy, and the agents I actually use have to consult them instead of the old index.

Every wrong answer I complained about above happened while these drafts were circulating. We're solving the vocabulary problem for the second time; whether the answers stay truthful is still open, and schema.org shows how that goes when the incentives point elsewhere.

# Why a shop would bother

Kasper's essay makes the commercial point: how usable your site is for agents starts to affect conversion. It reminds me of when page speed and mobile layouts became ranking signals, and suddenly every shop cared about both.

I'd put it more bluntly: an agent that can verify stock at shop A and can only guess at shop B will send the buyer to shop A every time. It has no brand loyalty and it doesn't window-shop.

For 20 years, the deal was that you make your site legible to Google and Google sends you humans. The agentic version of that deal is the same shape with a different reader, except this reader doesn't stop at your landing page. It checks whether your claims hold up before it recommends you, and when it catches your markup lying, there's no charitable human to shrug it off.

What I want is mundane. I want to ask "where can I buy these [products] in [city] today", get back two shops where "in stock" was checked against the till seconds ago, and have the agent maybe reserve a pair because the shop published a tool for exactly that.

The interaction half of that story has a spec and code you can run in a browser today. The discovery half has three specs and, so far, no answer I can trust, and that's the half I keep getting burned by.