Six ways to make your product work for AI agents. What each one actually buys.

For a lot of teams, yes, and we would rather say so here than in a kickoff. The volume argument is the one to start from: SE Ranking’s 2026 analysis of AI referral traffic put traffic arriving from AI search and assistants at roughly 0.32% of all website traffic, up from about 0.24% in 2025 and 0.02% in 2024. That is a sixteen-fold rise in two years and it is still a fraction of a percent, so anyone telling you the channel is already decisive is selling something. What makes the number interesting is not its size but its slope and its concentration: it is wildly uneven by category, and the teams it is already material for tend to be ones where a buyer researches before committing, or where the task is repetitive enough that somebody would happily delegate it. So the test is your own data rather than the industry average. Split your referrers and your server logs by assistant and agent user agent and look at the trend over the last two quarters. If it is flat at zero, build for your human funnel and revisit next quarter. If it is small and compounding, you have a channel forming, and the right response is the cheap durable layer now rather than a product bet. The expensive mistake is not being late. It is building an agent surface for a channel that never arrives, and then maintaining it.

Very often yes, and it is the first thing we recommend to most teams who ask about any of this. It is cheap, it is durable whichever way the agent standards land, and a large share of it is work you would want for ordinary search anyway: accurate structured data, headings that say what the section is, a real answer in the first paragraph rather than a preamble, an llms.txt, a documented API, and content that covers the questions and comparisons a buyer asks rather than only the keywords they type. Where it stops is specific and worth understanding before you decide it is enough. Discoverability gets you found, quoted and described correctly. It does not let anything happen. An agent that can read your pricing page perfectly still cannot start a trial, check coverage for an address, reorder a consumable or reschedule a delivery, so a user who wanted that done leaves the assistant and completes the task somewhere that made it possible, or does not complete it at all. The honest sequencing rule: do the discoverability layer until assistants describe you accurately, then look at whether anybody is trying to act and failing. If nobody is, you are done, and you have spent very little. That is a real outcome and we say it out loud because the alternative, selling a product surface to a team whose problem was a thin pricing page, is how this category gets a bad name.

Mostly you would not, and if the platform is your main channel then riding its server is the correct answer. The platforms have been explicit about the model. When Microsoft put the Dynamics 365 Commerce MCP server into public preview on 29 June 2026 it described MCP as "an open standard that lets a platform expose its capabilities once, enabling supported AI agents across multiple surfaces to call them in real time", and the surface area it listed is the commerce stack itself: product discovery, inventory availability, pricing, discounts, checkout, store operations. If your catalog is the product and the platform runs your checkout, that covers the task, you get agent reach with no build and no maintenance, and duplicating it with your own server is work with no upside. What you are trading away is worth naming, though, because it is the same trade as every marketplace. The platform owns the interface, so the agent sees the fields it chose to expose rather than the ones that differentiate you. It owns the ranking, so you compete inside its ordering. And it owns the relationship, so the agent transacts with the platform and you receive an order. Teams that eventually build their own surface do it for one of three reasons: the thing agents should be able to do is not in the platform’s model at all, the differentiator is an experience rather than a catalog row, or they have a direct channel they are unwilling to let an intermediary mediate. If none of those is true for you, stay on the platform. That is not us declining the work, it is the cheaper correct answer.

Where the agent is standing, and whose session it is acting in. WebMCP is in-page: your own site declares tools, in JavaScript, and an agent running inside the browser calls them in the session the user is already signed into, with the permissions they already have. That makes it the right shape for anything that depends on being that user, right now, in that account, without you building a second authentication path or handing credentials to anything. It is also the newer of the two and still moving: it entered a public Chrome origin trial, reported by InfoQ in June 2026, running from Chrome 149 to Chrome 156, and has been submitted to the W3C where it is incubating in the Web Machine Learning community group with both Google and Microsoft involved. Submitted and incubating is not shipped, so treat it as a scoped bet with a known expiry rather than infrastructure. A hosted MCP server is the opposite: it is your product exposed as a remote service that any MCP host can connect to, which today means usable from inside ChatGPT, Claude and the other assistant hosts without the user visiting your site at all. With MCP-UI it can return your own interface rather than a block of text, so what the user sees is a surface you designed instead of a model’s paraphrase of it. The cost is that it is a real product surface: its own auth, rate limiting, abuse handling, versioning and support load. The two are complements, not alternatives, and most teams need neither first. The deciding question is the one from the reads above. If the task requires the user’s signed-in session, WebMCP. If the task should work from inside an assistant without your site, a hosted server. If you cannot name the task, build neither yet.

Buy the widget if the job is answering questions about documents you already have, and build if the answer has to do something or has to look like your product. A hosted chat or search widget is genuinely good at retrieval over a corpus: documentation, a help centre, a policy library. It is fast to install, somebody else maintains the retrieval quality, and for a support use case it is frequently the whole answer. The point where buying stops working is when the response needs to be an interface rather than a paragraph. A chart with your real data in it, a comparison table the user can sort, a form prefilled from the conversation, a seat map, a schedule, a checkout step. That is generative UI, and it is a Frontend problem rather than a prompt problem: the components have to be typed so the model cannot produce a shape your app cannot render, streamable so the user is not watching a spinner, accessible so the generated path is not a dead end for keyboard and screen reader users, and bounded to a registry of real components so the model composes your design system instead of inventing a fourth button. A widget cannot do any of that, because it does not have your components. The other half of the decision is data boundary. A widget means your content, and often your users’ questions, live with a vendor. For a public help centre that is usually fine. For anything touching customer data it becomes an architecture decision rather than a purchase, and it is worth making deliberately rather than discovering it in a security review.

Several things, and they come up in the first conversation rather than three months in. If your own logs show no agent or assistant traffic and no trend, there is no channel to serve yet and the quarter is better spent on the funnel you can measure. If assistants cannot currently describe what you sell, every budget should go to the content and structured-data layer first, because nothing will call a tool it never found. If your domain logic lives only inside your components and your controllers, with no API boundary to expose, the honest first project is extracting it, which is unglamorous and is the actual blocker: teams that skip it ship a tool layer wired into the UI and then break an agent integration on every release. If you cannot name one concrete task an agent should be able to finish, you are not ready to expose tools, and exposing them anyway produces a capability surface nobody uses and everybody has to maintain. If the platform you sell through already covers the task, stay on it. And if what you want is a demo for a board meeting, we are the wrong shop, because the thing we would build is a product surface with auth, rate limits and a support load, and that is a bad way to buy a slide. The one thing we will not do on request is ship an agent interface without the guardrails around it. A tool that an agent can call without authentication, rate limiting, input validation and an audit trail is not an integration, it is an incident waiting for a quarter to happen in.