When an agent clicks a button, something has to receive that click. Which machine is running the browser, who started it, and what happens to its logins when the task ends? On a developer's laptop the answer is the laptop; in production, nobody has usually decided.
Browser infrastructure for AI agents is the hosted layer that answers that question: real browsers started on request, a connection handed to the agent, each run kept apart and the right state kept between runs. Running that browser yourself works for one agent and becomes a second job once a fleet depends on it. Solari provides the layer as Cloud Browsers, next to sandboxes and desktops on one account, so a team brings the model and the agent logic while Solari runs the environment. This guide follows the parts of that layer in the order an agent meets them.
Where the Browser Actually Runs
The answer to the opening question starts with the session. A browser session here is one cloud browser that an agent opens, drives and closes. A Solari session is a real Chrome browser that runs by default as a headless browser: full page rendering, no screen.
The agent never logs in to the remote machine. It connects over a WebSocket and sends commands through the protocol behind Chrome DevTools, usually via Playwright or Puppeteer. Moving to hosted browsers changes the connection line, not how the agent drives the browser.
Start time matters at this step because the agent waits for it on every task. Solari browsers are ready in 8 ms, so the start barely registers next to the page load that follows. A fresh browser is only half the story, though, since most useful work sits behind a sign-in.
What Survives Between Runs
Logins are the next thing an agent meets, and a browser that forgets them makes the agent sign in again, two-factor prompts included, on every run.
A profile solves that. A Solari profile saves a login, its cookies and its site data in Playwright's storageState format, and any later session that passes the profileId opens already signed in. One rule trips people up in code: a profile seeds only the session's default context, so a context the agent creates itself starts empty.
Pinetree Health's Canva scheduling runs on Solari profiles in production. Because a profile holds a real login, it deserves the same care as a password. Saved logins only help, however, when the site lets the browser in at all.
Getting Past Sites That Block Automation
That leads to the third part of the layer: sites that challenge or refuse a browser that looks scripted. Solari keeps the answer opt-in. The default browser is the fastest choice for public pages and trusted sites, while stealth mode makes the browser look like an ordinary visitor's for sites behind bot defenses.
Stealth is also the switch for proxies in a chosen country and for captcha solving. The practical rule is to start on the default, turn stealth on when challenge pages appear, and test on the exact sites the agent needs. Whichever mode runs, the next question is what actually happened inside the session.
Seeing What the Agent Did
When an agent fails, the team needs to see what the browser saw, and recording is how. With session recording, a Solari session created with the recording flag can be replayed from an expiring link or downloaded as a line-by-line log of the page.
Recording needs care: it captures input values by default, so a session that types a password or card number should run unrecorded. With visibility covered, the remaining questions are isolation and cost.
Isolation, Scale and Cost
Running many agents at once raises two questions: can one run see another, and what does the fleet cost. On isolation, each Solari session runs in a microVM with a dedicated kernel per session, which keeps one agent's browser state away from the next. On cost, a monthly plan sets the concurrency cap and session length, and browser time is billed hourly, as the figure below shows.
The free plan covers prototyping, and each step up mostly buys more browsers in parallel and longer sessions. Proxies and captcha solving are metered separately on the paid plans, with the rates on the Solari pricing docs. Browsers are not the only environment an agent needs, which is where the layer widens.
Beyond the Browser: Sandboxes and Desktops
Some jobs need more than a web page: code an agent writes needs a sandbox to run in, and a computer-use model needs a full screen. Solari offers AI Sandboxes, isolated Linux machines for agent-generated code, and Computer Desktops, Linux computers with a graphical screen an agent can see and control. Both run on the same account and API key as the browsers.
Choosing the Right Setup
Browser infrastructure comes down to the parts above: a session the agent's existing client can drive, logins that persist, a way past bot defenses, a replay of every run and isolation that holds at fleet size. Judge a provider on those five, on the sites the agent actually visits, rather than on a feature list. Price comes last, measured at the team's own volume of browser hours. Browsers, sandboxes and desktops sit behind one Solari API, a design the Solari launch post walks through.
Get Started With Solari
To pick the right browser layer for an agent, start one session from the sessions guide, point the existing Playwright script at it and run a real task end to end. Solari starts browsers in the 8 ms noted above and bills them at $0.07 per browser hour on Professional, so get started with Solari today.
