The owner asked the assistant to check whether the dentist had moved Thursday's appointment and to pay the water bill if it was due. Each site wanted a password, the dentist's portal texted a code to a phone sitting in a coat pocket, and the assistant stopped to ask for help before either page got past its sign-in form.
That pause is the browser problem every personal agent app meets: each owner has their own accounts, the sites expect a person, and the agent works in short bursts between long silences. The browser layer has to supply four things: a saved login per owner, a way to hand the browser to that owner when a site asks for something only they hold, a steady network identity, and sessions that close when the errand ends. Solari Cloud Browsers cover all four through options on the session call, and this guide walks through them in the order an errand meets them.
A Saved Login for Every Owner
The first thing an errand meets is a sign-in page, so the browser layer starts with the login rather than the page. A Solari profile saves a browser's cookies and localStorage in Playwright's storageState format, and a later session that names the profile starts already signed in.
For a personal agent app the pattern is a profile per owner, stored with that owner's record and attached each time an errand runs. The attachment is a single option when the session is created:
The profile seeds only the session's default context, so a context the agent opens on its own starts signed out. A profile is also a real login: anyone with the API key can attach it and act as that account, so each environment gets its own key. Saved logins expire, though, and some sites ask questions no cookie can answer.
Handing the Browser to the Owner
When a login lapses or a site sends a code to the owner's phone, the agent needs a person, and the profile editor is how it reaches one. The app calls profiles.edit(), gets back a link and shows it to the owner, who opens a live browser in their own tab, signs in, clears the two-factor prompt and saves.
The link stays valid for 30 minutes, or until the edit is saved or exited, and nothing is saved automatically. The app either waits with waitForSave() or decides itself when to save or discard, so a half-finished sign-in never overwrites a working profile. Frameworks that speak MCP get the same handoff as a pair of tools: one returns the link, the other finishes the edit.
A stalled errand becomes a short message to the owner, which is the right experience for an app acting on someone's behalf. Once the owner is signed in, the next thing a careful site checks is where the traffic comes from.
A Steady Network Identity
Sites that guard personal accounts notice when a login arrives from a new address every time, so the browser layer has to keep its address steady. Solari routes a session through a proxy when stealth is on, with residential, static ISP or mobile IPs by country, as the proxies guide sets out.
The option that matters most here is proxy.session, a label the app picks: sessions that share the label share the same exit IP. A label per owner means the bank sees the same address on Tuesday that it saw on Monday, which is what multi-step logins and account-bound flows need. The static tier keeps a fixed IP for the whole session, which suits sites that allowlist addresses.
Proxies need stealth and a paid plan, and stealth sessions carry their own cap, counted in addition to ordinary browsers; a session over it is refused with a 429. That cap, together with how long each session stays open, is what shapes the bill.
Short Sessions and a Small Bill
A personal agent spends most of its day waiting, so the cheapest browser is the one that closes when the errand ends. Solari browsers are ready in 8 ms, so an app can open a fresh session per errand instead of keeping one warm for every owner, and a finally block that closes the browser ends the billing with the errand, as the sessions guide shows.
The plan limits a personal agent app meets first are profiles and stealth sessions, laid out in the figure below.
The rows come from the Solari pricing page. Free suits a prototype with a few test owners, while Professional holds a profile for each of several hundred owners at $0.07 per browser hour. Credits refill each month and there is no end-of-month overage charge, so a busy week cannot surprise the app with an invoice.
Cost and limits settle how the app runs; the last question is how it shows the owner what it did.
A Record the Owner Can Check
An app that acts in someone's name will be asked what it did, and a recording is the plainest answer. Solari session recording is opt-in at session create, and a replay opens from a temporary link or downloads as a line-by-line log of the page.
The rule that matters is that recording captures input values by default. An errand that types a password, a card number or a code stays unrecorded, while an errand that only reads, such as checking an appointment time, can be recorded and shown to the owner. With the login, the handoff, the address and the record in place, the setup fits in a short rule.
Choosing the Right Setup
A personal agent app's browser layer comes down to choices made per owner: a profile for the login, the editor link for anything only the owner can answer, a proxy label for a steady address, and recording only on errands that type nothing secret. Open a session per errand and close it in the same block that opened it. The personal agents guide covers the sandbox and desktop beside the browser, and the Solari introduction shows how all three share an API.
Get Started With Solari
Start with a single owner: create a profile, send yourself the editor link, sign in, and run an errand with the profile attached. Solari is the fastest and cheapest place to grow the app from there, with sessions ready in the time noted above, the Professional rate in the table and 2,000+ engineers already building on it. Create a free Solari account and the Free plan's monthly credits cover the first errands.
