GTM Deep Prospecting With Browser Agents (2026 Guide)

The target account list landed in the sales channel on Monday with a request from the head of sales: before anyone writes an email, find out which of these companies are hiring for the team the product replaces. By mid-afternoon a rep had worked through careers pages, pricing pages and changelogs, and had a handful of rows with notes nobody else could check.

Deep prospecting is that research done for every account: reading each company's own careers board, pricing page, docs and news, and turning what changed into a short brief with the evidence attached. A browser agent does it by opening a browser session per account, reading the pages a rep would read and writing each finding next to the URL it came from. Solari supplies the parts on one account: cloud browsers that run accounts in parallel, saved logins for licensed tools, recordings as evidence and a sandbox for scoring. This guide walks through the pipeline from the account list to a brief a rep can trust.

What Deep Prospecting Asks of a Browser Agent

The signals decide which pages the agent opens, so they come before any code. The useful ones are concrete and dated: a job posting for the role the product serves, a pricing change, a launch on the changelog, a new integration in the docs.

Most of those pages render in JavaScript, so a plain HTTP fetch often returns an empty shell. A headless browser renders them the way a person's browser does, and the agent's job per account stays short: open the pages, extract the signals and attach the URL and the quoted line to each. That per-account shape is what lets the work run in parallel.

Run Each Account in Its Own Session

Since the unit of work is an account, each account gets its own Solari session, a real browser driven with the standard Playwright API. A failure on a careers page then stays inside that session instead of leaking into the next company.

The plan sets how many accounts run at once, and the figure below shows the paid limits from the Solari pricing docs.

A prospecting session is short, a handful of page loads and a close, so the browser hour matters more than the plan fee. The loop below sizes a worker pool to the plan and closes every browser in a finally block, so a crashed page never leaves a session running.

const limit = pLimit(PLAN_CONCURRENCY)

async function research(account: Account) {
  const browser = await client.launch()
  try {
    const page = await browser.newPage()
    const findings = []
    for (const url of account.pages) {
      await page.goto(url)
      findings.push({ url, text: await page.locator("main").innerText() })
    }
    return { domain: account.domain, findings }
  } finally {
    await browser.close()
  }
}

await Promise.all(accounts.map((a) => limit(() => research(a))))

const limit = pLimit(PLAN_CONCURRENCY)

async function research(account: Account) {
  const browser = await client.launch()
  try {
    const page = await browser.newPage()
    const findings = []
    for (const url of account.pages) {
      await page.goto(url)
      findings.push({ url, text: await page.locator("main").innerText() })
    }
    return { domain: account.domain, findings }
  } finally {
    await browser.close()
  }
}

await Promise.all(accounts.map((a) => limit(() => research(a))))

const limit = pLimit(PLAN_CONCURRENCY)

async function research(account: Account) {
  const browser = await client.launch()
  try {
    const page = await browser.newPage()
    const findings = []
    for (const url of account.pages) {
      await page.goto(url)
      findings.push({ url, text: await page.locator("main").innerText() })
    }
    return { domain: account.domain, findings }
  } finally {
    await browser.close()
  }
}

await Promise.all(accounts.map((a) => limit(() => research(a))))

Pace each company's site as well: read its robots.txt, space visits to a host and stop after repeated refusals. Public pages cover most signals, but some of the best sit behind a login.

Use Saved Logins for Licensed Tools

Some signals live in tools the team already pays for, such as a data provider or a partner portal. A Solari profile saves that login with its cookies and site data, so every session starts signed in. A person signs in once in the console's profile editor, which also handles 2FA prompts, and the code attaches it by profileId.

The rule that trips people up is the context. A profile seeds only the session's default context, so the agent opens pages from session.context or session.newPage(); a browser context the code creates itself starts without the login. Treat profiles like passwords: anyone holding the API key can attach one and act as that account.

Automate only tools whose terms allow it, and keep personal data out of the brief unless the team has a basis to hold it. With logins in place, the next concern is proving what the agent saw.

Keep Evidence a Rep Can Check

A rep sends an email only on a finding they can verify, so every signal in the brief carries its quote and link. When a finding looks wrong, a recording settles it: a session launched with recording: true replays in the console or downloads as a line-by-line log, kept for 7 days on Starter and 30 on Professional.

Recording captures input values by default, so leave it off on any session that types a password and keep it on for public-page runs. Once the evidence is attached, the findings are ready to rank.

Score the Accounts in a Sandbox

Ranking is code work rather than browsing, so it moves to a Solari sandbox on the same account and API key. The agent writes the findings into it as JSON with files.write and runs a Python scoring script through runCode, which keeps variables and imports between calls, so the model can adjust weights without reloading data.

The script is ordinary lead scoring: points for a matching job posting, a recent launch or a pricing change, and a threshold that decides which accounts reach a rep this week. Its output is a short brief per account, written back to the CRM with every source attached.

Choosing the Right Setup

Deep prospecting with browser agents comes down to four parts. Give each account its own session and size the pool to the plan, keep licensed tools behind a profile read from its default context, attach a quote and a link to every signal, and score in a sandbox. Together they turn an afternoon of open tabs into a brief that is ready before the email is written. The Solari introduction shows how browsers and sandboxes share one account.

Get Started With Solari

Start with the accounts the team is about to email and a short list of pages for each, then add a profile only where a licensed tool holds the signal. Solari browsers are ready in 8 ms and Solari is about 2x cheaper than Browserbase per browser hour, so a fleet of short research sessions stays fast and cheap. Create a free Solari account and run the pipeline on a few accounts before moving the full list to a paid plan.