In Lesson 32.1 you learned the hosted deal: the platform supplies the model, the limits, and the connectors, and you supply the goal and the judgment. Now we examine the connector people reach for first — the web.

What a browsing agent actually does

A web or browsing agent is a hosted agent that can inspect web pages and, on some platforms and under platform rules, take browser actions: open pages, follow links, fill forms, scroll, screenshot, or click through a flow. The platform mediates everything — which sites are reachable, whether login is allowed, how many steps the agent may take, and what it may submit.

Think of it as sending an assistant to the library with a time limit and a rulebook. The assistant can read, compare, and report. It can sometimes fill in a form you point at. But it cannot stay overnight, it cannot enter locked rooms, and it follows the library's rules, not yours.

Platform browsing behavior changes often. Before relying on any specific capability — logins, file downloads, form submission, shopping actions — check the provider's current documentation linked in Lesson 32.1.

Where browsing agents shine

• Research across public pages. Gather background from several articles, compare how sources describe the same event, collect quotes with links back to the page.
• Page comparison. "How do these three pricing pages differ?" The agent reads rendered pages a human would otherwise open one by one.
• Form navigation and walkthroughs. Mapping a multi-step public flow: which screens exist, what fields are required, where the flow dead-ends.
• UI validation. Open a staging or public page, screenshot it, and report what renders — broken layouts, missing copy, error banners.

These all share a trait: the evidence is visible in the page itself, and a human can re-open the same page and confirm what the agent reported.

Where they break

• Fragile pages. Sites change layouts, selectors, and flows without notice. A browsing sequence that works on Monday can fail on Tuesday because a button moved. There is no contract with a rendered page the way there is with an API.
• Login and permission boundaries. Many platforms restrict or forbid authenticated browsing. Even where login is technically possible, handing session credentials to an agent crosses a boundary: you are granting identity, not just information. Prefer an official API or a scoped token wherever one exists.
• Incomplete evidence. An agent may read three pages, miss the fourth, and summarize confidently. Unlike an API response with a defined schema, "I read the site" has no completeness guarantee. Treat browsing output as leads, not records.
• Non-repeatability without state. A hosted browsing run leaves no durable run record you control — no job ID, no step log, no retry-from-step-three. Re-running the same prompt next week may follow different links and reach different conclusions, and you will have no log to explain the difference.

Dashboard browsing versus API and CLI work

This is the decision that matters most in practice.

Browsing a dashboard means the agent reads rendered screens designed for human eyes: charts without underlying numbers, tables split across pages, exports behind clicks. It works for a one-off check. It fails as an operational workflow because every step depends on pixels and layout.

Using an authenticated API or CLI tool means calling a defined interface: request a report, receive structured data, store it, act on it. The call either succeeds or returns an error. It can run on a schedule, log each step, retry cleanly, and be reviewed in code. That is the repeatable path you learned in Parts V and VII.

The rule of thumb: if a service offers an official API and your use is permitted, use the API. Use browsing for inspection and one-off understanding; use APIs and CLIs for anything that must run more than once or be trusted.

A concrete contrast

Take a weekly price check across three vendors. The browsing version: an agent opens each site, scrolls past banners, finds the price element, copies the figure, and pastes it into a table — repeating every week, breaking whenever a layout shifts, with no record of which page version it saw. The API version: a script calls each vendor's product endpoint with a key, receives structured records, stores the raw responses with timestamps, and diffs them. The second version runs unattended, retries cleanly on failure, and leaves evidence a human can audit months later.

Both produce a table on a good day. Only one produces the same table for the same reasons next month. That repeatability gap is why operators treat browsing as reconnaissance and APIs as infrastructure: browse to learn what exists, then build the durable path on the interface that promises a contract.

Practical exercise: choose the surface

Take these four tasks and assign each one surface — browser inspection, official API, CLI, or no automation:

1. Compare how three competitors describe the same feature on their public pages. 2. Pull last month's sales totals into a spreadsheet every Monday morning. 3. Check whether your staging homepage renders correctly after a deploy. 4. Log into a bank portal nightly and move money based on an agent's judgment.

For each, write one sentence of justification naming the deciding factor: repeatability, evidence quality, permission boundary, or fragility.

Finish line: four tasks, four assigned surfaces, four one-sentence justifications.

Verify it: for the task you assigned to API or CLI, name the actual API or tool that would serve (or write "no documented API found — recheck"). For the task you assigned to browsing, name what evidence a human would re-check.

Common failure mode: assigning task 4 to any automation without stopping at the permission boundary. Moving money on scraped sessions combines every weakness — fragile selectors, credential exposure, irreversible action, no audit contract. The correct answer is no automation, or a bank-provided API with explicit approval, never screen-scraping plus judgment.

Check your understanding

1. Why is "the agent read the site" weaker evidence than "the API returned this record"? 2. Name two weaknesses that make dashboard browsing unsuitable as a scheduled operational workflow. 3. A vendor offers both a dashboard and a documented API. Which do you automate against, and why?

Next, we cross the boundary: what changes when you stop renting the agent's home and build it yourself — your code, your VPS, your rules.