The draft reached the growth lead's review queue on a Thursday morning with a note: the statistic in the middle paragraph had been matched, word for word, against the page it came from. Nobody on the team had opened that page. An agent had, in a browser it started for the job and released minutes later.
That agent belongs to the marketing system Pinetree Research, the company that builds Solari, runs on Solari itself. The agents work inside a Solari AI Sandbox and open a Solari Cloud Browser whenever they need the web, so the whole system sits on one account and one API. This article covers what the system does, which surface each job uses, and the rules that keep a person in charge. Here is how the pieces fit together.
What the Marketing System Does
The system works like a small newsroom, so the jobs come before the infrastructure. Monitors watch competitors' sites and ask AI search engines the questions Solari's buyers ask, then write what they find into a shared vault of markdown notes. Writers read that vault, including the voice rules, the claims table and the competitor notes, and draft posts, articles and newsletters from it.
An Editor agent scores every draft against a checklist written by Harry Chow, who leads growth at Pinetree Research. A draft that clears the bar goes to his review; anything lower goes back with the fixes listed. The figure below maps each job to the surface it runs on.
Almost every row touches a web page or runs code, which raises the question of where the agents live.
Why the Agents Live in a Sandbox
The agents need a computer of their own, mostly to limit how far a mistake can travel. They write files, run scripts and install whatever a task calls for, and a sandbox keeps that work on an isolated Linux machine instead of a laptop or a shared server. Solari creates that machine by API, with commands, file transfer, and pause and resume.
State is the second reason. The sandboxes docs show an idle timeout that pauses the machine by default rather than killing it, and say its size sticks across snapshot, pause and resume. A system that works in bursts keeps its place between jobs without staying busy.
Sandboxes do the computing, but the web has different risks, and that is where the browsers come in.
Why Every Web Read Gets Its Own Browser
Reading the web is the system's most frequent job, so it gets its own surface rather than a headless browser bolted into the sandbox. An agent that needs a pricing page or a changelog opens a Solari Cloud Browser, reads the text and releases the session. Each read starts clean, so a cookie banner on one site never carries into the next.
The same browsers handle the jobs where accuracy matters most. AI-search checks run ChatGPT logged out, so the answers match what a new visitor sees. A third-party statistic enters the stat bank only after a browser finds the exact quote on its source page; otherwise it is rejected. Branded visuals render in a browser too, from a template page captured as an image.
A browser per read only makes sense when starting one costs almost nothing, and the Solari site says "Browsers are ready in 8 ms and sandboxes in 90 ms". Logged-in work is the exception to the clean-slate rule.
Keeping a Login Without Keeping a Password
Some jobs happen behind a login, and a fresh browser each time would mean signing in each time. Pinetree Health, Solari's sister brand, runs its Canva scheduling on Solari profiles in production for this reason. The profiles docs say "A profile saves your login, your cookies and site data, so you don't have to sign in again."
A profile uses Playwright's storageState format, the JSON of cookies and per-origin localStorage, and a session attached by profileId starts signed in. A person signs in once in the console's profile editor, so the password never sits in the agent's code. The docs name the rule that trips people up: a profile seeds only the session's default context, so an agent that creates its own context must apply the storage state itself.
The same page says "Treat profiles like passwords", which leads to the controls around the agents.
What a Person Still Approves
Infrastructure keeps the agents contained; a person keeps them accountable. An agent reaches the outside world only by proposing an action, and by default that proposal lands in Harry's approval queue with a short rationale. Nothing goes out under the Solari name because a model decided it should.
Recording adds an audit trail for browser work. The recording docs show recording as a flag set at launch, with a replay link or an NDJSON download afterwards, and warn that "Recording captures input values by default." Record the sessions that read and act, and leave recording off for any session that types a secret.
Put together, the setup comes down to a few choices any team can copy.
Choosing the Right Setup
The pattern is short: agents in a sandbox, a fresh browser per web job, logins in profiles, and a person approving anything public. Each choice limits what a mistake can touch, and none needs a second vendor, because the sandbox and the browsers share an account, an API key and a bill. A team building its own agent system can start with the same split and add Computer Desktops when a job needs a full screen. The wider platform is described in Introducing Solari.
Get Started With Solari
Start with a sandbox for the agents and a browser session for a single web read, then add a profile for the login that matters most. Solari is the fastest and cheapest place to run that pair, with the 8 ms browser start above and browsers at $0.07 an hour on the Professional plan, as the pricing page shows. The Free plan is $0 a month with $3 of monthly credits, so create a free Solari account and start the first sandbox today.
