AI Engineer World's Fair 2026
Rebuilding the web for agents — Liad Yosef, MCP Apps
Read the talk
Rebuilding the web for agents
MCP Apps brings service interfaces into assistants. Liad Yosef explains how that changes product design, why published guidance can go unread, and what agents need to find and use the web.
From a talk by Liad Yosef
At a glance
Ideas worth remembering
MCP Apps lets a service return interactive UI inside a conversation, keeping human inspection and choice within an agent-led task.
A personal assistant can carry context across services and compose the interface fragments relevant to one intent. Yosef’s anniversary flow illustrates the proposed architecture.
Agent readiness includes understanding, interaction, authentication, and payment. Discovery alone does not establish that a task can be completed.
Published guidance needs a route from the pages agents actually visit. ORA’s llms.txt observation supports that distinction, although the reported usage rate remains unclear.
Compare the same site and intent across agent harnesses: different journeys can reveal resources that one environment finds and another overlooks.
Provider catalogs describe available integrations; queryable directories help agents discover them. Successful use still requires its own observation.
Human accessibility and agent accessibility overlap where software must communicate meaning and capabilities without relying on visual presentation.
MCP Apps brings the human decision back into chat
An agent can find hotels, but a person may still want to choose one. It can retrieve a 3D model, but someone needs to inspect it. Seat selection needs a view of the venue. These are the kinds of decisions MCP Apps is meant to support: an MCP server supplies an interactive interface inside an assistant’s conversation, so automation can lead into a useful human interaction.
Liad Yosef introduces himself as MCP Apps co-creator and maintainer, ORA co-founder, and someone who built and led agentic storefronts at Shopify. His starting point is that a chat host needs access to existing services. Hotel arrangements and customer support for changing a venue seat remain work that those businesses perform; an assistant does not gain those capabilities merely by presenting a conversational interface.
What the embedded interface preserves
The server sends a piece of the provider’s UI into the chat. Yosef describes three benefits of that arrangement:
- Provider identity: The service retains its recognizable interface rather than appearing only as text or database records.
- User familiarity: A Booking.com interface gives the person a familiar indication of which service they are interacting with. Yosef treats that recognition as a source of trust.
- Host capabilities: The assistant can offer access to services without recreating the businesses behind them.
Yosef calls this the last mile of interaction. As the agent takes on more of the preceding work, the remaining interface can focus on what the person needs to inspect or decide. His embedded-app example brings Booking and AllTrails into the same conversation: separate services contribute useful information and interaction while the chat keeps the task’s context together. The interface becomes a step within the task, rather than a reason to start over in another application.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
One intent, composed from several services
Planning an anniversary exposes the coordination problem. A person opens tabs, learns Google’s interface, learns Amazon’s interface, learns Booking’s interface, and expresses parts of the same intent in each. Yosef describes two decades spent perfecting those individual flows. Even when each product works well, the person still has to connect them.
His proposed alternative breaks interfaces into useful atoms that a personal assistant can compose. A Google view establishes that the anniversary is approaching. Shopping and booking services provide ways to act on it. If Claude knows that the user prefers hotels in nature, it can select Booking’s map as the relevant interface. The assistant chooses which piece to bring into the conversation using both the task and the user’s preferences.
Yosef’s claim that he does not need 99% of Booking’s or Airbnb’s dashboard expresses the mismatch between a whole application and one task. The percentage is rhetorical, rather than a measured share of unused functionality. The concrete design move is to return the map or choice that matters now, leaving the rest of the dashboard out of the interaction.
The assistant carries the connections
In this anniversary scenario, Booking would not need to develop its own integration with the user’s calendar, and Amazon would not need to develop an integration with Booking. The assistant has the context and coordinates the service fragments. This is a proposed experience: the example explains where the integration work would live, without establishing that the complete anniversary flow already operates end to end.
Putting a separate agent-shaped text box on every website leaves much of the original coordination burden intact. The person still visits Amazon, Etsy, and Expedia and tells each assistant what they want. Yosef expects people to prefer the personal assistant that already knows them. His sharpest product preference is about continuity: the same assistant should carry the intent across services.
Establishes that an anniversary is approaching.
The personal assistant combines calendar context, service capabilities, and a relevant hotel interface. This is Yosef’s proposed workflow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why browser automation leaves the dashboard in the way
Browser and computer-use agents can operate the web that already exists. Yosef questions why that should be the default workflow. Filters, pagination, sorting, and dashboards were designed to help people navigate information under human perception constraints. Asking an agent to work through those controls keeps the same intermediate steps, even when the task could be expressed directly to the service. His faster-horse analogy challenges that choice of route.
WebMCP, as Yosef describes it, changes how an agent operates within a website. The website exposes JavaScript tools, allowing the agent to call those tools instead of taking screenshots and inferring what to do. His Gemini-and-Chrome example finds deals or buys things while the person browses. This provides a more direct way to act within the browsing experience.
The remaining question is whether the person should have to visit the website. Yosef uses Salesforce to make that objection concrete: opening a complex dashboard so an assistant can click buttons still makes the dashboard the destination. Exposing tools improves the agent’s access to actions; moving the task into a personal assistant changes where the user begins.
When the assistant becomes the entry point
Yosef’s friends who connect Jira’s MCP to their IDEs stop visiting Jira’s website. His mother already uses ChatGPT extensively; he imagines her booking a doctor’s appointment there instead of navigating a clinic’s site. During a trip to Georgia, he encounters a woman whose phone has three apps: WhatsApp, Camera, and ChatGPT. These anecdotes explain why an assistant might become a habitual starting point, although they do not measure how widely that change has spread.
Yosef initially predicts that websites and browsers will become obsolete, then qualifies the claim: they will not disappear completely. He points to Sentry’s Designing for Agents discussion as an example of product interaction expanding beyond a web application into API-first access. The supported design direction is that a website can remain useful while ceasing to be the mandatory path to a product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The nearly headless web changes who experiences the product
Yosef describes Salesforce, Cloudflare, and Sentry as moving toward headless access. The architectural point is that agents can use product capabilities without navigating the full web application. How much interface should come back depends on the task: organizing email may end with a completion message, while booking a honeymoon hotel may require a person to inspect options and choose.
He calls this the nearly headless web. The agent interacts with the service headlessly, then returns selected UI resources when human interaction matters. Product experience consequently splits into two connected concerns: how the agent understands and operates the service, and how the person experiences what the agent brings back. MCP Apps addresses that second concern without requiring every intermediate action to become a screen.
Yosef predicts that 90% will depend on agent experience; that proportion is a forecast without a defined measurement in the talk. His more concrete requirement is to serve several kinds of users: the company’s own agent, a customer’s assistant such as ChatGPT, and a person who still visits the website directly. Agent access adds another way to use the product while human browsing remains a requirement.
Discovery is the beginning of a transaction
Getting found through SEO, AEO, or GEO only begins the job. Yosef identifies additional capabilities an agent needs:
- Understanding: Determine what the business offers and whether it fits the task.
- Interaction: Learn how to use the service and perform the necessary actions.
- Authentication: Establish access to the service.
- Payment: Complete payment headlessly, rather than depend on a person navigating checkout.
Appearing in an answer does not establish that an assistant can complete any of these later steps.
His team’s analytics choice shows how integration can affect a product decision. They asked Claude Code to recommend an analytics service. It suggested PostHog. The team preferred Mixpanel, which they had used for a decade, but Claude Code continued to recommend PostHog because it judged the MCP and API easier to integrate. The team switched. This is one recommendation and purchasing decision, rather than a comparative benchmark of the services; its force comes from how little the team’s accumulated familiarity mattered to the assistant’s reasoning.
Yosef extends this into a warning about repeated friction. An agent that has to launch a browser to use a product may remember the difficulty and prefer a different product next time. The talk presents that as an expected behavior, without demonstrating it across agents. The practical risk follows from the analytics example: when an assistant both recommends a service and integrates it, ease of programmatic use can influence which product reaches the human customer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Published guidance only helps if agents find it
At ORA, Yosef’s team began evaluating websites against protocols and best practices, returning readiness scores and agent feedback and comparing results on a leaderboard. Then actual agent behavior challenged a simple checklist assumption. Almost fifty percent of the websites they tested published llms.txt, but agents generally headed to the documentation page and then the homepage.
The usage rate is unclear: Yosef first reports no use of llms.txt, then refers to forty percent using it without defining the denominator. His narrower observation is consistent enough to explain the problem: agents that reached the file found it because the documentation pointed them there. A file can exist without being on the path an agent takes. Publishing useful guidance and connecting it to likely entry points are separate tasks.
Yosef also argues that model improvements make fixed tool-writing conventions age quickly. His example contrasts descriptions of three paragraphs with descriptions of three lines becoming sufficient. That comparison does not establish an optimal length for a particular tool or model. It explains his decision to seek feedback from agents attempting real tasks, rather than treat a prescribed description format as a permanent answer.
Watch the path, then investigate the failure
ORA’s Journey takes a website, an intent, and an agent and records the path the agent follows while trying to complete the task. Yosef says the team ran these journeys tens of thousands of times. Watching the path exposes what the agent searches for and which pages it visits. If a website publishes auth.md but the agent never looks for it, the useful question becomes how the agent actually tries to find authentication information.
The comparison needs more than one harness—the environment through which an agent pursues its task. Yosef runs the same intent against the same website through multiple environments, including Claude Code and ChatGPT, and shows different journeys. He says ChatGPT finds results better in the illustrated case. That observation applies to the example, rather than establishing a general ranking. Keeping the site and intent the same makes the different paths worth investigating.
Journey also connects those paths to business questions and goals for a domain. The point is to understand how an agent tries to accomplish something the business cares about, rather than stop at a score for published files. A successful run in one environment can coexist with a missed resource or an unsuccessful path in another. Readiness therefore depends on observed use as well as the resources a provider exposes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Discovery has to find usable resources
After studying how agents use websites, Yosef returns to discovery at a different level. Search accompanied the web, app stores accompanied mobile, and feeds accompanied social platforms. What should an agent use to discover an MCP server or an openapi.json description? The object it needs may be a usable connection to a service, rather than a page describing the service.
His hypothetical Airbnb–Booking.com comparison makes the selection problem concrete. Airbnb might offer the better MCP integration while Booking.com offers the better API. Neither preference is presented as an actual evaluation of those companies. The example asks discovery to distinguish between access methods: finding the right business is insufficient if the assistant cannot find the resource that best supports its task.
Three discovery approaches, three limitations
Yosef sees different problems in existing approaches:
- Conventional web search: Human SEO and PageRank shape the results, which he considers insufficiently flexible for discovering agent resources.
- Assistant-specific registries: Closed catalogs require each provider to submit its application to the particular platform.
- A central MCP registry: Shared discovery still needs decisions about curation, governance, and which resources qualify for inclusion.
These approaches answer different questions. A ranking of pages, admission to an assistant’s catalog, and governance of a shared resource directory do not automatically provide the same discovery experience.
Yosef describes two emerging conventions for different parts of that experience. aicatalog.json describes how a website exposes its agent-facing resources. Agentic Resource Discovery, or ARD, describes how a directory exposes itself to agents. A provider catalog helps answer what connections a business offers; a directory gives an agent a way to query a collection of resources. The talk describes their intended roles without establishing broad adoption or resolving the curation questions.
From a scanned domain to a queryable connection
ORA.directory collects domains the team has scanned and exposes descriptions agents can query. In Yosef’s monday.com example, ORA generates an aicatalog.json file identifying the MCP server and API server. Vercel is another example of an entry describing available agent resources and how to access them. Yosef presents the directory as ARD-compliant, making both the collection and its resource descriptions accessible to agents.
This provides a route from discovery to a candidate integration. It does not complete the later work of authentication, payment, or task execution. Those remain separate capabilities to investigate through actual use. A catalog can tell an agent where an MCP or API server is; a journey can reveal whether the agent manages to use it for the intended business goal.
Queries for agent-facing resources.
ARD describes access to the directory; provider catalogs identify available connections. Resource discovery precedes successful use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the existing web accessible to agents
Yosef brings Journey, Directory, and the Ranker together as parts of ORA’s work, then ends with an overlap between agent readiness and human accessibility. An agent relying on nonvisual information needs signals explaining what a website is and how it works. He compares that need to the experience of people with vision disabilities: visual presentation alone cannot carry the meaning required to use the product.
The useful overlap concerns making meaning and capabilities available without depending on sight. It does not imply that every agent lacks visual capabilities—the earlier screenshot-based browsing discussion already describes another mode of access—or that an agent completing a task establishes human accessibility. Yosef’s point is that improving the signals available to one audience can help the other.
His closing goal is to make the existing web agent-accessible. MCP Apps supplies a way to return a useful interface when a human needs to choose. Observed journeys reveal which routes agents actually take. Resource descriptions help them find connections they can use. The work is to prepare services for those different routes while keeping the human interaction that the task still needs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Readiness scanning, agent journeys, and research into how agents find and use websites. The supplied page includes a Journey entry point.
Further reading
- Liad YosefReference
The speaker’s profile and writing about MCP Apps, WebMCP, and human-agent interaction.
Related talks
- MCP Apps: Extending the Frontier — Ido Salomon & Liad Yosef
Explains the embedded-interface layer in more detail, including host-to-application communication, governance, and an interactive funnel example.
- MCP-UI: Extending the Frontier — Liad Yosef and Ido Salomon, MCP Apps
Develops the communication among applications, hosts, and backends and the distribution model for interfaces inside assistants.
Read the complete timestamped transcript
- 0:12
Hi, everyone. Uh, hello, hello. So we're gonna talk a little bit about the agentic web, and more spe-specifically, what it means and how do we make the web ready for agents. Um, one disclaimer, um, I built this talk yesterday, so it might be outdated because, uh, things are moving really, really fast in this, uh, in this space. And, um, I think I need to introduce myself just to, um, to get some context. So I'm the co-creator and maintainer of a spec called MCP Apps. MCP Apps, that's the underlying
- 0:42
spec be-behind, uh, ChatGPT apps, Claude apps, Copilot, GitHub. Every chat-based app that you saw... that you see is based on the spec MCP Apps in the MCP committee. I'm also the co-founder of a company called ORA, where we research the agentic human interactions, and I built and led the agentic storefronts in Shopify. So the topic of agentic web is really close to my heart. Um, and a lit- a little bit of primer about MCP Apps, if you're not
- 1:12
familiar. Um, MCP Apps are actually... This is actually the spec that paved the way to agentic web. So MCP Apps were, were released as a spec and as, as a standard few months ago, um, with the support of, uh, Claude first as the first client, and then all clients followed. And if you play with any chat-based app and you pulled any, uh, visualization and interaction UI layer from an MCP server, you probably used MCP Apps. And the good thing about MCP Apps is
- 1:42
that everybody wins because if the servers or the providers can send UI chunks into the chats, then the apps gain their brand and identity. They get, they get to keep their UI and not being reduced to a database or just text-based, uh, information. The users gain the trust and familiarity because if you, uh, ask ChatGPT, "Hey, book some hotels for me," and you see Booking.com, then you know it's Booking.com, right? You know who you're
- 2:11
interacting with. And the host of the, the chats gain, uh, access to the world of capabilities. Um, you know, a few months ago, people ask, "Yeah, why won't, uh, OpenAI just build everything out of scratch?" But OpenAI will not negotiate, uh, deals with hotels or support, uh, users that want to change seat in a venue. Um, we need those services, and MCP Apps actually solve for this, uh, for this last mile of interaction.
- 2:41
Yeah. So, um, uh, this is the, this is the benefit, uh, that we get, and MCP Apps solved our last mile of interaction, right? So what does it mean, the last mile? Last mile is, as agents become better, as models become better, they can do things more autonomously. But we are still in the end of the chain as humans. We still need to be able to choose the hotel or to view a, a 3D model or to choose a seat at, at the venue, all those
- 3:11
last mile of interaction, and that can change. And, um, this is an example from, uh, um... Oh, sorry. Yeah. So this is from, like, uh, Claude, um, API on MCP Apps. This is how it looks like, right? So when you, um, when you're embedding apps inside chats, you get this unified experience of how UI feels inside the same context of a chat. And as you can see, in the same conversation, you get data from Booking, you get data from AllTrails, you can get data from
- 3:41
everything you, um, uh, you want to interact with, right? So this is, this is already happening. MCP Apps is already s- wi-widely supported across every, uh, chat agent, except Gemini, but that's coming. Um, and this is already hap-happening. And the interesting part is that it brings us to what we call the agentic web. So what, what is the agentic web? The agentic web is not a web of agents. Uh, it's not the web as we know it today. It's a, it's a shift.
- 4:11
It's a change. It's a, a changing in the way that we see websites and the way that we see browsers. Because up until now, we spent 20 years, two decades, perfecting this experience, meaning that if I want to somehow, um, do a project or fulfill a task or plan an anniversary, I have to open tabs in my browser, and I have to go through these tabs, and I have to convey my intent differently to each of those services, right?
- 4:41
Meaning that if I just want to plan an anniversary, then I need to learn Google's UI and Amazon's UI and Booking UI and the other Booking UI and the other Amazon UI, all that just to convey the same intent to those interfaces. And every company perfected this user flow. But we don't need to do it anymore, right? We can just take these interfaces and break them into atoms because we don't need... I don't need 99% of Booking's dashboard. I
- 5:11
don't need 99% of Air- Airbnb's dashboard. I definitely don't need Jira's dashboard. But I do want to convey my intent to those services, so why can't I let my personal assistant use that? So if I have a personal assistant, I can just take these atoms, and it composes these atoms and say, "Yeah, I see that you have an anniversary coming. This is, this is the view from Google that says that you have an anniversary coming, so I can book... I can, I can buy things for you. I can book your hotel." Now, Claude
- 5:41
knows me, so it, he knows that I prefer to book hotels in, uh, uh, in the nature, right? So it knows to pull the map from Booking. I don't need to think about it. And what Booking and Amazon and Google benefits from this is that they have this integration layer that they don't, they don't need to develop 'cause Claude has the context, um, for me, right? So Booking doesn't need to develop integration with my calendar. Amazon doesn't need to develop integration with Booking. So it's a win-win-win. This is the view that we're, uh, aiming for, and this is
- 6:11
very different from what the things are going, which is this, which is basically browsing into different services just to stare at different text boxes that ask what I want to do there. But no one is going to do that. In fu- in, in a year, no one is going to, um, browse through Amazon's agents and, and Etsy's agents and Expedia's a- agent. I don't wanna do that. I have my own personal assistant. I don't want, I don't want to use your agent. I wanna use my agent. Okay?
- 6:42
Now, if we think about it, it means that websites as the source of truth are something that's gonna go away, because why would I need the website? Why would I need to open the tab? Why would I need the information that the website is working really hard to convey to me? And the immediate response to that is that, yeah, we have browser agents. We have computer use agents. We have very smart agents or assistant that can browse the web for us, but that doesn't make sense because that, that's, that's a faster,
- 7:12
horse solution. Why would I let an agent that doesn't know anything about the human perception limitations work with, uh, filters and paginations and sorting and all of those UIs that we spent decades perfecting for us, um, just for it to fulfill its task? So Google has, uh, um... Google is very bullish on the other end of the spectrum, which is co-browsing and, and websites, and they have a protocol called, or standard called WebMCP. WebMCP says, okay, instead of the agent
- 7:42
taking screenshots of the websites and trying to figure out what's happening, let's have the website expose some tools in the website, JavaScript tools, and the agent will work with it. And you can see here an example of Gemini and Chrome that, um, buys stuff for me or, uh, finds, uh, deals for me as I browse the web, which is very nice, but it's very simple. What happens if we push Salesforce dashboard to Gemini on Chrome? Why would I want that? Why would I want to browse to Salesforce dashboard with Gemini
- 8:12
to click buttons for me in a dashboard that I don't even want to use? I mean, this is definitely not what we want. And the shift is that assistants are becoming our entry point to the web, right? We see it everywhere. Every major lab wants its app to be the everything app, and the shift is happening. And friends of mine that connect Jira's MCP to their IDEs, they don't go to Jira's website anymore, right? And my mother uses
- 8:42
ChatGPT for everything. If she could book a doctor's appointment using ChatGPT, she won't go to that clinic's websites anymore, and you have a long tail of websites that no one is going to see because it's much easier for me to connect to them using my personal assistant. So websites will become obsolete, browsers will become obsolete, and personal assistant will become our only gate to the web. And I know what it sounds like. It sounds like old men yelling at a lit- literal cloud, right? I mean, um, yeah, they're not gonna go completely obsolete, but we see
- 9:12
it with the younger generation today. My [REDACTED] goes to ChatGPT. He doesn't go to Google when he, when he wants to search for stuff. I was, uh, I was traveling to Georgia, the country in Eastern Europe, and there was an older lady there that asked me to take a picture of her, like [REDACTED], and on her phone she had three apps: WhatsApp, Camera, and ChatGPT. That's it. The shift is happening. Um, and very smart people like David Cramer from Sentry said a year ago, "I will take this bet
- 9:43
against anyone who thinks websites are going to be obsolete in 25 years." That was one year ago. Few days ago, David Cramer p- published Designing for Agents, which says, "We have to recognize that interaction with products at Sentry will no longer be exclusively through our web application, and we have to design for API first as a surface." So everything is going headless. Salesforce recently went headless, which is very important because Salesforce's main differentiator from its competitors is its UX. It's the way that it conveys
- 10:13
everything to the user. But it went headless. Cloudflare went headless. Sentry went headless. Um, this is a, a tweet by a Cloudflare CEO, uh, saying that agents traffic surpassed, uh, human traffic in the web. And we have this spectrum of interaction because if, if my agent is autonomous, I don't need this last mile of UI, right? If I have an OpenClau, I just send... and I just say, "Yeah, organize my emails." It comes back, said, "Done." Good. But if I want to book a hotel for my honeymoon, I probably need this last mile of interaction, so we call it the nearly
- 10:43
headless web, right? Uh, it's not completely headless. Um, the agents will interact with your web head- with your, um, website headlessly, but then it will bring back these UI resources for you. So user experience as we know it is being split. Now it's the agent experience of your website, plus how a user experiences the agent that experiences your website. But 90% is gonna rely on agent experiences, m- which means your website needs to be agent ready
- 11:13
for everything. It needs to be agent ready for your agent. If I'm booking, I need to make bookings that are ready for bookings agent. I need to make it ready for my customer's ChatGPT or my customer's OpenClau, and I need, I need to be ready for my human customer who doesn't have an agent but still wants to browse to booking.com, right? So I need to, to be agent ready, and what we fi- found out is that agent ready means a lot of things. So we heard a lot about AEO, SEO, GEO, how to get discovered. But discovered, discovery is
- 11:43
only the first, the first step, because once an agent knows about you, it still needs to know what you are and how to interact with you, and how to, uh, authenticate to you, and how to headlessly pay you, right? And actually, when, when we built, uh... It's an anecdote, but when we built, uh, analytics for our product, we asked Claude Code, "What's the best analytics service?" And it recommended PostHog, which is an analytics service. And we said, "No, we prefer Mixpanel," because we know Mixpanel. We worked with Mixpanel for a decade. We know how to work with it. And Claude Code insisted on PostHog because it said, "PostHog has better
- 12:13
MCP and API, and I can integrate to it better." So we don't have brand loyalty, right? We went with PostHog if that's Cl- what Claude Code recommend, but it made us think about Mixpanel, and Mixpanel spent a decade perfecting their UX and developer experience. We just left it just because Claude Code prefers PostHog, and it will always happen. Hermes, for example, if it uses your product, and it needs to spin up a browser to use your product, it will remember that, and next time it won't go to your product anymore, right? So at ORA, which is an agentic web research lab,
- 12:44
we started researching. Uh, we raised some ca- raised some capital, and we started researching what does it mean for the web to be ready for agents. And we have these, um, readiness benchmarks, which is interesting. So you can run... It's free. You can go to ora.ai. You can run any website. You get this score and benchmark according to a lot of protocols and best practices, and you have agentic feedback, so the agent actually returns the feedback about your, uh, your website. And we have
- 13:14
this leaderboard of how companies and products rank according to this benchmark, and we started mapping the web, and everything was nice. But we hit one insight or one, uh, unexpected result. We found out, uh, anyone here heard about llms.txt? llms.txt, that's like the de facto standard to be agent ready. You say, "Yeah, if your, if your website publish an llms.txt, agent know how to interact
- 13:44
with you." Um, and you have auth.md and pricing.md and X-402 and a lot of standards. And we found out that almost fifty percent of the website that we tested, that we ran, published llms.txt. But none of the agents that we ran on this website actually used llms.txt. Actually, almost all the agents went straight to the docs page, and then the homepage, and the forty percent that did use llms.txt used it only because the docs pointed out that there's a file called
- 14:13
llms.txt that they need to, to use. So then it hit us. We said, "It doesn't make a lot of sense for us as humans to define to agents what they need." No one is doing it anymore. Even OpenAI, they don't publish best practices for tools anymore because they say that every time they publish best practices, the models become better, and these practices become obsolete. Six months ago, the best practice for an MCP server was, yeah, uh, have three-paragraph description so agents will know how to interact with you, and now three lines are
- 14:43
enough. So best practices become obsolete. We need the agents to define what the agents need, right? We need agents' feedback on this website, so we built ORA's Journey. And ORA's Journey, that's a really cool... That's also free. You can go to journey.ora.ai, and you can run on any website, any intent, with any agent, and see the path of the agent as it tries to interact with the website. So for example, etia.com. Choose Claude, Claude Code,
- 15:14
and we run it on the website, and you can see in real time how the agent goes and what it tries to look for in the website. And we, we did it tens of thousands of times just to understand what agents really look for when they look... whe-when, when they try to interact with, with websites. And the cool thing is not running just one harness. It's running multiple harnesses. You see here Claude Code and Eve, which is, uh, Vercel's harness, um, and ChatGPT on the same
- 15:44
website with the same intent. Okay, so this is Claude Code. This is Haiku. This is Eve. See how different the agent journey looks like, and this is ChatGPT. So ChatGPT could, could find results better. See, you can just see the, the, the journey across, across the website, and we need to understand why. We need to understand why does it happen, why websites publish auth.md files, but agent don't look for auth.md files, and what do they look for? So in ORA,
- 16:14
um, you can actually, uh, go to any business, business question. So for any domain you have, like, business goals or, or questions, and you can see the paths that the agents are taking. And the, uh, interesting part of it is that, okay, now we know how agents interact with website. What's the next big, big milestone for ag- the agentic web? And for those of you who, uh, heard the, the previous talk, um, it's discovery, right? But it's not the discovery that we think of.
- 16:44
It's not a SEO. It's not GEO. It's not AEO. Because we have to remember that every rev- revolution came with its discovery layer, right? The web revolution came with search. Um, mobile came with app stores. Social came with feeds. What is the discovery layer for agentic resources? What is the discovery layer for MCPs? What is the discovery layer for openapi.json? What do we even look for? I mean, maybe Airbnb has a better MCP than, than Booking.com, but Booking.com has better API than Airbnb. So how do we do it?
- 17:15
Um, web search, classic web search, it's not enough because, um, it ba- it's based on human SEO and human, uh, PageRank, and it's not flexible enough. Custom registries, like per agent or per chats, they're not enough because they're closed, and they're, uh, um... and, and they require every app to sub- to submit itself to these regi- registries. And a central registry, like an MCP registry, that's not enough because who will do the curation? What's the governance model? How do we decide
- 17:45
which resource comes to that registry? There are eme- emerging standards around it. There's an aicatalog.json, which is a standard by Anthropic, OpenAI, Google, MCP, and A2A, which standardizes how a website exposes itself to agents. And there's the Agentic Resource Discovery standard, which is by all these companies and more, which is basically standardize how, uh, a discovery layer or, or a directory, uh, expose itself to agents. So we built ORA.directory, right?
- 18:15
Because we're a research lab for the agentic web, so we built this. And in ORA.directory, we take all the domains that we scanned or scanned ourselves, and we put it in a directory that agents can actually query, right? Um, we expose the aicatalog.json files, so you can see here, for example, for monday.com. You can see that we generate this JSON file that basically tells agents, "Yeah, this is the MCP server for Monday, this is the API server for monday.com," and you can just... The agent can just query that,
- 18:46
right? So for every domain, it can just goes to, go to aicatalog.json, and we expose the registry, the directory itself. So for every entry on the directory, we can, uh, we can tell the agent, "Yeah," for example, Vercel, "These are the agentic resources, um, and this is, and this is how you access them." And obviously, this directory is fully ARD or Agentic Resource Discovery compliant, so any agent can just query that directory with any, with any query, right? So this is, uh,
- 19:16
this is ORA.directory, uh, if you wanna take a look. All of it is part of the ORA multiverse: Journey, Directory, and the Ranker. And we found out some very other interesting insights. For example, being agent ready and being human accessible is very similar because LLMs, when they come to a website, they're like, um, users or people with vision disabilities. They don't see your website. They need other signals to understand how to work with your website, and making your website human accessible helps agent accessibility and vice,
- 19:46
vice versa. So to wrap up, these are MCP Apps. This is what I've been working on in the past few months, and this was the last piece for the agentic web. This actually brought the agentic web. And now agents start to roam the web, and agents need different things. They need different roads. They need different infras. But we don't want to rebuild the web for agents. We, we want to make the web agent accessible. So let's just make sure the web is prepared for when agents are coming.
- 20:19
Thank you very much.