A Bounded Autonomy Architecture

Browser Use becomes easier to judge when its features are read as one architecture rather than as a catalogue of browser actions, model providers, and deployment options. The central question of this series has been where an open-ended model can usefully act on a changing web interface and where control must return to the runtime, the application, or a person. The answer is a bounded feedback system: Browser Use can make the page legible, turn a model decision into a typed operation, and preserve evidence of what happened, but it cannot make an ambiguous business outcome self-verifying.

The system’s value lies in the feedback boundary

A Browser Use task starts with an objective and a definition of acceptable success. That definition is easy to neglect because the agent’s immediate input is usually a natural-language request. Yet “find,” “compare,” “fill,” and “book” imply different proof. A search task may need a set of extracted links. A form task may need a confirmation message and a saved value. A booking task may need a durable identifier, not merely a click result. The success definition tells the rest of the architecture what evidence to preserve.

From there, the agent repeatedly moves through the same relationship. The browser session provides a current state; the state layer selects DOM, accessibility, layout, tab, scroll, loading, file, and screenshot signals; the model interprets that packet; the tool registry validates and executes a typed action; browser and domain policy constrain the effect; and the result returns through history and observability into the next state. The loop is adaptive because each decision is conditioned on new evidence. It is bounded because the model acts only through the tools, browser session, and policies the application has exposed.

flowchart LR T["Task and success definition"] --> S["Current browser state"] S --> M["Model judgment"] M --> A["Typed action contract"] A --> P["Browser and domain policy"] P --> E["Browser effect"] E --> R["Result, history, and observability"] R --> V{"Task-specific verification"} V -->|Continue with evidence| S V -->|Stop or escalate| H["Application or human accountability"] A -.-> C["Application defines tool privilege"] P -.-> C C -.-> H

Each connection matters. A good model cannot compensate for a state packet that omits the control it needs. A rich state packet cannot compensate for a tool contract that exposes an unsafe operation. A validated action cannot compensate for a browser profile that allows the wrong destination. A blocked destination cannot compensate for a completion rule that accepts a locally successful click as proof of a business outcome.

Consider a task that asks Browser Use to find an available appointment and complete the booking. The task is not one action. The browser may expose a location field, build an autocomplete menu after input, reveal dates only after a search, open a slot list in a new state, and display a final confirmation. The state representation must identify the current controls and signal when the page is still loading. The model must choose a next step from that representation. The tool layer must validate the action and stop stale queued actions if the page changes. The result must tell the next step whether suggestions appeared, navigation occurred, or an error was returned. The application must still verify that the appointment was actually booked.

This example shows why the architecture is more than a wrapper around a language model. The browser is not merely an output device; it is the environment that produces evidence and changes in response to actions. The model is not merely a text generator; it is a decision-maker constrained by a representation and an action schema.