The task is the same one browser-use takes on: work a website that has no API. Fill in a form, pull out a table, get to the right screen through three navigations. The bet is different, and that is the most interesting thing about the project.
browser-use hands the whole task to an agent: you describe the goal, and the agent decides what to click at every step. Stagehand v4 no longer does that. Not because it never got there - because that mode was deliberately cut out of it.
The v3 migration guide leaves no room for interpretation: agent() is gone, and nothing in v4 replaces it one-for-one. Then it explains why: agent() was built for models that could not reliably drive a browser on their own, so it wrapped the three commands in a loop and asked the model to pick one tool per step. Every one of those steps was a model call, whether the page needed judgement or not.
The project belongs to Browserbase, ships under MIT and has been alive since 24 March 2024. As of 25 August 2026 that is 24,043 stars, 1,654 forks and a commit to the main branch on the same day. This piece is about what is left after the agent was removed, how it works inside, and where the traps are laid.
What Replaced the Agent
Two approaches take its place, and the documentation states plainly which one to start with.
The first is called code mode: the model works before the run rather than inside it. You ask an assistant to write a Stagehand script, read it, correct it, and from then on run ordinary code - reproducible, diffable, with no inference per step. When the site changes, you point the assistant at the part that broke. Browserbase recommends this path.
The second is a plain tool-calling loop that you write yourself. The model stays in the loop at runtime, but instead of three broad commands it gets the whole browser surface: navigation, locators, clicks, waits, snapshots. A step names a specific operation rather than restating it as an English sentence.