← Back to all posts

Browser automation for agents has two different jobs, and pretending they are the same job creates bad systems.

Sometimes an agent needs a clean browser runtime: CI, scraping, QA, scheduled checks, and research runs where personal cookies should not be involved. Sometimes an agent needs the user's real browser: existing tabs, active sessions, extension state, and authenticated workflows that cannot be recreated safely in a new browser.

Scout is built around that distinction.

Hosted runtime first

The browser runtime exposes browser automation over MCP. Agent clients connect over streamable HTTP, authenticate, discover typed tools, and call operations such as browser-navigate, browser-snapshot, browser-interact, browser-extract, and browser-screenshot.

That path is the default because it is portable and isolated. It works well for IDE agents, CI jobs, scraping flows, and automation that should not inherit personal browser state.

Extension when state matters

The extension path exists for the cases clean automation cannot solve. If an agent needs the user's visible Chrome session, authenticated tabs, browser cookies, or extension-mediated state, Scout can coordinate with the extension through durable session streams.

That does not make the extension the whole product. It makes the extension a runtime bridge for real-browser workflows.

Why CDP still matters

CDP is still the right low-level browser control plane for many browser operations: page lifecycle, runtime evaluation, network events, console logs, screenshots, dialogs, storage, downloads, and tracing. Scout wraps those capabilities in typed MCP tools so agents work with stable refs and structured results instead of raw protocol details.

The important choice is not "CDP or no CDP." The important choice is which browser context the agent is allowed to operate: a clean connector-managed session or a real user browser session.

The mental model

For browser work, the loop stays the same:

1. Connect or launch a browser context.
2. Capture a snapshot.
3. Act through refs.
4. Observe events.
5. Extract content.
6. Repeat until the task is complete.

Scout's runtime architecture keeps that loop stable while making the boundary explicit. Other capabilities stay in their own scoped surfaces instead of being folded into browser automation.