How to Build a Research Agent That Reads the Live Web

Solari gives a research agent the live web: a Solari cloud browser starts a session in 8 ms on Steel's open-source benchmark and reads the pages that render in JavaScript, sit behind a login or block automation. The build has three parts. A search step finds the pages, one Solari browser reads each page, and a Solari sandbox runs the parsing and analysis code away from your own machines. You bring the model and the search API; Solari runs the environment it works in.

A research agent that fetches pages over plain HTTP works in the demo and fails in production. The first page that renders in JavaScript, sits behind a login or shows a bot challenge comes back empty, and the agent answers from whatever it managed to read. Self-hosting Chromium is the usual next step, and the team's time moves from research quality to keeping browsers alive. A hosted browser layer is the common fix. Browserbase, Steel and Solari all sell one, and the build below runs on Solari.

What a Research Agent Needs From Its Infrastructure

Solari covers the four things a research agent needs: fast sessions, many sessions at once, logins that persist and somewhere safe to run code. One question can turn into dozens of page reads, so session start time and concurrency decide how long the agent takes to answer. Paid sources need a login that survives between runs. And the analysis step, where the model writes code to clean, dedupe and compare what it found, should never run on the host that holds your keys.

Step 1: Find the Pages

Discovery runs on the search API your model already calls. Browserbase sells one: Browserbase says its Startup plan includes 1,000 search calls a month on its pricing page. Any search provider works here. Solari takes over once the agent has a list of URLs it wants to read.

Step 2: Read Each Page in a Real Browser

Solari opens one real Chrome per URL, the agent reads the page, and the session closes. You drive it with the standard Playwright API, and the sessions docs say "Every option is opt-in. The default is a fast headless browser with no profile, recording, proxy, or stealth." Turn on stealth for sites that flag bots; proxies and captcha solving run on stealth sessions.

import { Solari } from "@solarisdk/browser"

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })

async function read(url: string) {
  const browser = await solari.launch({ stealth: true, recording: true })
  try {
    const page = await browser.newPage()
    await page.goto(url)
    const text = await page.locator("body").innerText()
    return { url, sessionId: browser.id, text }
  } finally {
    await browser.close()
  }
}

const urls = await search(question)            // your search API
const pages = await Promise.all(urls.map(read)) // one session per page

import { Solari } from "@solarisdk/browser"

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })

async function read(url: string) {
  const browser = await solari.launch({ stealth: true, recording: true })
  try {
    const page = await browser.newPage()
    await page.goto(url)
    const text = await page.locator("body").innerText()
    return { url, sessionId: browser.id, text }
  } finally {
    await browser.close()
  }
}

const urls = await search(question)            // your search API
const pages = await Promise.all(urls.map(read)) // one session per page

import { Solari } from "@solarisdk/browser"

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })

async function read(url: string) {
  const browser = await solari.launch({ stealth: true, recording: true })
  try {
    const page = await browser.newPage()
    await page.goto(url)
    const text = await page.locator("body").innerText()
    return { url, sessionId: browser.id, text }
  } finally {
    await browser.close()
  }
}

const urls = await search(question)            // your search API
const pages = await Promise.all(urls.map(read)) // one session per page

Solari's session speed pays off when one answer needs many reads. On Steel's open-source benchmark, a Solari session averaged 199.9 ms end to end across 5,000 runs, with session create at 8 ms. On the same benchmark, Solari is about 4x faster than Kernel, about 4.5x faster than Steel and about 14.8x faster than Browserbase. Solari's PR #4 on that repo is open, so anyone can rerun it.

Solari's Professional plan runs 150 concurrent browsers, plus 50 concurrent stealth sessions counted as a separate cap. Teams moving from Browserbase keep their code and change the import, with the migration guide linked from the sessions docs.

Step 3: Keep Logins for Sources Your Team Pays For

Solari profiles start each session already signed in. The profiles docs say "A profile saves your login, your cookies and site data, so you don't have to sign in again." You log in once from the console's profile editor, which handles 2FA and captchas, or upload a Playwright storageState file you already have. Then pass profileId when the session launches.

Two details matter for research agents. A profile seeds exactly one context, the session's default one, so read pages through browser.newPage() rather than a context you create yourself. And the docs say to treat profiles like passwords: anyone with your API key can attach one and act as that account.

Step 4: Process What It Read in a Sandbox

Solari sandboxes run the model's code in isolation from your machines. The sandboxes docs describe a sandbox as "a machine for running code and automation, with no screen", and runCode keeps variables and imports between calls, so the agent loads the pages once and queries them step by step.

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", isolation: "hardened" })

await sbx.files.write("/tmp/pages.json", JSON.stringify(pages))
const out = await sbx.runCode(agentCode, { language: "python" })
console.log(out.results)

await sbx.kill()

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", isolation: "hardened" })

await sbx.files.write("/tmp/pages.json", JSON.stringify(pages))
const out = await sbx.runCode(agentCode, { language: "python" })
console.log(out.results)

await sbx.kill()

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", isolation: "hardened" })

await sbx.files.write("/tmp/pages.json", JSON.stringify(pages))
const out = await sbx.runCode(agentCode, { language: "python" })
console.log(out.results)

await sbx.kill()

Pick the isolation tier on purpose. The docs say "hardened" is a dedicated microVM "with all outbound network blocked", which suits code the model wrote a moment ago and you have not read. The "shared" tier is built for commands and code, and this step writes files, so it runs on "hardened".

Step 5: Record Runs So You Can Check the Sources

Solari recording gives every answer evidence of what the agent actually saw. The recording docs say the replay downloads as "a line-by-line log of everything that happened on the page", and the console replays any recorded session. They also say "Recording captures input values by default", so leave recording off for sessions that type a password.

What It Costs to Run

Solari bills a research agent $0.07 per browser hour on the Professional plan (docs pricing), a $200 monthly plan that covers $200 of usage. Solari sandboxes on Professional bill $0.0245 per vCPU-hour and $0.0077 per GB-hour on the same page. Solari's browser hour is the lowest of the three plans below.

Session length is the other number to check. Solari's Professional plan runs sessions of up to 24 hours. Steel says sessions on its Scale plan run up to 1 hr on its pricing page.

Limits to Plan Around

Plan around three things. Discovery runs on the search provider your model already calls, and Solari takes over at the URL list. Stealth sessions carry their own cap on top of the browser cap, and an over-cap stealth session gets a 429, so queue reads rather than firing them all at once. Proxies and captcha solving start on Solari's Starter plan, which matters if your sources block automation.

Where Each Fits

A research agent on Solari reads each page in a real browser, keeps its logins between runs, runs its analysis in an isolated sandbox and leaves a replay of every source it used. Search-and-fetch APIs such as Browserbase's suit agents that only need search results and short page extracts, and Browserbase is the more established vendor with the larger ecosystem; Solari is the younger company and moves faster on speed and price. For the pages search cannot render, Solari is built to run that part: start with the sessions guide, see how the pieces fit in Introducing Solari, and point your agent at its first page today on Solari's Free plan.

FAQ QUESTIONS:

• How do I build a research agent that can read JavaScript-heavy pages?

• How does a research agent stay logged in to paid sources between runs?

• Where should a research agent run the code it writes to analyse pages?