1. Introduction: The Web Won't Hold Still
If you've built a web agent recently, you know the failure pattern. You give it a task like "pull every listing from this directory into a spreadsheet" and watch it inch forward. It reads the page. It predicts a click. It waits for the new DOM—the page structure the browser sees. It reads again, predicts again, waits again.
Then, somewhere around step 40, things fall apart. A modal pops up unexpectedly. The 'next page' button moves. The agent mistakes one element for another. Any one of these can derail the entire task. The deeper problem isn't the bad click—it's how the agent operates: look at the page, decide on one action, see what changed, then decide again. It repeats this loop endlessly, without a durable plan for completing the task from start to finish.
The field has tried several ways to make this loop more reliable. Some agents, like OpenAI's Operator and Anthropic's Computer Use, work from screenshots and interact with websites much like a human would. Others, like WebVoyager, use the page's DOM to understand available elements and decide which to interact with.
Benchmarks such as Mind2Web and WebArena have made these systems easier to compare by standardizing a set of actions: click, type, scroll, and select. Open-source tools like browser-use, Skyvern, Stagehand, and LaVague have packaged these ideas into APIs that engineers can more easily integrate into real applications. By 2026, these tools have matured significantly, with improved error handling and broader site compatibility, yet the core paradigm remains the same.
These approaches make the loop more reliable, but they don't change how it fundamentally works: the agent still takes one action at a time, waits to see the result, then decides what to do next. When the task is over, it hasn't built anything reusable—it has only completed a sequence of clicks.
Figure 1: The failure pattern: each browser step is another chance to misread the page. Whether the agent works from pixels, page elements, a fixed action menu, or a framework wrapper, four costs return: brittle actions, per-step price, stale page state, and no reusable tool at the end. (Diagram by author.)
Three years of web agents, color-coded by family. Most systems still advance one fragile action at a time. Webwright, released in May 2026, picks up the code-writing thread that CodeAct started. (Timeline by author; dates from each project's release.)
Webwright, a browser-agent framework from Microsoft Research and the University of Hong Kong, takes a different approach. Its tagline captures the idea: "A terminal is all you need for web agents."
Instead of asking the model to figure out the next click, Webwright has agents write and run code—using bash and Playwright scripts to open browsers, inspect pages, and carry out the task. The result isn't a long sequence of browser actions; it's a program engineers can inspect, rerun, modify, and reuse.
This difference matters most when the web serves as your data source: dashboards, product catalogs, search results, internal tools, JavaScript-heavy sites, and workflows you expect to run more than once. In these cases, the question isn't just whether an agent can finish the task—it's whether it should keep clicking through the browser or write a reusable program to do the work.
We'll start with the four main approaches to building web agents and the limitations they still share. Then we'll look inside Webwright: how its three core components work, how a framework of roughly a thousand lines performs on benchmarks, and what the results say about cost and reliability. Finally, we'll put the approach to work on three common scraping challenges: paginated pages, JavaScript-rendered content, and infinite-scroll feeds.