When Model Intent Becomes Browser Behavior

Browser Use’s tool layer is the boundary where a model’s interpretation of a page becomes an operation with consequences. This chapter explains what that boundary adds: action descriptions that guide selection, schemas that constrain arguments, runtime context that connects a tool to the current browser, and result fields that determine what the agent sees next. The goal is practical judgment: the reader should be able to expose a small custom action surface and distinguish a browser interaction from extraction, file handling, and final task output.

The registry is a contract between model and runtime

A language model can describe an intention in ordinary language, but a browser needs a concrete operation. “Choose the earliest available appointment” is not executable until the system has decided whether it should search, click a date, select a slot, submit a form, or extract information. Browser Use’s Tools registry provides that vocabulary. Its built-in actions cover navigation and search, clicking and input, scrolling and key sending, tabs and form controls, extraction, screenshots, file operations, JavaScript evaluation, waiting, and task completion.

The list matters less than the contract behind it. Each registered action has a name and a description. The description is shown to the model as part of the available action surface, so it explains not only what the function does but when it should be selected. The action also has a parameter model. The registry can derive a Pydantic model from a function signature or accept one explicitly, then validate the model’s arguments before the function runs. A request to click without a usable index, select a value with the wrong shape, or call a custom function without a required argument can fail at the interface rather than inside an unpredictable browser operation.

That validation is a form of translation. The model operates in a semantic space—“the login button,” “the first result,” or “the current UTC time”—while the registry requires named fields and types. The browser then receives an operation that the runtime can inspect and log. The contract does not make the model correct, but it narrows the gap between what the model meant and what the system is capable of executing.

The registry also injects context by agreement about parameter names. A custom action can receive the current BrowserSession, the direct CDP client, a page-extraction model, a file system, available file paths, the current page URL, or an indication that sensitive data is present. The model does not have to serialize a live browser connection into its output, and the action author does not have to reconstruct that connection from a string. The runtime supplies the object at execution time, after validating the model-facing parameters.

This creates an important ownership boundary. The model chooses a registered action and supplies its public inputs. The registry validates those inputs and supplies live context. The action function uses that context to perform work. A custom action that needs to interact with the page must ask for the runtime’s browser-session parameter rather than assuming that a generic browser object will appear. The names are part of the interface because they determine what the runtime is allowed to inject.