Gemini CLI can search, reason over files, call tools, and assemble a research report from the terminal. The difficult part starts when the evidence lives behind JavaScript rendering, interactive filters, an authenticated session, or a page that refuses ordinary fetch requests. With Gemini CLI browser automation, the research plan no longer has to stop at the search result. Install the BrowserAct Agent Skill and Gemini CLI can move from discovery to the live source: extract a protected page, open

The research task that exposes the browser gap

Suppose the goal is:

Compare five project-management tools using their current pricing pages, public release notes, documentation, and authenticated trial dashboards. Return plan limits, recently shipped features, source URLs, retrieval times, and unresolved conflicts.

Gemini CLI can create the plan and search for relevant pages. A normal fetch may still fail in four different ways:

1. The pricing table is rendered after JavaScript executes.
2. The release-note page loads more entries after a click or scroll.
3. The dashboard exposes the real plan limits only after login.
4. The source returns a challenge, partial HTML, or content that differs from what a browser displays.

Those failures should not be collapsed into “the web page is unavailable.” They require different recovery paths. BrowserAct provides an extraction command for protected pages, real-browser execution for interactive pages, authorized Chrome-session reuse for logged-in sources, and remote human assistance at trust boundaries.

For the broader evidence model, see Live Web Data for AI Agents.

Define a research contract, not a topic

“Research project-management tools” invites a long but unreliable summary. Define the deliverable before activating a browser Skill.

Question:
As of 2026-07-15, compare Tool A, Tool B, Tool C, Tool D, and Tool E
for a 25-person software team.
 
Required fields:
- entry paid plan and monthly price
- minimum seats or billing conditions
- automation limits
- guest permissions
- latest three product releases
- source URL and retrieval time for every field
 
Source policy:
1. official pricing and documentation
2. official release notes
3. authenticated trial dashboard when public docs are incomplete
4. independent source only for external evaluation
 
Output:
- normalized comparison table
- one evidence record per material field
- conflict and missing-data log
- recommendation separated from verified facts

This contract gives Gemini CLI a stopping condition. It also prevents the model from filling missing values with memory or a search snippet.

Pro Tip: Add an as_of date and a freshness rule to the prompt. Pricing may require same-day retrieval, while a stable product-limit document may allow a longer window.

First gate: install and activate the BrowserAct Skill

Gemini CLI discovers Agent Skills from workspace and user locations, including .gemini/skills/ and the cross-agent .agents/skills/ alias. Its /skills command can list, enable, disable, and reload Skills. Remote installations require consent, and Skill activation also requests permission.

Gemini CLI documents how Skills are discovered, activated, and managed.

Use the official BrowserAct installation instruction:

Install browser-act. Skill source:
https://github.com/browser-act/skills/tree/main/browser-act
Verify it works after installation.

Then check the environment before research begins:

1. Confirm the browser-act Skill is discovered.
2. Inspect the Skill source and referenced scripts.
3. Confirm BrowserAct CLI availability.
4. Read available browser identities and current sessions.
5. Do not create, import, or delete a browser without approval.

The check matters because a Skill is procedural authority. Gemini CLI's own guidance recommends reviewing third-party Skills, avoiding hardcoded secrets, and limiting scope. The research prompt should not silently broaden shell or browser permissions.

Second gate: route each source to the lightest working path

Do not open five full browsers just because the task involves websites. Route by source condition.

A Gemini CLI collection instruction can be explicit:

For each source URL:
1. Try the lowest-cost retrieval method that can return the required fields.
2. If content is incomplete, record the failure type before escalating.
3. Use BrowserAct stealth-extract for protected page content.
4. Use a named browser session only when rendering or interaction is required.
5. Return evidence records; do not write the final comparison yet.

Third gate: collect evidence before synthesis

The collection output should be machine-checkable. One useful schema is:

{
  "entity": "Tool A",
  "field": "entry_monthly_price",
  "value": 12,
  "unit": "USD per user per month",
  "conditions": {
    "billing": "annual",
    "region": "US",
    "account": "public"
  },
  "source": {
    "url": "https://example.com/pricing",
    "retrieved_at": "2026-07-15T09:15:00Z",
    "method": "browseract-stealth-extract"
  },
  "evidence": {
    "visible_text": "Annual billing: $12 per user/month",
    "artifact": "tool-a-pricing.png"
  },
  "status": "verified"
}

The condition fields matter. A model can correctly extract $12 and still produce a false comparison if one source uses annual billing, another monthly billing, and a third enterprise pricing.

Allow five statuses:

• verified: the source directly supports the normalized value;
• partial: some conditions or qualifiers are missing;
• conflict: authoritative sources disagree;
• blocked: access or permission prevented retrieval;
• rejected: the source does not meet the source policy.

Only verified records should flow into an unqualified comparison table.

Pro Tip: Make the agent return table headers and row labels with every extracted value. Responsive pricing tables often lose column context when converted to plain text.

Fourth gate: parallelize without mixing sources

Research becomes slow when the agent opens one source, waits, extracts, closes it, and repeats the entire sequence. Parallel collection helps, but only if sessions remain isolated.

Use a named session per source family:

research-tool-a-public
research-tool-b-public
research-tool-c-public
research-trial-dashboard
research-release-notes

Each worker owns its session and returns the same evidence schema. The coordinator does not click inside a worker's browser; it waits for records, checks completeness, and assigns retries.

The authenticated dashboard should not share its identity with public stealth sessions. Public research can use fresh isolated state. The trial dashboard needs a stable authorized identity. Mixing them makes results harder to explain and can carry unexpected cookies, region settings, or account context into another source.

For the execution pattern, read Concurrent Browser Automation.

Ready to move from sequential page fetching to isolated browser research? Start with BrowserAct and give each source its own execution lane.

Fifth gate: recover from blocks without inventing data

The recovery ladder should be written before the task encounters a problem:

official API or public page
  → direct extraction
  → protected-page extraction
  → stealth browser
  → authorized local browser
  → CAPTCHA handling when permitted
  → human handoff for login, 2FA, consent, or ambiguity
  → BLOCKED result if the boundary remains unresolved

Gemini CLI should record which layer failed and why. “Could not access source” is not enough. Distinguish DNS failure, HTTP block, empty rendered state, expired authentication, CAPTCHA, missing permissions, and schema mismatch.

If a person must sign in or resolve a verification screen, preserve the original browser session and research record. The handoff guide explains how to pause and resume browser automation without moving credentials into model context.

Let Gemini reason only after the evidence gate

Once collection finishes, validate the record set:

1. Every required field has a status.
2. Verified records include URL and retrieval time.
3. Values retain billing, region, account, and filter conditions.
4. Conflicts remain visible rather than silently averaged.
5. Screenshots or artifacts exist for material claims.
6. Recommendations are clearly separated from sourced facts.

Then give Gemini CLI the verified records and ask it to synthesize:

Write the comparison using only verified evidence records.
Label vendor claims as vendor claims.
List conflicts and missing fields before the recommendation.
Attach the direct source URL to each material statement.
Do not fill a missing value from model memory.

This turns Gemini from an unconstrained web summarizer into a reasoner over a controlled live corpus.

Turn the collection path into a reusable Skill

The first project teaches the agent where pricing, release notes, and dashboard limits live. Do not make the next session rediscover every path.

Create a focused Skill package:

.agents/skills/product-tool-research/
├── SKILL.md
├── evidence.schema.json
├── source-policy.md
├── normalization-rules.md
└── report-template.md

The Skill should encode the stable procedure, not today's values. Include source priority, routing rules, evidence schema, normalization, failure statuses, browser identity rules, and the final report template. Keep volatile URLs and selectors in a reference file that can be updated without rewriting the whole procedure.

For repeated high-volume extraction from the same site, use the workflow in Create a Browser Automation Skill. Skill Forge can explore the site, verify a working data path, and package it for future agent runs.

Prove reuse in a new Gemini CLI session

Start a clean session and change one variable: the tool list, country, or reporting date. The request should be short:

Use the product-tool-research Skill to compare Tool F, Tool G,
and Tool H for a 50-person UK team as of today.
Return the standard evidence table, conflict log, and recommendation.

The rerun passes when Gemini CLI:

• activates the intended Skill;
• uses the correct evidence schema;
• routes each source to an appropriate retrieval path;
• keeps browser sessions isolated;
• stops at authentication and approval boundaries;
• produces citations that support nearby claims;
• reports missing facts instead of guessing.

Measure records verified per minute, evidence completeness, source recovery rate, human interventions, and total cost per completed research brief. Speed without evidence is not a successful run.