Websites won't die, they'll stop being the front door
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.
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.
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.
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
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.
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
ShippedA 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.
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.
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:
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.
ai-catalog.jsonAnthropicOpenAIGoogleMCP
ARDGoogleMicrosoftNVIDIAGoDaddySalesforce
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