Skip to content

Computer-use models will agentify the web, not APIs — Dhruv…

Talk by Dhruv Batra (Yutori) arguing that computer-use models, not APIs, will "agentify" the web. He contends that while agents may drive most web activity, the long tail of roughly 200 million active sites will never expose APIs. Reading HTML is also insufficient, because much page state is computed and rendered at runtime (e.g., scores loaded later as JSON, "sold out" shown as a rendered zero) rather than stored as text, making the browser like a game engine and pixels the source of truth. He calls this the bitter lesson for web agents: per-site scaffolding does not generalize. Yutori's Navigator model operates on screenshots and clicks, writes JavaScript when faster, and misses 8 of 300 trajectories on a benchmark he believes should be retired. Topics covered include restaurant menu examples, school district procurement via FOIA requests, whether computer-use models are good enough, and latency and cost per task. # Channel Identity Observations ## Video Title as Identity Evidence - **Title**: *"Computer-use models will agentify the web, not APIs — Dhruv Batra, Yutori"* — this frames the channel/video as featuring **named AI industry figures** discussing **AI agent / web interaction topics**. The speaker is identified in the title as affiliated with **Yutori**, an organization in the AI space. ## Explicit Self-Description by the Speaker - The speaker introduces himself only by first name: **"my name is Drupad"** (likely a transcription of "Dhruv" per the title). No further personal or channel self-description appears in the transcript. - He claims institutional work affiliation implicitly: **"we have a model called Navigator"** and **"the model that we just released navigator N1.5"** — indicating he speaks as a representative of a team building computer-use agents. - He self-positions as an AI-background person learning about browsers: **"often people who are coming from an AI background like me, uh we didn't always understand this."** ## Claimed Scope of the Talk/Argument - **Central thesis (explicit claim)**: **"computer use agents and computer use models will agentify the web, not APIs"** — specifically for the **"long tail of the web"**, since "the head of the distribution, the most popular website, perhaps will give you the API, but the long tail will not." - He explicitly frames the video as a persuasive argument: **"what I hope to convince you today is that this last bit is wrong"** (referring to the belief the web will provide APIs). ## Observable Demonstrated Content - **Technical demonstration of current models**: describes Navigator versions — v1 acting **"purely like a human. Screenshot in, button clicks and scrolls out"**, and a newer version that **"can also write JavaScript on demand"** via a Chrome extension. - **Benchmark and cost claims** about his own model: **"navigator N1.5 is sitting at 97% human eval"** on a Mind2Web-style benchmark, and **"80 cents per task versus $2.30"** compared to "Opus 4.7, GPT 5.5" on latency/cost. - **Extensive concrete web examples** used as evidence: restaurant menus (including a hard-mode site of **"JPEGs embedded in a gallery"**), US school district procurement sites, NBA score pages loading via async JSON calls, and a product page stock indicator. - **Multi-agent architecture demonstration**: an **"orchestrator that is launching multiple navigators in parallel each with a cloud sandbox instance."** ## Intended Audience (Observable) - A **live talk audience** is evident: **"[laughter]"**, **"[applause]"**, and audience-addressing phrasing ("for those of you who can already see"). - The audience appears to be **technically sophisticated** — assumed familiarity with **LLMs, tool calling, MCP servers, coding agents, benchmarks, and parameter counts** ("trillion parameter plus models") without explanation. - Mixed background expected: he explicitly bridges AI and browser-engineering audiences: **"for people who work in the browser industry, they understand this. But... people who are coming from an AI background like me... we didn't always understand this."** ## Tone and Presentation Style - **Argumentative, provocative, informal**: uses strong rhetoric such as **"just delusional,"** **"the amount of delusion here is off the charts,"** and **"if there was ever a time to say go touch grass... I think this is it."** - **Opinionated but self-aware**: notes his examples are his own — **"this is my own example. I've not dunked on everybody else."** ## Summary of Channel Presentation Evidence | Dimension | Evidence | |---|---| | Featured speaker | Dhruv Batra (per title), affiliated with Yutori, builder of the "Navigator" computer-use model | | Topic scope | AI agents, computer-use models, web agentification vs. APIs | | Audience | Technical AI/web practitioners in a live talk setting | | Style | Thesis-driven persuasive talk with demos, benchmarks, and rhetorical humor | | Self-description strength | Minimal personal intro; strong institutional/product claims about Navigator and Yutori's work | # Delivery Observations: Dhruv Batra — Computer-Use Models Talk ## Overall Tone - **Conversational, argumentative lecture style**: framed explicitly as a persuasive argument — "My claim today and argument and what I hope to convince you today is that this last bit is wrong." - **Blunt, colorful language** used repeatedly for rhetorical effect: - "is is just delusional" - "The the amount of delusion here is off the charts" - "I want to rid you of the delusion that such an endpoint exists" - "I think a a fantasy" ## Recurring Teaching Habits ### 1. "Easy / Medium / Hard mode" scaffolding He repeatedly grades real-world examples by difficulty, a stable pattern across both case studies: - "This is easy mode." (German restaurant menu) - "The medium mode is..." (PDF menu) - "Here's the hard mode." - Again for school districts: "This is what easy mode looks like... This is what slightly harder mode looks like... for ultimate boss level..." ### 2. Anticipating and voicing audience objections A recurring structure: raise the counterargument, concede partially, then rebut: - "So at this point of time you might be thinking, 'Fine. I'm stuck with infra as it is... But I have coding agents...' Fair fair point." - "Around here usually, you know, in this flow of an argument is when people start asking are computer use models actually good enough...?" - "Around this time usually is when people start asking questions, okay, so they're getting better, but aren't these things slow?" ### 3. Live-demo-style narration of web pages He walks through screenshots in an improvised, reactive voice, with visible surprise: - "Nuestra carta, see? 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. Oh, it's a gallery of of individual What is this?" ### 4. Repeated analogies to ground technical points - **Game engine analogy**: "Think of it as a game engine... you're asking for a 'Can I not read the source code of the game and predict exactly what the pixels are going to be?'" - **"Bitter lesson" framing**: "in a way, this is the bitter lesson uh for web agents." ### 5. Catchphrase-like claims Two phrases recur as the talk's thesis: - "the web was built for human eyes" (appears at least twice) - "pixels are the source of the truth" / "pixels in, button clicks out" ## Humor and Informal Register - Internet-slang and self-deprecating asides: - "if there was ever a time to to say go touch grass... I think this is it." (audience laughter) - "this is my own example. I I've not dunked you on everybody else." - "I will dump this into ChatGPT or whatever and it'll do it." ## Quantitative Specificity He habitually supports points with concrete numbers — website counts ("active websites are somewhere, you know, 200 million"), step counts ("20, 30, 40 steps"), cost comparisons ("80 cents per task versus $2.30"), and benchmark figures ("97% human eval. Eight trajectories out of 300 are incorrect"). ## Epistemic Honesty Markers He explicitly flags uncertainty and avoids overclaiming: - "No benchmark is perfect. The point isn't that this is the the right solution..." - "we're slightly better, but I think that's within statistical uh noise... That improvement I wouldn't beat the drum on." - "In practice, of course, there are accuracy gaps and so on, but in principle, this task is solvable." ## Closing Pattern Ends by restating the opening argument and resolving it with a wry concession: "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." ## Uncertainty Note Filler words ("um," "uh") and self-corrections are pervasive throughout the transcript, consistent with an unscripted live delivery; the structural patterns above (difficulty modes, objection-anticipation, quantified claims) are well-supported by repetition, while the humor appears consistently but is less frequent overall. # Observation Record: "Computer-use models will agentify the web, not APIs" — Dhruv Batra, Yutori ## Speaker - The talk is delivered by a single speaker who introduces himself as **"Drupad"** (curated metadata identifies the speaker as **Dhruv Batra, Yutori**). ## Core Argument The speaker presents a layered argument he intends to refute in part: 1. **Premise he agrees with:** AI agents will become the primary drivers of action on the web — more agents than human eyeballs. 2. **Premise he agrees with:** The web will therefore be "agentified." 3. **Premise he disputes:** That agentification will happen through **APIs and protocols** (MCP servers, web MCP, ~20 competing payment protocols). > "This last bit that suddenly the web will provide you APIs for accessing things is just delusional." **His counter-claim:** Computer-use agents/models will agentify the web, specifically the **long tail** — the head of the distribution may provide APIs, but the long tail will not. ## Supporting Evidence and Reasoning ### The API assumption fails on real websites - **Restaurant menu example:** He contrasts: - *Easy mode:* text-based menu (in German), scrapable. - *Medium mode:* menu button leads to a PDF. - *Hard mode:* menu exists only as pixelated JPEGs in a gallery; even OCR via ChatGPT struggles. - > "You're telling me this will give you an API endpoint that you can pass gluten-free items?" - **School district RFP example** (enterprise use case): ~15,000–20,000 US school districts; information often buried in scanned PDFs behind purchasing/solicitation menus, and in one case requires FOIA requests answered by scanning the requester's email and posting PDFs to Google Drive. - > "These are the people you're telling me will give you an MCP server?" ### Concession on flight-booking use cases - He agrees that expecting a computer-use agent to click through flight aggregators (his own example: business class flights Miami → Palma de Mallorca) is "bizarre" — aggregators already return JSON for tool-calling LLMs. ### Scale and institutional inertia - ~200 million active websites, ~1 billion total. - Even if coding agents can technically generate API endpoints, institutions won't grant access and "change very slowly" — "There are still places that are faxing each other." ### Reading HTML is not enough - **NBA score example:** the score loads via an async call after initial HTML; the answer is absent from initial HTML. - **Osmium cube stock example:** "sold out" states are *rendered* from a backend `quantity` variable by a rendering script — the text never appears in source. - **Conclusion:** The browser is a **rendering engine**; "the web was built for human eyes" and pixels are the source of truth — machines will need **vision**. - He frames this as "the bitter lesson for web agents": scaffolds don't generalize to the long tail; the general solution is **pixels in**. ## Yutori's Work: Navigator - **First version (Nov prior year):** screenshot in, button clicks/scrolls out — general solution. Example: verifying discount-code validity by simulating a 20–40 step purchase trajectory; "in principle, this task is solvable" where API approaches may not be, "in practice, of course, there are accuracy gaps." - **Next version:** can also **write JavaScript on demand** (e.g., filling multiple form fields simultaneously), while treating the screenshot as the source of truth / formal verification. - **Multi-agent orchestration:** parallel navigators in cloud sandboxes achieve "superhuman" parallelism. ## Claims on Progress, Cost, and Latency - **Perception vs. reality:** online perception is that computer-use progress is slow; he claims numbers show otherwise. - **Benchmark:** on MiniWoB-style benchmark (he says "mind to web"), Navigator N1.5 reaches **97% human eval** (8/300 trajectories incorrect) on ~30–50 step interactions; he says the benchmark version is saturated and should be retired. - **Cost/latency:** against "Opus 4.7" and "GPT 5.5" (as stated), accuracy is "slightly better... within statistical noise"; the emphasized gains are **latency per step** and **cost per task** (e.g., **80 cents vs. $2.30** at 20–30 steps) via a smaller-footprint model. - **Concession:** the claim that computer-use is slow and expensive is "largely true. There is some truth to it" — but much can be optimized out. ## Conclusion / Prediction - He calls reinventing 30 years of human-oriented web infrastructure via APIs in 2–10 years "a fantasy." - The web will be agentified by **extrapolating the trend** (rising accuracy, falling latency and cost): > "We will just pile on another layer of mess on top of the mess that the web is... hundreds of browsers that are pretending and clicking buttons just like humans would... It will cost less than a penny... run in less than 100 milliseconds. And at some point, you will say, 'Yeah, that's an API.'" # Speaker Attribution Record ## Video **Title:** Computer-use models will agentify the web, not APIs — Dhruv Batra, Yutori **Video ID:** `01a15ca7-f77f-711a-8c0d-503d5bdbb381` ## Speakers ### Primary Speaker — Presenter ("Drupad" / Dhruv Batra) - **Role:** Presenter / keynote-style talk, identified by title metadata as **Dhruv Batra of Yutori**. The speaker self-introduces only as "Drupad" (apparent transcription of "Dhruv"). - **Affiliation (from metadata):** Yutori - **Role of talk:** Argues that computer-use agents (not APIs/MCP-style protocols) will agentify the long tail of the web. Describes Yutori's **Navigator** model family (Navigator N1.5, first version released November prior year). - **Stance noted:** Self-identifies as coming "from an AI background like me" and as speaking for "we and some others in the area." ### Audience (unidentified) - Expressed via transcript markers only: `[laughter]`, `[snorts]`, `[applause]`. No individual audience members identified or quoted. ## Promotional / First-Party Content Flags - Segment describing **Navigator** model (screenshot-in / clicks-out, JavaScript execution capability, Chrome extension demo) — first-party product discussion by the speaker's own team. - Benchmark and performance claims comparing **Navigator N1.5** against frontier models ("Opus 4.7, GPT 5.5") on latency and cost (e.g., "80 cents per task versus $2.30") — **first-party promotional performance claims**, unverified in the transcript. ## Referenced Sources & Third-Party Claims - **Mind2Web benchmark** ("a popular benchmark online") — cited performance figures: 97% human eval, 8 of 300 trajectories incorrect, ~30–50 interaction steps. Speaker explicitly notes "No benchmark is perfect." - Referenced protocols/ecosystems (as topics, not endorsements): **MCP servers, web MCP**, and "20 different competing protocols" for payments. - Example websites shown (unnamed or partially named in transcript): nba.com page, German-language restaurant site, "Nuestra carta" restaurant site, Ithaca public schools site, another public school purchasing/solicitations site, a school district FOIA process via Google Drive, an osmium-cube product page. - Competing models named: **Opus 4.7**, **GPT 5.5** (as stated in transcript). - Web-scale statistics cited by speaker: ~200 million active websites, ~1 billion total websites — speaker's own framing, no cited source. ## Provenance Notes & Uncertainty - Speaker name discrepancy: transcript self-introduction ("Drupad") vs. metadata title ("Dhruv Batra, Yutori"); treated as the same person with high confidence but not independently confirmed in transcript. - Live-demo visual content (restaurant pages, school district sites, benchmark charts) is described verbally only; screenshots were not verifiable from the transcript. - **Comment availability:** Not indicated — no curated metadata supplied. - No timestamps were present in the transcript; none recorded. \>\> Um welcome. Let's get started. So, my name is Drupad 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. 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?" 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?" 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 web MCP, and for payments there are 20 different competing protocols. And you know, every single company wants to introduce their own protocol along the way. 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. 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. 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. 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 it'll be a computer use agent clicking buttons on flights.google.com. I find this example, this is my own example. I I've not dunked you on everybody else. I find this example bizarre. Why would you possibly do it this way? Aren't you aware that there are already aggregators? 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. 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? And so, I assume that there's going to be a similar endpoint somewhere for that restaurant website or via an aggregator. Oops. 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. Uh, and I want to show you just for the sake of, you know, being on the same page, what two restaurant pages look like. Um, there are three that are on the screen. This is the first one. This is what we imagine a prototypical, this is easy mode. You go to a web page, there's no API, but at least it's text. It's in German, sure. 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 uh uh uh a page like this where of course the thing that you're looking for is slightly hidden away. 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. 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 you're like, "Where is the menu? Uh does anybody speak Spanish?" Nuestra carta, see? 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. 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. 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 It's struggling doing OCR on this thing. 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. That's an example number one. Let's 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. There's about 15 to 20,000 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? It's a simple question, and I want a similar endpoint. I want to say RFP status open and topic laptop. 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. Um okay, there's some portal. Um maybe there's, you know, some, you know, enrollment is maybe the wrong place to go. This is what slightly harder mode looks like. 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. 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 info or information under Freedom of Information Act. And then what they do is they scan your email that you sent to them, 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? The the amount of delusion here is off the charts. Like Like if there was ever a time to to say go touch grass, like \>\> \[laughter\] \>\> I think this is it. Okay. Uh so, this is what My claim here is that the web we forget is massive. It is extremely big. The the number of websites out there somewhere, you know, the active websites are somewhere 200 million. 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. 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. There are still places that are faxing each other. You're you're not going to be able to suddenly change this overnight. Okay. So at this point of time you might be thinking, "Fine. I'm stuck with infra as it is. Um so there's not going to be APIs available. But I have coding agents. Why don't I just throw them at the HTML? There is after all, if the browser's doing it, it's a piece of code. My coding agent should be able to do it as well." 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 If I ask you the question, what was the final score of this game between Minnesota Timberwolves and the Brooklyn Nets? Here's what the web page looks like. This is a modern website. 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. 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. So, the browser makes a call to an endpoint that it's extracting that information from. That endpoint responds with the 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. So, okay, you go, "Fine, these are just details. I just have to add some weights and sleeps, and sure." Okay, fair enough. I will take you to another example. Um I ask you the question on a product webpage, "Is the 25-mm osmium cube in stock or out of stock?" You're on a on this product website. Um you scroll down, there is a drop down. Uh that drop down 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, 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. 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. 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. 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 they're zero, grays it out and makes it unclickable. 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. But, you know, often people who are coming from an AI background like me, uh we didn't always understand this. The browser is a rendering engine. You are seeing pixels on screen. 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?" Well, yes, eventually, but right now you're asking for an exact inversion of that process. Fundamentally, the web 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. 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 was was built for for human consumption. 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. The thing that generalizes is the thing that it was designed for, which is the most general solution, just pixels in. \>\> \[snorts\] \>\> 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. 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. 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. Maybe it's only on a product, maybe 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." 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 22% off was met or not. And that is, you know, screenshot in, button click out. This trajectory took, you know, 20, 30, 40 steps, depending on the sophistication of the task. If you can do it on your browser, uh this model can accomplish it in principle. 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. \>\> \[snorts\] \>\> 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, it does not mean that is the only way you should do it. 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. 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. 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 sort of formal verification system built in. 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 of truth. \>\> \[snorts\] \>\> 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. They are clicking buttons on multiple websites. So, you can accomplish things that would be superhuman because no human would be able to paralyze over that many instances. Um around here usually, you know, in this flow of an argument is when people start asking are computer use models actually good enough for these tasks? There's actually a perception online that it's not clear whether progress on computer use has been fast and there are questions about why has progress been slow? That's not the reality I'm seeing and that's not the reality that the numbers back up. This is a popular benchmark online mind to web. No benchmark is perfect. The point isn't that this is the the right solution, but on the x-axis are release times of different models. On the y-axis is performance which is human eval on on this. So, a human went in, looked at the trajectory, decided whether it was correct or not. And basically this particular version of the benchmark is saturated. The last the model that we just released navigator N1.5 is sitting at 97% human eval. Eight trajectories out of 300 are incorrect. At this point of time, you should just retire the benchmark, build something harder. There's about, you know, 30 to 50 steps of interaction that are happening. The next step is to go for something larger. 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. \>\> \[snorts\] \>\> Around this time usually is when people start asking questions, okay, so they're getting better, but aren't these things slow? Cuz after all, you're looking at a screen, you're 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. 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, Opus 4.7, GPT 5.5, on a couple of Brazilians 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. 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. So if you have something like on these data sets, something like 20, 30 steps of interaction, you're looking at 80 cents per task versus $2.30, and that makes a big difference. And so the models are getting cheaper uh in that sense, and you can launch them at at scale. 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, this is where I started. AI agents are going to be the dry 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. 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 30 years of infrastructure that was built layer upon layer for human consumption will, in what, two, 5, 10 years be reinvented is I think a a fantasy. Um 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. 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. 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. And that trend, I think, will continue. And the way we will agentify the web 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. Which Which is to say, you know, you will issue a task. Behind the scenes, there will be hundreds of browsers that are pretending and clicking buttons just like humans would. 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 100 milliseconds. 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. \>\> \[applause\]