Earlier this year I kept thinking that AI would eventually move inside websites. I imagined a layer of intelligence installed into a site, perhaps through a plugin or API connection, which would understand the business and help operate parts of it from within. The direction that has emerged is slightly different, and I think it is more interesting because it changes the relationship between the website and the intelligence around it.

The intelligence often stays outside the website. The website increasingly exposes information and actions that an assistant can understand and use. Instead of every site becoming its own isolated AI product, an external assistant can become the interface through which many different products are discovered and operated.

MCP gave external intelligence a way to act

MCP, the Model Context Protocol, is one of the clearest examples of this shift. Anthropic introduced MCP in 2024, and adoption moved quickly across AI products, developer tools and external services. The protocol gives an AI application a standardized way to connect with tools, data and actions that live somewhere else.

The easiest mental picture for me is a set of handles exposed by the product. The AI can use those handles to search a database, create an object, change a setting, publish an item, retrieve information or send a request. The intelligence can remain in ChatGPT, Claude or another assistant while the useful capability stays inside the product that owns the data and action.

This architecture changes how a website or application can participate in an AI workflow. The product does not need to recreate a complete assistant for every user. It needs to expose useful capabilities clearly enough that an assistant can understand when they are relevant and use them with the right permissions.

Websites are also becoming easier for agents to understand

The action layer is only one part of the change. Websites have been machine-readable for a long time through structured data and conventions such as Schema.org, which help search engines understand whether a page represents a product, an organization, an article, a person, a price or another defined object.

Newer approaches extend that idea toward AI assistants. The llms.txt convention gives a website a place to explain what it contains and where important material can be found. WebMCP explores a further step by exposing page functionality in a form that a browser-based agent can understand and use. MCP connects assistants with tools and services beyond the page itself.

These technologies overlap in places and will continue to develop, so I would avoid treating the current boundaries as permanent. The larger direction is already visible: a website increasingly needs to be understandable to both people and agents, with a human interface on one side and a clear machine-facing layer on the other.

The website now has two audiences

A human visitor needs navigation, visual design, explanations, forms, buttons and a coherent experience. An AI assistant needs clear information about what the product is, what it can do, which actions are available, what permissions are required and what should happen after an action is requested.

This creates a practical new design question for companies. A website can still be a destination that a person opens in a browser, while it can also become a resource that an assistant searches, interprets, recommends and operates without requiring the person to navigate every screen manually.

That second audience changes the value of documentation, structured information, APIs and explicit action definitions. A product that is beautifully designed for a human can still be difficult for an assistant to represent correctly if its purpose and capabilities are vague. A product with clear machine-facing information becomes easier to understand and easier to place inside an AI-mediated workflow.

Bring your own agent, or bring the website into the intelligence

For a while I expected a future built around bringing your own API key into every product. I now see two broader directions. In the first, you bring your own assistant into a product. Your assistant already knows your preferences, context, permissions and tools, so the product can work with intelligence the user has already chosen.

In the second direction, the website itself enters the assistant environment. The assistant becomes the interface and the website becomes one of the available products behind it. The user asks for an outcome, the assistant identifies a relevant service, retrieves the required information and uses the available actions.

The two directions can coexist because they are different views of the same relationship. A person can enter a product with an assistant, or remain inside the assistant and access the product from there. As the interfaces improve, the difference may become smaller from the user's perspective.

Google offers a useful historical analogy

For roughly a quarter of a century, businesses adapted their websites to become products inside Google's discovery environment. Pages were created so a search engine could find them, understand them, rank them and send people toward them. Search became one of the main ways a website entered a person's decision process.

AI assistants may create another version of that relationship. A company will still want a strong human-facing website, while the same company will also want its products and capabilities to be understandable inside AI environments. The assistant may recommend the company, compare it with alternatives, retrieve information from it and eventually perform an action on the user's behalf.

This creates a much larger definition of web visibility. The goal extends beyond appearing in a list of links. A product also needs to be represented accurately enough that an assistant understands when to choose it and knows what can happen after the choice is made.

What this changes for builders

The practical work begins with clarity. Products need clear descriptions, well-structured information, predictable actions and explicit permissions. If an assistant can connect to a service, the service needs to expose useful capabilities without forcing the AI to guess what every button or field means.

The next step is deciding which parts of the product belong inside the assistant experience and which parts still deserve their own interface. A conversational request may be perfect for retrieving information, creating an object or changing a simple setting, while a detailed visual editor may still work better on the product's own surface.

I increasingly think the future web will support both modes at once. People will continue to open websites directly when they want depth, exploration or visual control, while many routine interactions will begin inside assistants that already know what the user is trying to accomplish.

The change is easy to underestimate because the web still looks familiar on the surface. Underneath that familiar browser experience, websites are gradually becoming easier for external intelligence to understand and operate. That may change how products are discovered, how users interact with them and, once payment rails become normal, how transactions happen as well.