Brahim Bousnguar

Notes

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

By · · 6 min read

Websites aren't going away. They're losing their job as the front door. That's the claim Liad Yosef, co-creator of MCP Apps, made at AGNTCon + MCPCon Europe: personal assistants become the main entry point to the web, and the website becomes one surface among several.

I've spent the last two weeks making this site readable by agents, so that line stopped me. Then his research data hit my own setup even harder.

Who walks through the front door Today you open a browser tab for each business and go in through its website. In the agentic web your assistant calls each business's MCP server directly, and only a small piece of branded interface, like a seat map, comes back to you. you learn every menu calls, no clicking seat map comes back You Browsera tab per business Your assistantalready knows what you want Travel Shop Tickets webMCP webMCP webMCP
Today: every business is a website. You open a tab for each one and learn its menus just to say what you want. Agentic web: your assistant calls each business behind the scenes. The website is still there, it's just not the way in. Only the last mile, like a seat map, comes back to you as UI. Based on Liad Yosef's MCP Apps and the agentic web, AGNTCon + MCPCon Europe 2026. Switch the tabs.

What he actually said

The talk is MCP Apps and the agentic web, 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 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 aiming at agents first (a year after its CPO bet him that websites would still be around in 25 years), Salesforce going headless, DoorDash shipping a CLI. He also cited Cloudflare saying bot traffic passed human traffic faster than expected.

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

This was the part that made it click 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 express that intent to the business.

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

What's left is what he calls the last mile. Some things are hard to do in text: picking a seat in a venue, checking a calendar. That's where MCP Apps come in. An MCP server doesn't only return data, it can send a chunk of its own interactive UI into the chat.

An illustration of MCP Apps, not a real product: each service sends its own small piece of interface into the chat, and you never leave the assistant.

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: plan 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 stop owning the user journey. They only own 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 sat down with them to turn it into the MCP Apps spec, released in January.

Every category gets its own assistant

Liad frames who feels this first as a spectrum. 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, with people using Salesforce through their chat app.

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

Happening

Coding agents

Dev tools

Picked by the agent, or not picked at all.

Happening

Claude, ChatGPT, Gemini

B2B SaaS, productivity

Salesforce, used from inside a chat.

Next

Personal assistants

Consumer apps, e-commerce

Ten times more companies.

Each wave of assistants becomes the new entry point for a whole category. Redrawn from Liad's slide.

The new UX is AX plus UAX

He splits user experience in two.

UX=AX+UAX

AXhow an agent experiences your product

UAXhow 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. And it means being agent ready 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 Four kinds of visitors reach your product through two surfaces. A person in a browser and a browser agent use the human interface. The user's own AI agent and the app's own agent use the MCP endpoint. Yourproduct Human UI MCP You, in a browser Browser agent Your AI agent The app's agent WHO VISITS WHAT THEY USE
Two surfaces, four kinds of visitors. Redrawn from Liad's "Agent ready, on all fronts" slide.

Agents have no brand loyalty

My favourite story from the talk. When his team picked an analytics tool, they wanted Mixpanel, which they'd used for ten years. Claude Code kept pushing PostHog because its MCP server and API were easier to work with. They went with PostHog.

What the team wanted

Mixpanel

10 years of using it

ranks higher on Google

What the agent picked

PostHog

better MCP server

easier API to work with

Shipped
The analytics pick Liad's team ended up with, as he told it.

A decade of UX and developer experience, lost because an agent had a smoother time elsewhere. And Mixpanel ranks higher on Google.

That's the part I can't unsee. I work on e-commerce integrations for a living, and that next wave is aimed 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.

The stat that hit my own 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, and auth weighs the most: 30 points out of 100.

Ora's agent-readiness loop A user's intent starts a loop of five checks: discovery, 15 points, can agents find you; identity, 20 points, do agents understand you; auth and access, 30 points, can agents authenticate; integration, 20 points, can agents do the work; user experience, 15 points, can humans use you when needed. Then it returns to the next intent. A bar shows the weights out of 100, with auth the largest. Intent Discovery 15 pts Can agents find you? Identity 20 pts Do agents understand you? Auth & Access 30 pts Can agents authenticate? Integration 20 pts Can agents do the work? User Experience 15 pts Can humans use youwhen needed? WEIGHT, OUT OF 100 15Discovery 20Identity 30Auth 20Integration 15UX
The five checks an agent runs into, in order, and how much each one weighs. Redrawn from Liad's slide on how Ora scores agent readiness.

The llms.txt finding lives in that first box. 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.

Half the web publishes llms.txt, agents mostly skip it Ten squares, five filled: about half of the sites Ora scanned publish an llms.txt. Below, the path agents actually took: agent to homepage to docs. The llms.txt file hangs off the docs with a dashed line, read only when the docs point to it. SITES ORA SCANNED THAT PUBLISH LLMS.TXT ~50% WHERE THE AGENTS ACTUALLY WENT Agent Homepage Docs llms.txt read only when the docs point to it
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:

How an agent finds my MCP server An agent arriving at heybrahim.com. Its request for the ai-catalog.json file returns 404. The homepage doesn't show the MCP server's URL, only small footer links. The URL is on the AI page, the notes and llms.txt, each one click past the homepage. Agent ai-catalog.json404, doesn't exist Homepageno URL, just footer links AI page Notes llms.txt MCP serverapi.heybrahim.com/mcp 2 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 spells it out best is the one his data says they skip.

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

That 404 is the fix he points to. He showed two emerging standards that stack on each other.

The first is /.well-known/ai-catalog.json: one file on your domain that lists every agent entry point you have, MCP servers, OpenAPI, GraphQL, A2A, 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", the registry ranks what it knows and points at a domain, and 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, stacked Your agent asks a directory for an email service. The directory, built on the Agentic Resource Discovery standard, ranks services and points to a domain. That domain's /.well-known/ai-catalog.json file lists its agent entry points: MCP, OpenAPI, GraphQL and A2A. Your agent "I need an email service" ARD directory A directoryranks services for the task points to a domain service.example CATALOG one per domain /.well-known/ai-catalog.jsonlists every agent entry point MCP OpenAPI GraphQL A2A

ai-catalog.jsonAnthropicOpenAIGoogleMCP

ARDGoogleMicrosoftNVIDIAGoDaddySalesforce

The directory finds the domain, the catalog finds the entry points. Redrawn from Liad's "Emerging standards" slide, with the names it showed under each standard.

Google announced the ARD specification with industry partners, 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.

Where I land

I don't think my site goes away. People still read a portfolio. But I built the agent side by guessing what agents want, and 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 the call. 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