AI Engineer World's Fair 2026
Computer-use models will agentify the web, not APIs
Read the talk
Computer-use models will agentify the long tail of the web
Flight search already has APIs. Restaurant menus and school procurement records reveal why browser vision may supply the task interface the rest of the web lacks.
From a talk by Dhruv Batra
Before you start: Basic familiarity with APIs, HTML and JavaScript will help you follow the browser examples.
How will agents act on a web built for people?
If agents are going to read, click and buy on our behalf, how will they operate on a web that is already hostile to automated traffic? The usual answer is that websites will expose APIs through protocols: MCP servers, WebMCP and a growing collection of payment interfaces. Dhruv Batra accepts the prospect of agents driving web activity, but challenges that implementation assumption. Popular services may provide APIs; the long tail cannot be assumed to follow.
Consider a request for business-class flights from Miami to Palma de Mallorca in August. Sending a computer-use agent to click through flights.google.com is an unnecessarily indirect route when flight aggregators already accept parameters and return JSON. An LLM can call a tool against that structured interface. The buttons exist to produce the request behind the scenes; when the appropriate API already exists, use it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A gluten-free query becomes a visual navigation task
Now ask whether a restaurant has gluten-free menu items. The desired interface seems equally straightforward: supply a dietary filter and receive matching dishes. But that assumes the restaurant—or an aggregator—has already made its menu available as structured, queryable data. Batra walks through three restaurant sites to show what the agent actually encounters.
| Example | What the site provides | What the agent needs |
|---|---|---|
| Easy | German menu text and prices | Text extraction and language understanding |
| Medium | A Menu button leading to a selectable-text PDF | Navigation and PDF reading |
| Hard | A Spanish site leading to a gallery of pixelated menu JPEGs | Visual navigation and image reading |
The progression matters. On the first site, the language is not a fundamental obstacle for a multilingual model. On the second, the information remains text, but the agent must discover and open the document. On the third, a photograph-heavy page offers no obvious text menu until the visitor recognizes Nuestra carta, opens it and then opens individual gallery images. Batra reports that ChatGPT struggles with OCR on the downloaded menu JPEGs. A simple dietary question has become a sequence of navigation and perception problems before any filtering can begin.
The missing endpoint is therefore not just an omitted convenience. It presupposes a clean data representation that the restaurant may never have created. The public interface is the collection of pages, documents and images a person can work through.
Suggest correction
School procurement exposes the institutional bottleneck
The enterprise version is a supplier asking whether a school district is currently procuring laptops. Given mydistrict.gov, the ideal interface would accept status=open and topic=laptop. Batra estimates a potential search space of 15,000–20,000 US school districts, though that range depends on whether regular districts or the broader category of education agencies is intended.
The demonstrations again become progressively harder. Ithaca Public Schools presents a portal that the agent must navigate. Another district places the relevant material under Finance → Purchasing → Current Solicitations, where the destination is a scanned PDF without extractable text. In the hardest example, obtaining information requires a Freedom of Information Act request. Staff scan the request email, upload it to Google Drive and attach the relevant PDFs. Expecting that institution to supply an MCP server overlooks the workflow it actually operates.
Batra uses roughly 200 million active websites and around a billion total websites as scale estimates. More consequential than the precise count is the ownership boundary. A coding agent might generate an API if given unrestricted access to an institution's software, but generating the code does not obtain that access, authorize deployment or change the institution's processes. Organizations still faxing documents will not all replace their infrastructure on an AI development schedule. The bottleneck is institutional adoption as well as software construction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The answer may not exist as page text
If the infrastructure will not change, why not point a coding agent at the HTML? A browser is software, so the information it displays must come from somewhere. The first complication is timing. In Batra's NBA.com example, a Minnesota Timberwolves–Brooklyn Nets page visibly shows a final score of 125–109. The initial HTML contains an empty placeholder. After a network-dependent delay, an asynchronous request returns JSON containing the score. Reading only the initial response misses the answer. Adding a wait seems like a reasonable repair—but the next example is not merely about waiting.
The next question is whether a 25mm osmium cube is in stock. A product dropdown shows three unavailable options and one available option. A human can interpret grayed-out, unclickable choices as unavailable, even when the interface does not explicitly label the remaining choice “in stock.” Yet the HTML option selector does not contain the availability text the visitor expects to find.
Batra describes product-count JSON containing a quantity value, followed by a separate rendering script that disables and grays out options whose quantity is zero. His account has the browser fetch that JSON; the companion explanation instead places it in the initial HTML and specifies a 25.4mm cube. Either placement leaves the central mechanism intact: availability is computed from data and expressed through rendered state, rather than supplied as a literal answer in the selector text.
A small JavaScript example captures that rendering rule. Here, a zero quantity makes the option unselectable without adding any “sold out” text:
javascript
const stock = { label: "25mm osmium cube", quantity: 0 };
const select = document.createElement("select");
const option = new Option(stock.label, stock.label);
option.disabled = stock.quantity === 0;
option.style.color = option.disabled ? "#888" : "#111";
select.append(option);
document.body.append(select);
Searching option.textContent would find the product name, not the stock answer. Recovering the visible meaning requires understanding the data, the rendering rule and the resulting interface. Batra compares the browser to a game engine: predicting its pixels from source code requires reconstructing the computation that produces them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Screenshots provide a general interface
The web was built for human eyes. Its rendered interface is where text, images, scripts and interaction state come together for the intended consumer. Batra calls this a bitter lesson for web agents: accumulating website-specific extraction rules and scaffolding does not provide the same generality as interpreting the interface itself. Vision gives the agent access to the representation that website builders already maintain for people.
The first version of Navigator, released in November of the preceding year, used screenshots as inputs and button clicks and scrolls as outputs. Its discount-code demonstration turns a natural-language claim into a browser task. The code may apply only to a particular product, within certain dates or above a minimum cart value. Those conditions determine the interaction the agent must perform.
The validation procedure follows the same route a shopper would take:
- Find the product described by the offer.
- Add the eligible product to the cart, satisfying any minimum cart requirement.
- Apply the discount code.
- Inspect the resulting price to check whether the claimed 22% reduction was applied.
The percentage is the offer being tested, not a measured success rate. Batra describes these tasks as taking roughly 20–40 interaction steps, depending on complexity. The visual interface makes the task expressible even without a dedicated validation API; it does not eliminate practical accuracy gaps. His claim that the model can accomplish browser tasks is explicitly an in-principle claim.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use code for action and pixels for feedback
Needing vision does not require imitating every human action. In the next model demonstration, a Chrome extension displays an Execute JS action while multiple form fields are filled together. The model has generated a function to perform the updates instead of clicking and typing into each field separately. The browser can execute code, so an agent can use that capability whenever it is the efficient way to act.
Choose the action method for the task, then inspect the rendered result. The model can read code, write JavaScript or click a control, and use the next screenshot to check what happened. Batra describes this as a “sort of formal verification” system, but the mechanism shown is visual outcome checking, not mathematical proof. Successful execution of a function is not itself evidence that the intended form state appeared; the screenshot supplies that feedback.
The same browser capability can be replicated. An orchestrator launches multiple Navigators, each in its own cloud sandbox, to work on different websites simultaneously. The advantage over a human operator comes from parallel execution across browser instances, not from requiring one agent to finish every interaction faster than a person.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When the benchmark becomes too easy
Are computer-use models reliable enough to make this useful? Batra answers with Online-Mind2Web, showing model release dates against human-evaluated task success. Evaluators inspect the trajectories and judge whether the tasks were completed correctly. This measures outcomes across browser interactions, rather than whether an isolated click was plausible.
Batra reports approximately 97% human-evaluated success for Navigator n1.5, with eight incorrect trajectories out of 300 on the evaluated Online-Mind2Web version. He describes the tasks as involving roughly 30–50 interaction steps. For him, that result is a reason to retire this version of the benchmark and build harder, longer tasks. The result belongs to that evaluated task set; the benchmark's tasks change over time, so its version matters when comparing releases.
The evaluated model also reflects the hybrid design: pixels come in, while both button clicks and code can come out. The progress claim therefore concerns a visual browser agent with multiple ways to act, not a system restricted to reproducing human mouse movements.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The economic case depends on each step
Reliability does not remove the cost of repeatedly observing a screen and taking an action. Batra acknowledges that computer-use workflows can be slow and expensive, especially when repeated across many tasks. In comparisons with Opus 4.7 and GPT-5.5 on browser-use benchmarks, he treats Navigator's small accuracy advantage as within statistical noise. The stronger practical argument is latency per step and cost per completed task.
Batra attributes the speed advantage to a smaller model footprint. For tasks involving roughly 20–30 interaction steps on the compared datasets, he cites about $0.80 versus $2.30 per task. The spoken comparison does not assign each price to a specific baseline or establish billing assumptions, so it supports the cost contrast without a precise model-by-model price ranking. Reducing the repeated cost of each interaction is what makes launching browser agents at scale more plausible.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The browser layer becomes the API
Agents can become a primary way of acting on the web without every institution rebuilding its interface for them. Batra doubts that decades of infrastructure assembled for human use will be reinvented within a few years. Yet the caller's desired abstraction remains sensible: submit a task, expressed in natural language or programmatic parameters, and receive its result.
His proposed path is to build that abstraction above the existing web. Improving models make browser interactions more reliable and less expensive. Behind the endpoint, many browser instances navigate pages, click controls and collect results; the service returns structured output to its caller. The underlying restaurant, school district or merchant need not have created a new API. Another layer of software absorbs the complexity of its existing interface.
Batra projects a future in which this work costs less than a penny per task, runs in less than 100 milliseconds and sometimes executes in the user's browser. These are forecasts, not the current measurements presented earlier. If the caller can issue a task and obtain structured data cheaply and quickly, the implementation behind that boundary becomes less important. From the caller's perspective, the browser automation service is the API.
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
The original Navigator launch, explaining screenshot-driven browser actions, training and evaluations.
Hybrid visual and JavaScript browser interaction, benchmark comparisons, and a July 2026 evaluation addendum.
Official benchmark repository with tasks, evaluation instructions and task-update history.
Further reading
Yutori's explanation of visual browser interaction, including the basketball-score and osmium-stock examples.
The paper introducing Online-Mind2Web and examining how automatic web-agent evaluation compares with human judgment.
Integration guidance for supplying screenshots and action history and handling Navigator's predicted browser actions.
Read the complete timestamped transcript
- 0:00
[upbeat music] Um, welcome. Let's get started. So my name is Dhruv Batra.
- 0:17
I want to talk to you about an argument. There's an argument online that says, roughly speaking, AI agents will be the drivers of actions on the web, not humans.
- 0:28
That there will be more agents clicking buttons, reading things, buying things for us than human eyeballs on the web. Um, you drive one step deeper into the argument, and you ask, how will this happen?
- 0:40
Because today, the web is extremely hostile to automated traffic. And the answer usually is, the web will be agentified. Um, you drive one step deeper into what does that mean and how will that happen?
- 0:55
And the answer usually is with APIs that agents will call via some set of protocols, and the set of protocols grows over time. It was initially supposed to be MCP servers, then WebMCP, and for payments, there are twenty different competing protocols, and, you know, every single company wants to introduce their own protocol along the way.
- 1:15
But okay, there will be APIs is the, is the argument. My claim today and argument, and what I hope to convince you today, is that this last bit is wrong.
- 1:24
I think the first two I generally agree with. This last bit that suddenly the web will provide you APIs for accessing things is, is just delusional. And my claim is computer-use agents and computer-use models will agentify the web, not APIs, and more specifically, the long tail of the web.
- 1:44
Um, the head of the distribution, the most popular website perhaps will give you the API, but the long tail will not. Um, and the story starts, uh, usually with these sorts of use cases.
- 1:56
I, I agree that they also frustrate me. When people show a use case of, "Find me business class flights from Miami to Palma de Mallorca for August," and somehow they expect that behind the scenes there will be a computer-use agent clicking buttons on flights.google.com.
- 2:11
I find this example... This is my own example. I, I'm not dunking on anybody else. I find this example bizarre. Why would you possibly do it this way? Aren't you aware that there are already aggregators?
- 2:23
You send them a variable, they will send you a JSON. Your LLMs can do tool calling. Why would you click buttons? The purpose of those clicking buttons is to generate this behind the scenes.
- 2:34
So we're on the same page there. The next step usually is, okay, let's roll this out to some other case. Um, I want to know, does my favorite restaurant or does this restaurant have gluten-free items on the restaurant's menu?
- 2:50
And so I assume that there's going to be a similar endpoint somewhere for that restaurant website or via an aggregator... Oops.
- 3:03
Um, that accepts a query that I can filter through, where I can ask for, "Give me your menu items that are gluten free." Um, I want to, for those of you who can already see, I want to rid you of the delusion that such an endpoint exists.
- 3:20
Uh, and I want to show you just for the sake of, you know, being on the same page, what do restaurant pages look like. Um, there are three that are on the screen.
- 3:29
This is the first one. This is what we imagine a prototypical... This is easy mode. You go to a webpage, there's no API, but at least it's text. It's in German, sure.
- 3:40
A different part of the world. Models can speak languages. I see text and I see pricings. Maybe this is easily scrapable. Okay. This is easy mode. The medium mode is a, a, a, a page like this, where of course the thing that you're looking for is slightly hidden away.
- 3:59
You press the Menu button, it actually takes you to a PDF. Okay, fine. If your agent has to do this, it needs a PDF reader mode. Fine. Like, you know, I can highlight these.
- 4:10
Okay, so this is at least text. No problem. Like, you know, I will dump this into ChatGPT or whatever, and it'll do it. Here's the hard mode. This is what a hard mode website for a restaurant looks like, where it's just pictures of the people who created the restaurant, um, of where they're located, of menu items, and
- 4:35
you're like, "Where is the menu?" Uh, does anybody speak Spanish?
- 4:40
Nuestra carta. Si? Okay. Let's, let's check. That's our menu. Um, you click there. Oh my God, these are... What am I staring at? Okay, uh, you click on it.
- 4:52
Oh, it's a gallery of, of individual... What is this? This is a, this is a pixelated... This is... There's no text here.
- 5:02
I am looking at JPEGs embedded in a gallery which contain the PDF items. You download this, and you put it into ChatGPT, and it's having str- it's struggling doing OCR on this thing.
- 5:15
Okay, so this is what the web looks like. You're telling me this will give you an API endpoint that you can pass gluten-free items, and it'll tell you what that is.
- 5:28
That's an example number one. Let's to- take a look at another examples. Uh, this is much more, you know, enterprise focused. Um, um, I am a business. I want to sell to a school district.
- 5:42
There's about fifteen to twenty thousand school districts in the US, and I want to ask the question, is this school district where I give you, you know, mydistrict.gov, is this school district procuring a laptop right now, right?
- 5:56
It's a simple question, and I want a similar endpoint. I want to say RFP status open and topic laptop.
- 6:04
And you think this will exist. Uh, let me tell you what these websites look like. Again, um, this is what easy mode looks like. This is, you know, Ithaca Public Schools.
- 6:18
Um, okay, there's some portal. Um, maybe there's, you know, uh, some, you know, enrollment is maybe the wrong place to go. This is what slightly harder mode looks like.
- 6:29
Um, this is a different public school. You look at the menu. Under finance, there's purchasing. Under purchasing, there's certain solicitations. Um, scan PDF again. Okay, very nice. Uh, so no text in here, but this is how they tell you about what they have, have purchased.
- 6:49
Um, and for ultimate boss level, I want to show you a different school district where in order to find information, you have to file a request for access of infor- or information under Freedom of Information Act.
- 7:06
And then what they do is they scan your email that you sent to them,
- 7:11
and they will scan that email, put it on a Google Drive, and then attach PDFs associated with your request. These are the people you're telling me will give you an MCP server? [laughs]
- 7:25
The, the amount of l- [laughs] delusion here is off the chart. Like,
- 7:31
if there was ever a time to, to say go touch grass, like [laughs] I think this is it. Okay. Uh, so this is what...
- 7:45
My claim here is that the web, we forget, is massive. It is extremely big. The, the number of websites are out there, uh, somewhat, you know, the active websites are somewhere two hundred million.
- 7:57
The total number of websites are sitting in a, in a billion. Infrastructure changes very slowly. Um, you can imagine as an engineer, you know, getting unfettered access to software systems and letting your favorite coding agent rip and generate an API endpoint.
- 8:16
Even if that technological problem is solved, which I agree seems like on a horizon it should eventually be solved, you're not going to get unfettered access to these institutions, and these institutions change very slowly.
- 8:28
There are still places that are faxing each other. You're, you're not going to be able to suddenly change this overnight.
- 8:35
Okay. So at this point of time, you might be thinking, "Fine. I'm stuck with the infra as it is. Um, so there's not going to be APIs available, but I have coding agents.
- 8:45
Why don't I just throw them at the HTML? There is, after all, if the browser is doing it, it's a piece of code, my coding agent should be able to do it as well."
- 8:55
Fair, fair point. I, you know, I also thought this way two years ago. Let me tell you what, what the web actually looks like. Um,
- 9:04
if I ask you a question, what was the final score of this game between Minnesota Timberwolves and the Brooklyn Nets? Here's what the webpage looks like. This is a modern website.
- 9:14
You know, it's NBA.com. You and I can see the score, 125 versus 109. Okay. Uh, behind the scenes, when you actually load the page and read it, this is what initially gets loaded.
- 9:28
There's an empty placeholder initially, and you wait a few hundred milliseconds to a few seconds, depending on your network connection, and your browser makes an asynchronous call later to fetch the information.
- 9:41
So the browser makes a call to an endpoint, uh, that it's extracting that information from. That endpoint responds with a JSON that contains the answer. If you just read the HTML when you load it, the answer is not in the HTML, and so your, your chatbot doesn't have access to that either.
- 10:00
So okay, you go, "Fine. These are just details. I just have to add some waits and sleeps and sure." Okay, fair enough. I will take you to another example.
- 10:09
Um, I ask you the question on a product webpage: Is the 25mm osmium cube in stock or out of stock? You're on a, on this product website. Um, you scroll down.
- 10:19
There is a dropdown. Uh, that dropdown is telling you and I as humans, you know, three things are sold out. One thing is in stock, even though it doesn't actually say in stock, like there's no text there that says in stock.
- 10:31
But you understand that grayed out means sold out, and, you know, sometimes the sold out won't actually be there as a text. Sometimes it'll just be unclickable grayed out.
- 10:40
Okay, surely this information must be in the code somewhere. You go and read the HTML, and it turns out there is an option selector. It actually doesn't say any of the things that I'm seeing on screen.
- 10:51
It doesn't say sold out. It doesn't say available. So what's going on? Uh, turns out behind the scenes, uh, the browser makes a call, gets a JSON object, which is the variable, which is product count.
- 11:05
That contains a variable called quantity. That quantity is, you know, 10 sometimes, zero sometimes. That's just, you know, how many things can the back end support right now. Some of those quantities are zero, and there's a different rendering script that anytime there's zero, grays it out and makes it unclickable.
- 11:24
Fundamentally, what is happening here is this information that you are seeing on screen is not written somewhere as pure text. It is calculated. It is rendered. Um, and for people who work in the browser industry, they understand this.
- 11:40
But, you know, often people who are coming from an AI background like me, uh, we didn't al-al-always understand this. The browser is a rendering engine. You are seeing pixels on screen.
- 11:52
It's... Think of it as a game engine. Um, and you're asking, "Can I not read the source code of the game and predict exactly what the pixels are going to be?"
- 12:00
Well, yes, eventually, but right now you're asking for an exact inversion of that process.
- 12:08
Fundamentally, the web [chuckles] was built for human eyes. Pixels are the source of the truth because the consumers of the websites are humans. That is what it was built for.
- 12:20
And so there is a implication here that we have to, we have to grapple with, which is machines will need vision to operate those things because the web world was built for, for human consumption.
- 12:31
Um, in a way, this is the bitter lesson, uh, for web agents, that the more you end up writing scaffolds around existing websites, the-- it doesn't actually generalize to the long tail of the web.
- 12:44
The thing that generalizes is the thing that it was designed for, which is the most general solution, just pixels in.
- 12:53
This is what, um, you know, we and some others in the, in the area have been working on. Um, we have a model called Navigator. Um, the first version of the model went out in November last year.
- 13:05
The first version acted purely like a human. Screenshot in, button clicks, and scrolls out. Um, I will tell you in a second, that is not where you should settle on, but it is a general solution.
- 13:16
It lets you do things like this. Um, I give you an e-commerce website, and I tell you, "There is this discount code. Please go-- The discount code is applicable under certain constraints.
- 13:27
Maybe it's only on a product, and it's only on a certain set of dates. Maybe it's only, um, with this minimum cart threshold." I describe that in natural language, and I tell you, "Tell me if this discount code is valid or not."
- 13:38
There is no API for this. The reason-- The way to do it is just like a human can. You go to that website, you find the product that is described, you add it to cart, you apply the discount code, and you check whether the claim of twenty-two percent off was met or not.
- 13:55
And that is, you know, screenshot in, button click out. This trajectory took, you know, twenty, thirty, forty steps, depending on the sophistication of the task. If you can do it on your browser, uh, this model can accomplish it in principle.
- 14:10
In practice, of course, there are accuracy gaps and so on, but in principle, this task is solvable, whereas in a lot of earlier cases, even in principle, that task may not be solvable.
- 14:23
So my claim is the web was built for human eyes. Machines will need vision, but of course, they do not need to be limited to human ways. Just because for the long tail you need to have a capability does not mean that is the only way you should do it.
- 14:36
Um, here is an example showing that. The next version of the model that we trained can also write JavaScript on demand. So this is a Chrome extension. On the right, you see an action that says, "Execute JS, value default, text select."
- 14:50
On the left, you saw that the model filled out multiple form fields simultaneously. The reason why it could do that is because it wrote a little bit of a function.
- 14:59
It can read the code when necessary. It can write code when necessary, because the browser, after all, is an engine that can execute code. But it has a s-sort of formal verification system built in.
- 15:11
It, it is seeing the screenshot. That is the source of the truth, so it knows whether it succeeded or not. So click buttons when you have to, write code when you have to, and look at the result, uh, through pixels, because that is the, that is the source of co-- of truth.
- 15:26
And of course, because these things are, are machines, you can string them into multi-agent systems. So you can have an orchestrator that is launching multiple navigators in parallel, each with a cloud, cloud sandbox instance.
- 15:38
They are clicking buttons on multiple websites. So you can accomplish things that would be s-superhuman, because no human would be able to parallelize over that many instances.
- 15:49
Um, around here, usually, you know, in this flow of an argument is when people start asking, "Are computer-use models actually good enough, uh, for these tasks?" Um, there's actually a perception online, uh, that, um, it's not clear whether progress on computer use has been fast, and there are questions about why has progress been slow.
- 16:08
That's not the reality I'm seeing, and that's not the reality that the numbers back up. Um, this is a popular benchmark, um, Online Mind2Web. No benchmark is perfect. The point isn't, uh, that this is the, the right solution.
- 16:24
But on the X-axis are re-- are release times of different models, on the Y-axis is performance, which is human evaled on, on this. So a human went in, looked at the trajectory, decided whether it was correct or not.
- 16:36
And basically, this particular version of the benchmark is saturated. The, the last-- the w-- model that we just released, Navigator n1.5, is sitting at ninety-seven percent human eval. Eight trajectories out of three hundred are incorrect.
- 16:48
At this point of time, you should just retire the benchmark, build something harder. There's about, you know, thirty to fifty steps of interaction that are happening. The next step is to go for something larger.
- 16:57
So at least in numbers, what I'm seeing, we're seeing steady progress in computer-use agents becoming-- being able to do more and more things. And this is the model that I showed, pixels in, button clicks, and code out.
- 17:11
Around this time usually is when people start asking questions. "Okay, so they're getting better, but aren't these things slow? 'Cause after all, you're looking at a screen, you're gen-- you're clicking a button, there are lots of buttons to click, and, you know, these things are expensive if you're running them for hundreds of, of things."
- 17:28
Um, that claim, I think, is largely true. There is some truth to it. Um, but I think people forget how, how much you can optimize these things out. Um, so this is our results compared to the frontier models.
- 17:43
Opus 4.7, GPT 5.5 on a couple of browser use benchmarks. Um, we're slightly better, but I think that's within statistical, uh, noise in terms of accuracy. That improvement I wouldn't beat the drum on.
- 17:57
What I would emphasize is latency per step and cost per task. In terms of latency, this is a smaller footprint model. That's why it's a lot faster than some of the trillion parameter plus models, and there are corresponding cost savings.
- 18:11
So if you have something like on these datasets, something like twenty, thirty steps of interaction, you're looking at eighty cents per task versus two dollar thirty, and that makes a big difference.
- 18:21
And so the models are getting cheaper, uh, in that sense, and you can launch them at, at scale.
- 18:28
Um, so hopefully at a, at a high level, I've sort of convinced you that there is something off with this argument. You know, this is where, where what my goal was.
- 18:38
This is where I started. AI agents are going to be the dri- primary drivers of action. Um, that seems sort of an uncontestable statement because, you know, the underlying intelligence of the models is becoming larger and larger.
- 18:53
Um, there is a certain gain of productivity and efficiency and, you know, just ease of life that you get, so it makes sense. But I think this hypothesis that suddenly overnight, thirty years of infrastructure that was built layer upon layer for human consumption will in what, two, five, ten years be reinvented is, I think, a, a fantasy.
- 19:17
Um, but, but this is ultimately what you want, right? Ultimately, you want an endpoint that, um, you know, some higher level entity can go to and I say, "I want you to do X."
- 19:30
There is some task, maybe I give you, uh, that task description in natural language. Maybe I have some programmatic description with parameters, and there's, you know, some endpoint I should be able to do it.
- 19:41
So how will the web be agentified? My answer is just extrapolate this trend. This is where we stand today. Accuracies are getting higher, benchmarks are falling, latencies are getting smaller, costs are falling.
- 19:55
And that trend, I think, will continue. And the way we will agentify the web, [scoffs] and in, in, in some sense, this is depressing, but this is true, we will just pile on another layer of mess on top of the mess that the web is.
- 20:10
Which i- which is to say, you know, you will issue a task. Behind the scenes, there will be hundreds of browsers that are pretending, uh, and clicking buttons just like humans would.
- 20:21
Um, and they will give you a result in a structured format. It will cost less than a penny. It will run in your browser sometimes. It will, you know, run in less than a hundred milliseconds.
- 20:33
And at some point you will say, "Yeah, that's an API. Like, why do I care?" And that's how we'll, we'll agentify the web. So thank you. [clapping] [outro jingle]