Brahim Bousnguar

Notes · Article

Websites won't die, they'll stop being the front door

By · · updated · 6 min read

Personal assistants will become the main way into the web, and websites one surface among several. Liad Yosef made that claim at AGNTCon + MCPCon Europe. He co-created MCP Apps, which let a service show its own screens inside an AI chat.

I had just spent two weeks making this site readable by AI agents, so that line stopped me. Then his research found a gap in my own site.

Who walks through the front door

The website stays, but it stops being the way in

TodayAgentic web

You open a browser tab for each businessYour assistant goes in for you

You learn its menus just to say what you wantIt already knows, and calls each business behind the scenes

The website is the way inThe website is still there, just not the way in

Every business is a websiteOnly the last mile, like a seat map, comes back to you

Based on Liad Yosef's MCP Apps and the agentic web, AGNTCon + MCPCon Europe 2026.

What he actually said

The talk is MCP Apps and the agentic web. It ran on the same livestream as the Dex Horthy keynote I wrote about in the software factory note. The line:

We might have websites and browsers lose their position as the main entry point to the web.

He doesn't say the web dies. He compares it to mobile: desktop didn't go away, but social media moved to phones and stayed there. Nobody opens Instagram on a laptop.

His bet is that a lot of what we do on websites moves to agents the same way, and stays.

His evidence was a list of companies already moving. Sentry now aims at agents first, a year after its CPO bet him that websites would still be around in 25 years.

Salesforce is going headless. DoorDash ships a CLI. He also cited Cloudflare: bot traffic passed human traffic faster than expected.

A website is a way to tell a business what you want

This part made the idea clear for me. When you land on booking.com, the site doesn't know if you want to book a hotel, file a complaint or log in. The whole interface exists so you can tell the business what you want.

If you already told your assistant what you want, it doesn't need to click through a website to pass that on. It can just call the business.

What's left is what he calls the last mile: things that are hard to do in text, like picking a seat in a venue or checking a calendar. That's where MCP Apps come in.

An MCP server lets an assistant call a service's tools. With MCP Apps, it doesn't only return data: it can send a piece of its own interactive screen into the chat.

MCP Apps: an anniversary planned in one chat

Each service sends its own screen into the chat

  1. YouAsk"Plan something for our anniversary on the 14th."
  2. The assistantAnswersYou're free after 7 pm that day, and there's a show at 8.
  3. Calendar, an MCP AppIts sliceSaturday the 14th, free from 19:00.
  4. Tickets, an MCP AppIts seat mapTwo seats in row B, and a Book button.

You never leave the assistant.

An illustration of MCP Apps, not a real product.

Everybody wins there. Ticketmaster keeps its brand, and you already know how to use its seat map. The assistant doesn't have to invent one, because the domain expert ships its own.

His example is planning an anniversary. Instead of 20 tabs, the assistant shows you a slice of Google Calendar, then a slice of Amazon, and you never leave the chat.

Apps no longer own the whole user journey, only the last mile. He calls this the nearly headless web.

MCP Apps started less than a year ago as MCP-UI, which he built with Ido Salomon. Anthropic and OpenAI then worked with them to turn it into the MCP Apps spec, released in January.

Every category gets its own assistant

Liad sees the change reach one category after another. Coding agents already changed how dev tools get picked. If your agent reaches for Supabase, MongoDB or Sentry, their business goes up, and if it doesn't, it goes down.

Chat apps like Claude, ChatGPT and Gemini are doing the same to B2B SaaS: people use Salesforce through their chat app.

The next wave is consumer assistants going mainstream, and it hits ten times more companies, the Walmarts and Targets. People stop browsing a store and ask their assistant to buy the thing. The assistant doesn't much care which store it comes from.

Three waves of assistants

One category after another, and e-commerce is next

  1. HappeningCoding agentsDev tools, picked by the agent or not picked at all.
  2. HappeningClaude, ChatGPT, GeminiB2B SaaS: Salesforce, used from inside a chat.
  3. NextPersonal assistantsConsumer apps and e-commerce: ten times more companies.
Each wave of assistants becomes the entry point for a whole category. Redrawn from Liad's slide.

Two kinds of user experience

He splits user experience in two.

Liad's equation: UX = AX + UAX

User experience splits in two, and both halves count

The agent sideAXHow an agent experiences your product.
The human sideUAXHow a human experiences that agent.

Headless, but with a human eye at the end.

From Liad's slide.

There's always a human at the end of the chain, so both halves count. It also means being ready for agents on every front at once.

You still need a website, now visited by people and by browser agents. You also need an MCP endpoint, visited by the user's own AI agent or by the app's own agent working for them.

Agent ready, on all fronts

Two surfaces, four kinds of visitors

Human UIYour website
  • You, in a browser
  • A browser agent
MCPYour MCP endpoint
  • Your own AI agent
  • The app's own agent, working for you
Redrawn from Liad's "Agent ready, on all fronts" slide.

Agents have no brand loyalty

My favourite story from the talk is about an analytics tool. His team wanted Mixpanel, which they'd used for ten years.

Claude Code, Anthropic's coding agent, kept pushing PostHog because its MCP server and API were easier to work with. They went with PostHog.

Liad's team picks an analytics tool

Ten years of Mixpanel lost to a better MCP server

What the team wantedMixpanel
  • Ten years of using it
  • Ranks higher on Google
What Claude Code pickedPostHog
  • A better MCP server
  • An easier API to work with
  • The one that shipped
As Liad told it.

That means a decade of UX and developer experience counted for less than an agent's smoother time elsewhere. And Mixpanel ranks higher on Google.

That part stays with me. I work on e-commerce integrations for a living, and that next wave aims right at my world. If people ask an assistant to buy something instead of browsing a store, the store's offering to agents is its storefront.

What his data says about my site

Liad's company, Ora, measures how ready websites are for agents. They score it as a loop of five checks, in the order an agent runs into you. Auth weighs the most: 30 points out of 100.

How Ora scores agent readiness, out of 100

Five checks in a loop, and auth weighs the most

  1. 15 pointsDiscoveryCan agents find you?
  2. 20 pointsIdentityDo agents understand you?
  3. 30 pointsAuth and accessCan agents authenticate?
  4. 20 pointsIntegrationCan agents do the work?
  5. 15 pointsUser experienceCan humans use you when needed?

Then back to step 1, with the user's next intent

Redrawn from Liad's slide on how Ora scores agent readiness.

That first box holds the finding about llms.txt, a text file that sums up a site for AI models. They scanned tens of thousands of sites, and about 50% publish an llms.txt.

Then they ran thousands of real agent sessions against those sites. The agents didn't look for llms.txt. They went straight to the docs and the homepage, and only read llms.txt when the docs told them to.

Where the agents actually went

Agents go to the homepage and the docs, not llms.txt

  1. HomepageWhere the agent lands.
  2. DocsIt goes straight to them.
  3. llms.txtRead only when the docs point to it.

Yet about 50% of the sites Ora scanned publish an llms.txt.

Ora's numbers as Liad gave them in the talk: tens of thousands of sites scanned, thousands of agent runs.

So I checked mine. heybrahim.com has an llms.txt, an llms-full.txt, a profile.json and an MCP server at api.heybrahim.com/mcp. Here's the route an agent has to take to find that server:

heybrahim.com, 27 September

No catalog, so my MCP server sits two hops deep

  1. ai-catalog.json404, the file doesn't exist.
  2. HomepageNo URL, just footer links.
  3. AI page, notes, llms.txtThe URL is here, one click past the homepage.
  4. MCP serverapi.heybrahim.com/mcp, two hops deep.
My own site, checked on 27 September 2026. The URL is on three pages, and the homepage isn't one of them.

The homepage, where agents actually land, only has small footer links: llms.txt, profile.json and one labelled "MCP" that goes to another page. None of them shows the URL, and profile.json doesn't have it either. The file that states it best is the one his data says agents skip.

$ curl -sI https://heybrahim.com/.well-known/ai-catalog.json | head -1
HTTP/2 404

His fix targets exactly that 404. He showed two emerging standards that build on each other.

The first is a catalog file at /.well-known/ai-catalog.json, listing every agent entry point on your domain: MCP servers, OpenAPI, GraphQL, A2A (agent-to-agent), whatever. An agent that lands on your domain doesn't need to read your docs to find the MCP URL.

The catalog still needs the agent to reach your domain first, and today that means web search. Agentic Resource Discovery (ARD) fills that gap.

It's a standard for directories. The agent asks a registry for "an email service", and the registry ranks what it knows and points at a domain. That domain's catalog does the rest.

His example was Stripe's directory. Ora runs one too, built from the catalogs of 70,000 domains they scanned.

Two standards: ARD and ai-catalog.json

The directory finds the domain, the catalog finds the entry points

  1. Your agentAsks"I need an email service."
  2. ARDA directoryRanks services for the task and points to a domain.
  3. CatalogThe domain's catalogLists every agent entry point: MCP, OpenAPI, GraphQL, A2A.

The catalog lives at /.well-known/ai-catalog.json, one per domain.

Redrawn from Liad's "Emerging standards" slide.

Google and industry partners announced the ARD specification, and AWS has written about supporting it.

Update, same day: I fixed my own 404. heybrahim.com now serves /.well-known/ard.json, the path the ARD spec has used since v0.91, and keeps ai-catalog.json as the older name from the talk.

Every page links to it with rel="ard", robots.txt has an Agentmap line, and the footer finally shows the MCP URL.

What I take from it

I don't think my site goes away, because people still read a portfolio. But I built the agent side by guessing what agents want. Liad's whole argument is to stop guessing and watch them.

Two of my next steps are already done: the catalog is published and the MCP URL is on every page. The one left is the one Liad would start with: run real agent journeys against the site and see which path they take.

Watch the part where he makes his prediction. And if you point your agent at heybrahim.com, tell me which door it used.

Plain text: websites-lose-the-front-door.md · Atom feed · All notes

Contact

Say hello.

b.bousnguar@gmail.com

SAP Commerce Cloud, MuleSoft and Salesforce integration · Nantes · EN / FR